Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Jan 2000 01:55:49 -0800
From:      gdonl@tsc.tdk.com (Don Lewis)
To:        Brett Glass <brett@lariat.org>, Keith Stevenson <k.stevenson@louisville.edu>, freebsd-security@FreeBSD.ORG
Subject:   Re: Some observations on stream.c and streamnt.c
Message-ID:  <200001220955.BAA16447@salsa.gv.tsc.tdk.com>
In-Reply-To: Brett Glass <brett@lariat.org> "Re: Some observations on stream.c and streamnt.c" (Jan 21,  2:44pm)

next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 21,  2:44pm, Brett Glass wrote:
} Subject: Re: Some observations on stream.c and streamnt.c
} At 02:27 PM 1/21/2000 , Keith Stevenson wrote:
} 
} >The ICMP_BANDLIM seemed to be the life saver.  I got tons of
} >"icmp-response bandwidth limit" messages in my syslog, but the load didn't
} >climb and I was still able to provide network services from the target host.
} 
} That's probably because one of the things the exploit does is to create
} an ICMP storm. Looks like it's triggered by the outgoing RST, which in
} turn is sent in response to the bogus ACK.

I think the message is misleading in this case and is being triggered
by the following code, which will cause the above message to be logged
when we try to send too many RST responses:

        if (inp == NULL) {
                if (log_in_vain) {
[ snip ]
                }
#ifdef ICMP_BANDLIM
                if (badport_bandlim(1) < 0)
                        goto drop;
#endif                  
                if (blackhole) {
                        switch (blackhole) {
                        case 1:
                                if (thflags & TH_SYN)
                                        goto drop;
                                break;
                        case 2:
                                goto drop;
                        default:
                                goto drop;
                        }
                }       
                goto dropwithreset;
        }        


If you attack a destination port that doesn't have a listening socket (or
you attack random ports, most of which won't have listening sockets, inp
will be NULL and the above code will be invoked.  ICMP_BANDLIM will keep
the code from falling through to dropwithreset the vast majority of the
time, saving your bacon.

Does anyone else think that the order of the above three tests is exactly
backwards?  This attack will really DoS the machine if you have log_in_vain
turned on.

If the attack is directed against a port with a listening socket, then
the above code is not invoked and the branch to dropwithreset happens
further down in the code at a place no protected by ICMP_BANDLIM.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001220955.BAA16447>