Phonix wrote:
>
> > 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.
Hey, I was just analyzing what the code was doing. There hasn't
been much in-depth info on this so the code was the best place
I had to look for info.
> 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.
Would this mean that the proof-of-concept code only works with NICs
that do checksumming of their own? (That would have been nice to know)
> > 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. =-)
Heh :-P
Okay, veleur curtain rewrite of my statement:
"The code ensures that correct UDP/ICMP headers are sent,
but this apparently has nothing to do with the exploit,
since the receiver won't parse them".
Granted, that comment was unnecessarily poisonous, but you should
have seen my analysis of jolt v1.0, where I'm whining about the
exploit doing a buffer overrun on itself - it's actually sending
large chunks of stack data to the victim :-)
> Did you read the original Razor advisory? If you had, you would have seen
> that the problem occurs with a very small packet stream
Okay, I'll take your word for it. I was (erronously?) assuming that
this proof-of-concept code was the one used, and saw no evidence of
rate limits.
> 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?)
Not forgotten.
> 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.
Yeah, this is what got me started on thinking of other ways that
this exploit could cause the problem (such as the network layer
resource exhaustion idea).
> [on firewalls with fragment reassembly]
> 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.
Wow, this opens up a whole new can of worms.
Fact: Firewalls that do not verify the integrity of fragments cannot
protect against fragmentation attacks. If you allow fragments through
out of order, you cannot possibly verify their integrity.
Now, since you're talking about TCP specifically, I assume that you're
not really talking about fragments, but really about TCP segments,
which is a whole different story. If the firewall does not attempt
to parse the TCP data, it does not need to reassemble the TCP stream.
Hence, it can most likely let the TCP segments pass through
out-of-sequence.
But, as I said. TCP segments != IP fragments.
Regards,
Mikael Olsson
--
Mikael Olsson, EnterNet Sweden AB, Box 393, SE-891 28 �RNSK�LDSVIK
Phone: +46-(0)660-29 92 00 Fax: +46-(0)660-122 50
Mobile: +46-(0)70-66 77 636
WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
