Date: Ñá, 22 ÿíâ 2000 22:06:36
Îò: Pete Carah <pete@ns.altadena.net>
Êîìó: security@freebsd.org
Òåìà: RE: Some observations on stream.c and streamnt.c
--------------------------------------------------------------------------------
Well, our (Bay) router is rendered silent (doesn't reboot) just
routing this attack through itself at around 6k pps. If aimed at
the router it gets silent faster but never seems to need a reboot (of
course, I don't want to try this too long on the particular router).
This is an ARN at 13.01, should have lots of CPU for 6k pps of this
attack. I Don't know why just relaying the attack to the other ethernet
has such a dramatic effect. (about 2k pps get through for a few seconds
then it sleeps completely).
It is not affected if the attack is against a host (fbsd or mac) on the
same segment, so the "side-effect" multicast, etc packets don't seem to
be bothering the router, at least not soon... Don't know what our
upstream sees :-)
We tried this against fbsd (2.2.8-stable, 3.3 and 3.4) with no apparent
results, but "only" at 6k pps for 5-10 mins. It didn't affect a Mac
(i-mac at 8.6 or a powerbook at 9.0) at all other than to lengthen the
ping times about 1/2 msec (tried both to listening and non-listening ports).
We didn't have time to try windoze or either Cisco.
(I didn't compile this for a "fast" machine, only my laptop which can
only get to 6700 or so pps.)
A flowpoint 2200 DSL router as target with old firmware (1.4.x) is
affected in an interesting way; it takes ping times from 1msec to around
7 for 20 pings, then drops about 5 sec of (all) packets, then cycles
again without rebooting. Apparently when it runs out of buffers it
garbage-collects rather slowly and otherwise recovers. Haven't tried
this on current firmware.
-- Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
