The Spoofed Route Pointer Vulnerability (MS99-038)

[Mikael Olsson <mikael.olsson () enternet se>]

Has anyone been able to get some more info on the
"Spoofed Route Pointer" Vulnerability (MS99-038) ?

Denying source routed packets is standard practice, I know,
but it'd be nice to be able to have firewalls detect this 
attack in particular, rather than just saying
"source route not allowed".

I'm going to go ahead and make some assumptions here...

My guess is that the route pointer does not point into the
source route option itself, but rather into dud option
or perhaps into the IP data (TCP/UDP/ICMP/etc). 
(Remember that the route pointer can offset up to 255 bytes
from the beginning of the option)

It could also be that the option list is terminated after
the source route option and then the route list is stored
after the terminator (still in reserved option space).

I'm also guessing that Windows is asking the question
"is there a valid source route option in the packet?" and
if there is, it throws it away.
This mechanism might be able to discern that the 
spoofed route pointer source routes are, in effect, NOT
valid source route options, and therefore they never 
get thrown away.

One would think however that if the stack was able to
discern that the source route isn't legally constructed,
it should throw them away by default, but...
Well..:-)

Hmm something just struck me as I'm writing this,
that actually seems probable.
What if the source route option is empty (only 
three bytes long)? This could make the stack think
that there's no source route option and therefore
not drop it, but then later on happily look at
the route pointer, pointing somewhere else in the
datagram.

Good ole' RFC791 states:
        If the pointer is
        greater than the length, the source route is empty (and the
        recorded route full) and the routing is to be based on the
        destination address field.

I'm going to go ahead and take a wild guess that the M$ implementor 
did the classical mistake of doing the comparison
"Is the offset equal to the length of the option" rather than
"Is the offset equal to or LARGER THAN the length of the option"
when checking if the source route is completed, otherwise none
of the ideas I've been discussing above would work.

<offtopic>

RFC791 states:
  The pointer is relative to this option, and the
  smallest legal value for the pointer is 4.

This seems illogical at first glance, and RFC1011 "clarifies":
  The most serious is a bit of confusion in the route options.
  The route options have a pointer that indicates which octet of
  the route is the next to be used.  The confusion is between the
  phrases "the pointer is relative to this option" and "the
  smallest legal value for the pointer is 4".  If you are
  confused, forget about the relative part, the pointer begins
  at 4.

Am I correct in assuming that the sender's IP occupies the first
four DATA bytes of the option, and that the pointer must atleast
point at the hop after that? The pointer is then actually relative
to the DATA of the option, not to the option itself?
This also means that the smallest possible source route option
is 3+4+4=11 bytes, and that correct option sizes are
11,15,19,23... bytes, correct?

</offtopic>

Any input or pointers to more information would be 
greatly appreciated.

Regards,
Mikael Olsson

-- 
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46-(0)660-105 50           Fax: +46-(0)660-122 50
Mobile: +46-(0)70-248 00 33
WWW: http://www.enternet.se        E-mail: mikael.olsson () enternet se