Loose Source Routing, why is it still here?

 Update!
lsrtunnel has been released, so you can play around with spoofing IPs using source routing. Check it out!

Loose source routing has been an internet protocol option for a long time, and most people who have bothered to look at it have realized that it provides a massive security hole. I'm pretty sure no one has ever explicitly spelled it out for the rest of the world, though.

An excellent description of the guts of loose source routing is contained in TCP/IP Illustrated, vol 2 by Richard Stevens and Gary Wright, in chapter 9. It's a wonderful book for a whole host of other reasons, and if you play with packet mashing at all, you really ought to read it. For those that don't have that reference available, I'll do a brief description.

The loose source route option was added to the IP protocol in order to assist in route debugging. Nowadays, it seems to be mainly used by large ISPs, to make sure that their peers aren't inappropriately dumping traffic onto their backbone links. A packet is given a list of desired hops that should be taken on the way to the final destination.

A loose source routed packet carries the same source IP address through all of its hops. The destination IP address will be set to whatever the IP of its next hop is. The IP option field will consist of the following: 

|-1byte--|-1byte--|-1byte--|---4 bytes----|---4 bytes----| ... 
----------------------------------------------------------------
| TYPE   | LENGTH | OFFSET | IP ADDR 1    | IP ADDR 2    | ...
| (131)  |        |        |              |              | 
----------------------------------------------------------------

The type is simply the value for the loose source route option, 131. The length is the total length of the option, in bytes, including the type, length, and offset fields. The offset is the value, in bytes of the location of the next hop that the packet hopes to travel to. An offset past the end of the option signifies that the current destination IP address is the final hop.

For example, if a packet was generated from 10.1.1.1, with a final destination of 172.16.1.1 via a hop to 192.168.1.1, the intial packet would have a source of 10.1.1.1, a dest of 192.168.1.1, and an IP option with a length of 7, an offset of 4, and the IP address starting at byte 4 of 172.16.1.1. If 192.168.1.1 forwards LSR packets, it would re-emit the packet with a source of 10.1.1.1, dest of 172.16.1.1, offset of 8, and the IP address at offset 4 of 192.168.1.1.

The main security problem with LSR is that several IP stacks will reverse a source route when responding to a source routed packet. This means that it would be trivial for an attacker to spoof a packet as coming from a trusted IP address that just so happens to be source routed through an IP address that the attacker can sniff on. The unsuspecting victim would then send return traffic to the spoofed source, but LSR it through the attacker. The attacker can carry on whole TCP sessions in this way without worrying about attacking weaknesses in TCP sequence numbers or lost packets.

Another security problem is that if you've got a NAT box, or some other internal, non-publically routed IP space that sits adjacent to a box that forwards source routed packets, a remote attacker will still be able to access boxes without public IPs by using the box that forwards LSR packets as a bounce point.

So, it's a problem, it's been known as a problem for a while, what progress has been made in fixing it?

In the *nix world, it's a mixed bag.

OpenBSD 3.0 by default sets the kernel variable net.inet.ip.sourceroute to zero

Solaris is pretty bad, up until Solaris 8. Solaris 8 will respond to LSR packets by default, but won't reverse the source route. This prevents the worst of the attacks.

To disable source routing under Solaris, use ndd to set the ip_forward_src_routed parameter to 0 under /dev/ip, and ensure that tcp_rev_src_routes is 0 under /dev/tcp. (The tcp_rev_src_routes parameter was added in Solaris 8, and is 0 by default).

Windows won't forward LSR packets unless it has multiple interfaces, apparently, but will respond to LSR packets, and reverse the source route. (At least on 98, 2000, and XP, by default).

To disable Windows source routing, open the Registry Editor and access the following key:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Under this key, create a new value called DisableIPSourceRouting of type REG_DWORD. The value should be set to 1 to just disable source routing and set to 2 to disabling IP forwarding and source routing completely.

Under Windows NT 4.0, Service Pack 6 must be applied for the DisableIPSourceRouting parameter to function correctly.
(Much thanks to H D Moore for the above Windows information).

Firewalls can and do scrub LSR packets off the network. One of the default rules in pf is to block all packets with IP options. This is nice, but with the number of admins who just want things to work, there's really no substitute for having security impacting features being in their most secure setting by default. Especially when it's a feature as rarely used as reversing source routed packets.

Want to scan your own network? lsrscan is a little tool I've whipped up to check out the behavior of boxes. Try it out, give me feature requests/feedback.

To spoof connections using loose source routed packets, try lsrtunnel.

Todd