Over the past few years TCP sequence number prediction attacks have become a
real threat against unprotected networks, taking advantage of the inherent
trust relationships present in many network installations. TCP sequence
number prediction attacks have most commonly been implemented by opening a
series of connections to the target host, and attempting to predict the
sequence number which will be used next. Many operating systems have
therefore attempted to solve this problem by implementing a method of
generating sequence numbers in unpredictable fashions. This method does
not solve the problem.
This advisory assumes that the reader already has an understanding of how
TCP sequence number prediction attacks are implemented.
The impact of this advisory is greatly diminished due to the large number of
organizations which block source routed packets and packets with addresses
inside of their networks. Therefore we present the information as more of
a 'heads up' message for the technically inclined, and to re-iterate that
the randomization of TCP sequence numbers is not an effective solution
against this attack.
Technical Details
~~~~~~~~~~~~~~~~~
Host B receives the initial SYN packet, creates a new PCB (protocol
control block) and associates the route with the PCB. Host B responds,
using the reverse route, sending back a SYN/ACK with the sequence number.
Host C spoofing Host A <-- <SYN/ACK> Host B in.rshd
As a side note, we're very lucky that TCP only associates a source route with
a PCB when the initial SYN is received. If it accepted and changed the ip
options at any point during a connection, more exotic attacks may be possible.
These could include hijacking connections across the internet without playing
a man in the middle attack and being able to bypass IP options checking
imposed by daemons using getsockopt(). Luckily *BSD based TCP/IP stacks will
not do this, however it would be interesting to examine other implementations.
Impact
~~~~~~
The impact of this attack is similar to the more complex TCP sequence
number prediction attack, yet it involves fewer steps, and does not require
us to 'guess' the sequence number. This allows an attacker to execute
arbitrary commands as root, depending on the configuration of the target
system. It is required that trust is present here, as an example, the use
of .rhosts or hosts.equiv files.
Solutions
~~~~~~~~~
The ideal solution to this problem is to have any services which rely on
IP based authentication drop the connection completely when initially
detecting that source routed options are present. Network administrators
and users can take precautions to prevent users outside of their network
from taking advantage of this problem. The solutions are hopefully already
either implemented or being implemented.
u_char optbuf[BUFSIZ/3];
int optsize = sizeof(optbuf), ipproto, i;
struct protoent *ip;
One critical concern is in the case where TCP wrappers are being used. If
a user is relying on TCP wrappers, the above fix should be incorporated into
fix_options.c. The problem being that TCP wrappers itself does not close
the connection, however removes the options via setsockopt(). In this case
when control is passed to in.rshd, it will never see any options present,
and the connection will remain open (even if in.rshd has the above patch
incorporated). An option to completely drop source routed connections will
hopefully be provided in the next release of TCP wrappers. The other option
is to undefine KILL_IP_OPTIONS, which appears to be undefined by default.
This passes through IP options and allows the called daemon to handle them
accordingly.
--- Cisco
To have the router discard any datagram containing an IP source route option
issue the following command:
no ip source-route
This is a global configuration option.
--- NetBSD
Versions of NetBSD prior to 1.2 did not provide the capability for disabling
source routing. Other versions ship with source routing ENABLED by default.
We do not know of a way to prevent NetBSD from accepting source routed packets.
NetBSD systems, however, can be configured to prevent the forwarding of packets
when acting as a gateway.
# sysctl net.inet.ip.forwarding
# sysctl net.inet.ip.forwsrcrt
# sysctl -w net.inet.ip.forwsrcrt=0
# sysctl -w net.inet.ip.forwarding=0
--- BSD/OS
BSDI has made a patch availible for rshd, rlogind, tcpd and nfsd. This
patch is availible at:
ftp://ftp.bsdi.com/bsdi/patches/patches-2.1
# sysctl net.inet.ip.forwarding
# sysctl net.inet.ip.forwsrcrt
# sysctl -w net.inet.ip.forwarding=0
--- OpenBSD
Ships with source routing turned off by default. To determine whether source
routing is enabled, the following command can be issued:
# sysctl net.inet.ip.sourceroute
# sysctl -w net.inet.ip.sourceroute=0
This will prevent OpenBSD from forwarding and accepting any source routed
packets.
--- FreeBSD
Ships with source routing turned off by default. To determine whether source
routing is enabled, the following command can be issued:
# sysctl net.inet.ip.sourceroute
# sysctl -w net.inet.ip.sourceroute=0
--- Linux
Ships with source routing enabled by default. Solaris 2.5.1 is one of the
few commercial operating systems that does have unpredictable sequence
numbers, which does not help in this attack.
ftp://ftp.secnet.com/pub/patches/source-routing-patch.tar.gz
The first command turns off packet forwarding in /dev/mem, the second in
/vmunix.
--- HP-UX
HP-UX does not appear to have options for configuring an HP-UX system to
prevent accepting or forwarding of source routed packets. HP-UX has IP
forwarding turned on by default and should be turned off if acting as a
firewall. To determine whether IP forwarding is currently on, the following
command can be issued:
# adb /hp-ux
ipforwarding?X <- user input
ipforwarding:
ipforwarding: 1
#
--- AIX
AIX cannot be configured to discard source routed packets destined for itself,
however can be configured to prevent the forwarding of source routed packets.
IP forwarding and forwarding of source routed packets specifically can be
turned off under AIX via the following commands:
# /usr/sbin/no -o ipforwarding=0
To turn off forwarding of source routed packets:
# /usr/sbin/no -o nonlocsrcroute=0
If shutting off source routing is not possible and you are still using
services which rely on IP address authentication, they should be disabled
immediately (in.rshd, in.rlogind). in.rlogind is safe if .rhosts and
/etc/hosts.equiv are not used.
Attributions
~~~~~~~~~~~~
mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1
A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd
Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR
tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO
fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8
45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU
qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8=
=xq4f
-----END PGP PUBLIC KEY BLOCK-----
Copyright Notice
~~~~~~~~~~~~~~~~
The contents of this advisory are Copyright (C) 1997 Secure Networks Inc,
and may be distributed freely provided that no fee is charged for
distribution, and that proper credit is given.
You can subscribe to our security advisory mailing list by sending mail to
majordomo@secnet.com with the line "subscribe sni-advisories"