Date: Wed, 21 Apr 2004 14:14:35 -0400
From: NetBSD Security-Officer <security-officer@netbsd.org.>
To: [email protected]Subject: NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability
-----BEGIN PGP SIGNED MESSAGE-----
NetBSD Security Advisory 2004-006
Topic: TCP protocol and implementation vulnerability
Version: NetBSD-current: source prior to April 22, 2004
NetBSD 2.0: branch affected, release will include the fix
NetBSD 1.6.2: affected
NetBSD 1.6.1: affected
NetBSD 1.6: affected
NetBSD-1.5.3: affected
NetBSD-1.5.2: affected
NetBSD-1.5.1: affected
NetBSD-1.5: affected
Severity: Serious (TCP disconnected by malicious party, unwanted data
injected into TCP stream)
Fixed: NetBSD-current: April 22, 2004
NetBSD-2.0 branch: April 22, 2004
NetBSD-1.6 branch: April 22, 2004
(1.6.3 will include the fix)
NetBSD-1.5 branch: April 22, 2004
Abstract
========
The longstanding TCP protocol specification has several weaknesses.
(RFC793):
- - fabricated RST packets from a malicious third party can tear down a
TCP session
- - fabricated SYN packets from a malicious third party can tear down a
TCP session
- - a malicious third party can inject data to TCP session without much
difficulty
NetBSD also had an additional implementation flaw, which made these
attacks easier.
Technical Details
=================
Under the current TCP protocol specification, it is impossible to make
us perfectly secure against these vulnerabilities. Improvements have
been made to reduce the probability of successful attacks. These
improvements are based on the recently released Internet Draft,
draft-ietf-tcpm-tcpsecure-00.txt
Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did
not even check that a RST's sequence number was inside the window. RSTs
anywhere to the left of the window were treated as valid.
The fact that this has gone unnoticed for so long is an indication that
there have not been a large number of RST/SYN DoS attacks ocurring in the
wild. However, the widespread nature of the larger TCP issue will likely
affect that trend.
Note that security protocols on top of TCP such as SSH and SSL do not
protect you from the DoS attack. These connections are also vulnerable
to disconnection. However, since these protocols sign their payloads,
data injection is not possible, though it could cause a disconnection as
a side-effect of the attack.
To use these attacks, the attacker must know the 5 tuple of the
connection being targetted. On the server end, the IP and port are
likely to be well-known. The IP and port of a client is more obscure.
For systems which provide shell access to untrusted users, be aware that
many system tools expose client IP and port information. Now that this
issue is public, developers and users may wish to discuss if any of this
information should be hidden by default.
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
http://www.us-cert.gov/cas/techalerts/TA04-111A.html
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
Solutions and Workarounds
All NetBSD systems that use TCP are affected.
The only complete protection from this issue, is to use a security
protocol which runs below the TCP layer, such as IPSec, or TCP-MD5.
However, in practice, we believe the currently implemented improvements
to the stack will prevent any serious impact of this issue.
NetBSD includes support for IPSec.
NetBSD does not include TCP-MD5 support at this time, though it is being
integrated shortly. Regardless, TCP-MD5 is only particularly suitable
for protecting BGP sessions over TCP, due to key management and cipher
selection issues. Only a small percentage of systems run BGP.
BGP system operators can prevent these attacks through ingress and
egress filtering. BGP routers should not accept packets claiming to be
from their BGP-peer, on interfaces other than those directly connected
to that peer. BGP routers should not accept packets claiming to be from
themselves, arriving on any external interface. These rules are easily
implemented with the IP Filter functionality in NetBSD.
Malicious parties create TCP packets with forged source addresses. If
you already have configured ingress filtering, according to RFC3013,
then your intranet TCP sessions are already protected. If not, consider
adding it, as well as egress filtering, to prevent your users from
forging source addresses to attack others.
The following instructions describe how to upgrade your kernel binaries
by updating your source tree and rebuilding and installing a new version
of kernel. The new kernel makes the attacks much more difficult.
* NetBSD-current:
Systems running NetBSD-current dated from before 2004-04-21
should be upgraded to NetBSD-current dated 2004-04-22 or later.
The following directories need to be updated from the
netbsd-current CVS branch (aka HEAD):
sys/netinet
To update from CVS, re-build, and re-install the kernel:
# cd src
# cvs update -d -P sys/netinet
# cd arch/ARCH/conf
# config CONFIG
# cd ../compile/CONFIG
# make clean depend; make
# cp netbsd /
# reboot
* NetBSD 1.6, 1.6.1, 1.6.2:
The binary distribution of NetBSD 1.6, 1.6.1 and 1.6.2 are vulnerable.
Systems running NetBSD 1.6 sources dated from before
2004-04-21 should be upgraded from NetBSD 1.6 sources dated
2004-04-22 or later.
NetBSD 1.6.3 will include the fix.
The following directories need to be updated from the
netbsd-1-6 CVS branch:
sys/netinet
To update from CVS, re-build, and re-install the kernel:
# cd src
# cvs update -d -P -r netbsd-1-6 sys/netinet
# cd arch/ARCH/conf
# config CONFIG
# cd ../compile/CONFIG
# make clean depend; make
# cp netbsd /
# reboot
* Binary Patch:
The 1.6 kernels are being built. This text will be updated once
they are available. The instructions are included here so that
you can follow them once the patch directory is populated with
a patch for your architecture.
For the NetBSD-1-6 branch, binary patches are being provided, in
the form of replacement kernels built with the patches from the
GENERIC kernel configuration. If you use a custom kernel
configuration, these may not be suitable for you.
To apply the binary patch, perform the following steps,
replacing ARCH with the NetBSD architecture you are running
(i.e. i386):
ftp://ftp.netbsd.org/pub/NetBSD/security/patches/SA2004-006-kernel/netbsd-1-6/ARCH-kernel.tgz
cd / && cp /path/to/ARCH-kernel.gz /
gzip -d ARCH-kernel.gz
The tar file will extract a new copy of:
ARCH-kernel
Back up your old kernel:
mv netbsd netbsd.old
Then either rename:
mv ARCH-kernel netbsd
or link, as per local site policy:
ln ARCH-kernel netbsd
Then, reboot.
* NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3:
The binary distribution of NetBSD 1.5 to 1.5.3 are vulnerable.
Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated
from before 2004-04-21 should be upgraded from NetBSD 1.5.*
sources dated 2004-04-22 or later.
The following directories need to be updated from the
netbsd-1-5 CVS branch:
sys/netinet
To update from CVS, re-build, and re-install the kernel:
# cd src
# cvs update -d -P -r netbsd-1-5 sys/netinet
# cd arch/ARCH/conf
# config CONFIG
# cd ../compile/CONFIG
# make clean depend; make
# cp netbsd /
# reboot
Thanks To
=========
NISCC
JPCERT/CC
Markus Friedl
Randall Stewart
Revision History
================
2004-04-21 Initial release
More Information
================
Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at
ftp://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.org/ and http://www.NetBSD.org/Security/.
Copyright 2004, The NetBSD Foundation, Inc. All Rights Reserved.
Redistribution permitted only in full, unmodified form.
$NetBSD: NetBSD-SA2004-006.txt,v 1.2 2004/04/21 17:34:50 david Exp $
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iQCVAwUBQIax4j5Ru2/4N2IFAQGApAP/e2HLnCeKLc6iaJ/VNW/uJ9pH+iXFuS5a
xT4NhV9YCyxAFKYlZjaanA0h3Nnedekk/FJpiVleb2I1el6sz7f4oQe8QhgnA6f/
jaINWUhkb9vmdhA0U629BWxCSHUzATEoTTXo2U5Onh4UTS2xBU+SmBc2DwhqXRB5
GS2zePuQpb0=
=YiKd
-----END PGP SIGNATURE-----
