Date: Wed, 5 Feb 1997 18:05:33 -0700 (MST) From: Oliver Friedrichs <oliver@secnet.com> To: freebsd-bugs@freebsd.org Subject: Security advisory Message-ID: <Pine.BSI.3.95.970205180524.16600A-100000@silence.secnet.com>
next in thread | raw e-mail | index | archive | help
I plan on posting this advisory within the next working day. If you have
any comments or suggestions please respond as soon as possible.. any input
is welcome.
- Oliver
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Secure Networks Incorporated. Calgary, Alberta, Canada, (403) 262-9211
-- cut --
###### ## ## ######
## ### ## ##
###### ## # ## ##
## ## ### ##
###### . ## ## . ######.
Secure Networks Inc.
Security Advisory
February 6, 1997
A simple TCP spoofing attack
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 introduces an alternative method of obtaining the initial
sequence number from some common trusted services. The attack presented here
does not require the attacker to open multiple connections, or flood a port
on the trusted host to complete the attack. The only requirement is that
source routed packets can be injected into the target network with fake
source addresses.
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 dimished 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
~~~~~~~~~~~~~~~~~
The problem occurs when daemons which attempt to drop source routed
connections, attempt to disable the source routing option on the incoming
socket rather than closing the socket completely. An example attack can
launched against the in.rshd daemon, which on most systems will retrieve
the socket options via getsockopt() and then turn off any dangerous options
via setsockopt().
An example attack follows.
Host A is the trusted host
Host B is the target host
Host C is the attacker
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 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
Host C responds, still spoofing host A via a source routed packet,
acknowledging the sequence number.
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 checking and determines that we have initiated a source routed
connection. The daemon now turns off this option, and any packets 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
attacking host now knows what the next sequence number will be. Knowing
this sequence number, we can now send a spoofed packet without the source
routing options enabled, pretending to originate from Host A, and our
command will be executed.
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 kernel.
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.
Solutions
~~~~~~~~~
The ideal solution to this problem is to have any security critical service
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 be implemented on most
networks, however to re-iterate them:
1. Block any source routed connections into your networks
2. Block any packets with internal based address from entering your network.
This is not an ideal solution for many situations where users are behind
filtering routers in corporate networks or internet service providers.
Example code to correctly process source routed packets is presented here
as an example. Please let us know if there are any problems with it.
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 (!getsockopt(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)
break;
i += (c == IPOPT_NOP) ? 1 : optbuf[i+1];
}
}
Disabling Source Routing
~~~~~~~~~~~~~~~~~~~~~~~~
We believe the following information to be accurate, however it is not
guaranteed.
--- 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,
this can be turned off via:
% /usr/sbin/sysctl -w net.inet.ip.forwsrcrt=0
--- BSDI
BSDI 2.1 has source routing disabled by default
Previous versions ship with source routing ENABLED by default
Turn off via:
% /usr/sbin/sysctl -w net.inet.ip.forwsrcrt=0
--- OpenBSD
Ships with source routing turned off by default
If source routing has been turned on, turn off via:
% /usr/sbin/sysctl -w net.inet.ip.sourceroute=0
--- FreeBSD
Ships with source routing turned off by default.
If source routing has been turned on, turn off via:
% /usr/sbin/sysctl -w net.inet.ip.sourceroute=0
--- Solaris
Ships with source routing enabled by default. Solaris is one of the few
commercial operating systems that does have unpredictable sequence
numbers, which does not help in this attack.
We know of no method to prevent Solaris from accepting source routed
connections.
--- SunOS
We know of no method to prevent SunOS from accepting source routed
connections.
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).
Attributions
~~~~~~~~~~~~
Thanks to Niels Provos <provos@physnet.uni-hamburg.de> for providing
the information and details of this attack. You can view his web
site at http://www.physnet.uni-hamburg.de/provos
Thanks 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
You can contact the author of this advisory at oliver@secnet.com
Type Bits/KeyID Date User ID
pub 1024/0E7BBA7D 1996/09/18 Oliver Friedrichs <oliver@secnet.com>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
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 find Secure Networks 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.970205180524.16600A-100000>