UDP DoS that affects all platforms?

I was looking through Full Disclosure today and got a notice about the following:

Quote:

---

Has anyone been following the thread on NTCanuck ref a DOS vulnerability
they have discovered using UDP? I have no further info than what is in this
thread:
http://ntcanuck.com/net/board/index.php?showtopic=175

But if all that they say is true.........We could be busy!!

---

I went through the thread in question and am not fully clear as to what it is that is happening. I'm gathering -- basically -- is that a specific (guess?) UDP packet is being crafted -- originally for bandwidth testing -- is getting through firewalls and overloading systems. Does anyone else know of anything else on this or have more details?

The only thing I have seen is from the FD list also and someone wrote just a short while back:


"POC has been sent to CERT but they have yet to release it. "

So it looks like CERT may be aware of it but they could be sitting on it until the vendors come up with something. Dunno, but I'll keep an eye on it and see.

hrm, I just read through the whole link you provided. I'm a bit skeptical myself about the validity of this "finding" of theirs as I'm not familiar with the group that is doing the testing.

For all we know it could be someone just drumming up a bunch of noise to get their names known. CERT hasn't responded, none of the major vendors have responded and BSD hasn't said anything about this.

A proof of some sorts, not POC or even binaries, is needed. Maybe they could find someone that is trusted in the IT media to check out their claims. If it's true then perhaps having someone in the media yelling about this kind of hole will help.

Also, in the thread they said something about an industry rag finding a similar hole to this but as a DDoS from about 8 YEARS ago. If this was a big hole like they are suggesting then I'm guessing that someone else out there knows what it is too. 8 years is a lifetime in the IT world and for something with so much potential devestation attached to it to go uncovered for so long is a bit unlikely.

you never know though, they could be straight up and telling us like it is. Until I see something from an official source on this though I'm going to be a skeptic.

In one of the subsequent forum posts they did say that they sent binaries for testing to CERT, so maybe thier is some validity to thier claims.

Ms. M: As I am sure you have no doubt noted the tone towards the end of the thread becomes a little skeptical...... Having read their claims all the way through I have to admit a similar learyness (sp?).

They began by inferring that the implementation of the RFC's by almost all vendors, (HW & SW), with regard to UDP was flawed insofar as a specially crafted packet(s) would permanently or semi-permanently freeze the target machine(s) with a total bandwidth cost to the attacker of between 2-15% of available bandwidth. They then expanded this threat to include TCP..... Ok.... I'm with them so far..... and, at that point, I fully understand why they don't want to release any more details.

The they went ahead and hinted that someone else had come up with this concept 8 years ago and published it in a well known industry magazine. Ok, now I'm getting a little bit skeptical myself...... The concept was freely published 8 years ago and no-one has either done anything about it or created a tool to utilize the "exploit"...... not even a poor one that would require a DDoS rather than a single machine......

At the point that they claimed actual hardware damage including MB failure I began to really feel leary...... That's all a bit much.... An indefensible flaw that requires minimal resources to exploit, that has a terminal result ranging from temporary freeze, through permanent freeze requiring hard reboot, through potential file system damage and finally the potential for component damage up to complete MB failure..... Oh..... and BTW, the concept was widely published 8 years ago bit no-one else has found the "golden" code!!!!

For those that haven't read the whole thing - Firewalls are "useless"..... Except.... wait for it..... M$'s ICF...... Now I know M$ has had a long history of being, how shall we say, a little cavalier with their implementations of the RFC's but if this is all true then Billy-boy really lucked out on this one....... ;)

At this point CERT has the source..... If it's for real we will probably not hear anything for a year or more because the fault has to be so low in the RFC's that almost everyone who ever followed them will probably have to rewrite all their code...... which isn't happening overnight.

At this point I am going to ignore it as someone doing their Chicken Little impression since, apparently, there is nothing I can do about it if it does exist - but then again, my gut says "nope..... bs".

Oh I agree but that's why I wanted to ask to see if anyone else has seen anything. I mean, look at the DRDoS claims of the GRC website. It was foretold to be severe and we haven't seen much. Heck, I even had a student try to re-create it in class with no success. (then again, our routers may have been locked down).

I'm hoping that if this is legit that someone -- CERT or someone else -- doesn't just assume that it is how the protocol is supposed to work if it does cause problems. And if it's not legit then someone state where the original source is.

LordCantenberry my point is that it is only THEM saying that CERT actually has the POC. CERT has not acknowledged in a public forum that indeed they are talking to this group, and I wouldn't expect CERT to do that in the first place. I don't know this group. I haven't seen work from this group before. I haven't seen them on my mailing lists. Because of that I don't believe them. I have seen SO much FUD come though the FD list that it isn't even funny. Almost weekly (for a while at least) there was someone claiming to come up with some huge hole in the 'intarweb' that breaks any and everything. Eventually they post a POC of some small hole that was found and patched like three years ago.

I'm in the boat with Tiger Shark on this. I personally, and I stress personally do not believe these claims. It's almost too much to believe... it borders on paranoia at points with all the failures that nothing can stop besides ICF. Bleh, I just don't buy it.

touché

NTCanuck just edited his post with two links:

http://portal.acm.org/citation.cfm?i...TOKEN=97363553

http://www.comsoc.org/tcgn/conferenc...esentation.pdf

Had visited NT Canunks site early today when MS Mittens first posted....and then again this evening as I was interested in the issue....albeit very skeptical on the hardware\os damage it claims.

I see an awful lot of new posts and .....new members...............as of Jan 21 2004

Appears some AO members are closely monitoring this issue : ).....first hand ..so to speak

I'm piqued.

Morgan

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