-
Heh, I gotta admit I'm kinda split on this one...
I mean, while the possibility of such a vulnerability cannot be totaly excluded (since not only is alot of code shared but so are design patterns); then again, extraordinary claims require extraordinary proof... which we haven't seen... yet(!/?)
Ammo
-
I've been trying to find out what ever little I could find about this, and assuming that it's a recieve livelock problem (based on the links Negative pointed out), and hypothetising that it's a real issue, shouldn't using FreeBSD or OpenBSD complied with the option DEVICE_POLLING protect from such an issue? Granted device polling is not optimal in normal use but it could provide a quick workaround (*if* it were to be true, of course)...
Ammo
-
I just don't see it. No two vendors use the same exact implementation of the TCP/IP protocol stack. For that matter, many vendors don't even follow the OSI ref. model exactly, but integrate several layers of it into a single module, and no two are the same.
I think the flaw lies elseware.........but I could be wrong.
Hope I'm not
-
Thursday January 22, 2004. 02:45 pm cst
CERT has contacted us again...
They are going to send the tool (binary only) along with some
notes that we are just_now editing to vendors. (making list also)
NOT as a vulnerability...
but for further testing on the secondary effects,
and any possible hardware combination problems.
(those problems may simply be going offline or h/w errata)
I am also including clearer_instructions and examples on it's use
as some folks had trouble reproducing effects but didn't tell us...
Hopefully we get our tiny caution/use manual correct this time. ;-)
This may take a day or two...
so for those concerned..
it's enroute shortly.
YAHOO! heh, good enough for now.
+=+=+=+=+=+=+=+=+=+
ive been following this soap since yesterday and im kinda releived for this guy