Bugtraq mailing list archives

DO NOT USE THAT PATCH (Re: IP firewalling bugs)


From: avalon () coombs anu edu au (Darren Reed)
Date: Thu, 24 Aug 1995 01:24:15 +1000


In some mail from System Administrator, sie said:

A variety of systems based on the Ugen firewall code (FreeBSD/Linux probably
NetBSD) are vulnerable to the following reported attack:

        Send an IP fragment 0 acceptable to the firewall
        Send an IP fragment at offset 8 to rewrite most of the header
                and all the data

that isn't the main bug.  sigh

For Linux at least the IP header should not be vulnerable to overwriting
because of the way the fragment merging is done. The following is a provisonal
not very tested fix (I only found out about the bug 30 minutes ago). Linux
is only vulnerable to tcp/udp header overwriting so host level blocking is
unaffected.

Because the Ugen firewall is virtually PD a variety of low end
routers seem to use it and may also be affected.
[...]

God this is getting old.  And I wish some people would read firewalls,
where this has been discussed to death.  btw, Ugen is using code which
was originally written by Danny Boulet (see below).

There is a fix available for the currently packaged version of ipfirewall
by Danny Boulet (which Ugen's is based upon) in FreeBSD which is to simply
use the latest rev (see below).

This was announced to firewalls mailling list and is fixed in version 2.0c.
However, there is a bug (those who read firewalls ignore this) in that
version - setting the MSB in the IP offset byte makes strange things
happen in the filter (thats a packet with 0x8000 set as opposed to
IP_MF (0x2000) or IP_DF (0x4000)).

At the time, I remember examining the IP reassembly of both BSD and Linux
and neither of them were vulnerable to overwriting fragments (when I last
checked).  You might want to reread what you said above.

Known fixed brands are:
Cisco
Livingston
Morning Star

Known fixed PD filters:
IP Filter 2.7.3
ipfirewall 2.0c (see above & is there later available ?)

- you should check the date of the revision when purchasing any of the above
for firewalling - the latter two were fixed before Easter, I believe.
See the Cisco advisory for more details (June sometime).

This is such a common and basic flaw that I'd assume any filter to be broken
unless the docs for it mention handling short TCP packets - regardless of
the name on the package.  Especially for things like Firewall-1!

+       if(frag1)
+       {
+               switch(ip->protocol)
+               {
+                       case IPPROTO_UDP:
+                               if(ip->ihl<<2+sizeof(struct udphdr)
+                                       >ntohs(ip->tot_len))
+                                       return 0;
+                               break;
+                       case IPPROTO_TCP:
+                               if(ip->ihl<<2+sizeof(struct udphdr)
+                                       >ntohs(ip->tot_len))
+                                       return 0;
+                               break;
+               }
+       }

That patch doesn't work - I can't even work out what it is trying to
solve!  In the cases where Linux is vulnerable, ip->ihl == 5 and
ip->tot_len == 28.  5 * 4 + 8 is not greater than 28.

But it won't stop Linux being vulnerable to short fragments.

What you want is something more like:

if (frag1 && (ip->protocol == IPPROTO_TCP) &&
    ((ntohs(ip->frag_off) & IP_OFFSET) << 3) < sizeof(struct tcphdr))
                return 0;

to stop all fragments which are fragmented inside the TCP header.

darren



Current thread: