Over the past few years TCP sequence number prediction attac s have become a real threat against

unprotected networ s, ta ing advantage of the inherent trust relationships present in many networ installations. TCP sequence number prediction attac s 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 introduces an alternative method of obtaining the initial sequence number from some common trusted services. The attac presented here does not require the attac er to open multiple connections, or flood a port on the trusted host to complete the attac . The only requirement is that source routed pac ets can be injected into the target networ with fa e source addresses. This advisory assumes that the reader already has an understanding of how TCP sequence number prediction attac s are implemented. The impact of this advisory is greatly diminished due to the large number of organizations which bloc source routed pac ets and pac ets with addresses inside of their networ s. 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 attac . Technical Details ~~~~~~~~~~~~~~~~~ The problem occurs when particular networ daemons accept connections with source routing enabled, and proceed to disable any source routing options on the connection. The connection is allowed to continue, however the reverse route is no longer used. An example attac can launched against the in.rshd daemon, which on most systems will retrieve the soc et options via getsoc opt() and then turn off any dangerous options via setsoc opt(). An example attac follows. Host A is the trusted host Host B is the target host Host C is the attac er Host C initiates a source routed connection to in.rshd on host B, pretending to be host A. Host C spoofing Host A <SYN> --> Host B in.rshd

Host B receives the initial SYN pac et, creates a new PCB (protocol control bloc ) and associates the route with the PCB. Host B responds, using the reverse route, sending bac a SYN/ACK with the sequence number. Host C spoofing Host A <-- <SYN/ACK>

Host B in.rshd

A simple TCP spoofing attac

Host C responds, still spoofing host A, ac nowledging the sequence number. Source routing options are not required on this pac et. Host C spoofing Host A <ACK> --> Host B in.rshd

We now have an established connection, the accept() call completes, and control is now passed to the in.rshd daemon. The daemon now does IP options chec ing and determines that we have initiated a source routed connection. The daemon now turns off this option, and any pac ets sent thereafter will be sent to the real host A, no longer using the reverse route which we have specified. Normally this would be safe, however the attac ing host now nows what the next sequence number will be. Knowing this sequence number, we can now send a spoofed pac et without the source routing options enabled, pretending to originate from Host A, and our command will be executed. In some conditions the flooding of a port on the real host A is required if larger ammounts of data are sent, to prevent the real host A from responding with an RST. This is not required in most cases when performing this attac against in.rshd due to the small ammount of data transmitted. It should be noted that the sequence number is obtained before accept() has returned and that this cannot be prevented without turning off source routing in the ernel. As a side note, we're very luc y 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 attac s may be possible. These could include hijac ing connections across the internet without playing a man in the middle attac and being able to bypass IP options chec ing imposed by daemons using getsoc opt(). Luc ily *BSD based TCP/IP stac s will not do this, however it would be interesting to examine other implementations. Impact ~~~~~~ The impact of this attac is similar to the more complex TCP sequence number prediction attac , yet it involves fewer steps, and does not require us to 'guess' the sequence number. This allows an attac er 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. Networ administrators and users can ta e precautions to prevent users outside of their networ from ta ing advantage of this problem. The solutions are hopefully already either implemented or being implemented. 1. Bloc any source routed connections into your networ s 2. Bloc any pac ets with internal based address from entering your networ . Networ administrators should be aware that these attac s can easily be launched from behind filtering routers and firewalls. Internet service providers and corporations should ensure that internal users cannot launch

the described attac s. The precautions suggested above should be implemented to protect internal networ s. Example code to correctly process source routed pac ets is presented here as an example. Please let us now if there are any problems with it. This code has been tested on BSD based operating systems. u_char optbuf[BUFSIZ/3]; int optsize = sizeof(optbuf), ipproto, i; struct protoent *ip; if ((ip = getprotobyname("ip")) != NULL) ipproto = ip->p_proto; else ipproto = IPPROTO_IP; if (!getsoc opt(0, ipproto, IP_OPTIONS, (char *)optbuf, &optsize) && optsize != 0) { for (i = 0; i < optsize; ) { u_char c = optbuf[i]; if (c == IPOPT_LSRR || c == IPOPT_SSRR) exit(1); if (c == IPOPT_EOL) brea ; i += (c == IPOPT_NOP) ? 1 : optbuf[i+1]; } } 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 setsoc opt(). 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. Disabling Source Routing ~~~~~~~~~~~~~~~~~~~~~~~~ We believe the following information to be accurate, however it is not guaranteed. --- 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 now of a way to prevent NetBSD from accepting source routed pac ets. NetBSD systems, however, can be configured to prevent the forwarding of pac ets when acting as a gateway. To determine whether forwarding of source routed pac ets is enabled, issue the following command: # sysctl net.inet.ip.forwarding # sysctl net.inet.ip.forwsrcrt The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on. Forwarding of source routed pac ets can be turned off via: # sysctl -w net.inet.ip.forwsrcrt=0 Forwarding of all pac ets in general can turned off via: # 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 OR via their patches email server <patches@bsdi.com> The patch number is U210-037 (normal version) D210-037 (domestic version for sites running

erberized version)

BSD/OS 2.1 has source routing disabled by default Previous versions ship with source routing ENABLED by default. As far as we now, BSD/OS cannot be configured to drop source routed pac ets destined for itself, however can be configured to prevent the forwarding of such pac ets when acting as a gateway. To determine whether forwarding of source routed pac ets is enabled, issue the following command: # sysctl net.inet.ip.forwarding # sysctl net.inet.ip.forwsrcrt The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on. Forwarding of source routed pac ets can be turned off via: # sysctl -w net.inet.ip.forwsrcrt=0 Forwarding of all pac ets in general can turned off via: # 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 The response will be either 0 or 1, 0 meaning that source routing is off, and 1 meaning it is on. If source routing has been turned on, turn off via: # sysctl -w net.inet.ip.sourceroute=0 This will prevent OpenBSD from forwarding and accepting any source routed pac ets. --- 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 The response will be either 0 or 1, 0 meaning that source routing is off, and 1 meaning it is on. If source routing has been turned on, turn off via: # sysctl -w net.inet.ip.sourceroute=0 --- Linux Linux by default has source routing disabled in the ernel. --- Solaris 2.x 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 attac . We now of no method to prevent Solaris from accepting source routed connections, however, Solaris systems acting as gateways can be prevented from forwarding any source routed pac ets via the following commands: # ndd -set /dev/ip ip_forward_src_routed 0 You can prevent forwarding of all pac ets via: # ndd -set /dev/ip ip_forwarding 0 These commands can be added to /etc/rc2.d/S69inet to ta e effect at bootup. --- SunOS 4.x We now of no method to prevent SunOS from accepting source routed connections, however a patch is availible to prevent SunOS systems from forwarding source routed pac ets. This patch is availible at:

ftp://ftp.secnet.com/pub/patches/source-routing-patch.tar.gz To configure SunOS to prevent forwarding of all pac ets, the following command can be issued: # echo "ip_forwarding/w 0" | adb - -w /vmunix /dev/mem # echo "ip_forwarding?w 0" | adb - -w /vmunix /dev/mem The first command turns off pac et 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 pac ets. 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 ipforwarding: ipforwarding: 1 # <- user input

A response of 1 indicates IP forwarding is ON, 0 indicates off. HP-UX can be configured to prevent the forwarding of any pac ets via the following commands: # adb -w /hp-ux /dev/ mem ipforwarding/W 0 ipforwarding?W 0 ^D # --- AIX AIX cannot be configured to discard source routed pac ets destined for itself, however can be configured to prevent the forwarding of source routed pac ets. IP forwarding and forwarding of source routed pac ets specifically can be turned off under AIX via the following commands: To turn off forwarding of all pac ets: # /usr/sbin/no -o ipforwarding=0 To turn off forwarding of source routed pac ets: # /usr/sbin/no -o nonlocsrcroute=0 Note that these commands should be added to /etc/rc.net

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 ~~~~~~~~~~~~ Than s to Niels Provos <provos@physnet.uni-hamburg.de> for providing the information and details of this attac . You can view his web site at http://www.physnet.uni-hamburg.de/provos Than s to Theo de Raadt, the maintainer of OpenBSD for forwarding this information to us. More information on OpenBSD can be found at http://www.openbsd.org

Than s to Brad Powell <brad.powell@west.sun.com> for providing information for Solaris 2.x and SunOS 4.x operating systems. Than s go to CERT and AUSCERT for recommendations in this advisory. You can contact the author of this advisory at oliver@secnet.com

-----BEGIN PGP PUBLIC KEY BLOCK----Version: 2.6.3ia mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1 A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd Kd23buvb 7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQM BO fR/bLKAOe7p9AQEBOAQA TXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8 45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU qRgK/j8KyJRdVliM1I X8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8= =xq4f -----END PGP PUBLIC KEY BLOCK----Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networ s Inc, and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. You can find Secure Networ s papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories"

Than s to Keith Bostic <bostic@bsdi.com> for discussion and a quic solution for BSD/OS.