> They both send out a continous stream of identical
> fragments (same offset, same frag ID, same everything)
> where the fragments are constructed such that
For the most part, the values in the IP header don't matter. The
important thing is that the fragment offset be non-zero (even offset 1
will work). The IP_MF bit does not matter; the Windows machine locks up
in either case.
By the way, setting the checksum to 0 is perfectly valid if you are
offloading the checksumming to the NIC. Since the nic can calculate the
value in hardware much faster than I can in software, it's easier to do it
that way.
> The author has also gone to great lengths to ensure
> that correct UDP/ICMP headers are sent, which is
> kind of ludicrous, since no first fragment is sent.
Did you read the code header? The code was taken from other places as a
proof-of-concept. Had the code needed to be pretty, it would have
been. I'll remember to include veleur curtains next time, just for
you. =-)
> UNLESS ofcourse the problem here isn't fragmentation at all
> but rather a resource exhaustion attack - maybe too many
> packets are received for the MS stack to be able to handle
Did you read the original Razor advisory? If you had, you would have seen
that the problem occurs with a very small packet stream (Razor said they
could reproduce it with 150 packets/sec; I could only repro it with a
stream as slow as 250/sec). Please check your facts before you being to
widly conjecture.
> In conclusion, I see two ways that this could cause crashes:
>
> 1. It is really a network layer resource exhaustion attack
See above. This is not the case.
> 2. Microsoft doesn't verify the checksum prior to storing it.
> Microsoft doesn't verify the structural integrity (the
> packet is truncated!)
> Microsoft stores all fragments received, perhaps triggering
We all know very well that many stacks have in the past had problems with
fragments and fragment reassembly (or have you forgotten
Teardrop/Nestea/Boink already?) One more is nothing surprising. What
*is* surprising is that some processing is being done when the fragment is
obviously a duplicate of one already received.
> * If the firewall has any sort of (pseudo)fragment reassembly,
> it shouldn't forward a single packet, since there are
> no valid fragments preceding the attack sequence.
Some do, some don't. Some firewalls will also (rightly) allow fragments
through out of order, since tcp doesn't require that they show up in the
correct order either.
.phonix.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
