Darren Reed
2004-Apr-20 18:59 UTC
[Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)
Forwarded message:> From full-disclosure-admin@lists.netsys.com Wed Apr 21 11:49:12 2004 > To: full-disclosure@lists.netsys.com > From: Darren Bounds <dbounds@intrusense.com> > Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability > Date: Tue, 20 Apr 2004 18:19:58 -0400 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > > > Darren Bounds, CISSP > > 443D 628D 0AC7 CACF 6085 > C0E0 B2FC 534B 3D9E 69AF > > - -- > Intrusense - Securing Business As Usual > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFAhaITsvxTSz2eaa8RAtQWAKCvKFFp0oS7VkjswUelIlOIhESoPgCeLqg4 > 2DmvTJTfsx8af50acb+OJ9g> =zPCJ > -----END PGP SIGNATURE----- > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html
Don Lewis
2004-Apr-20 20:12 UTC
[Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)
On 21 Apr, Darren Reed wrote:> Forwarded message: >> From full-disclosure-admin@lists.netsys.com Wed Apr 21 11:49:12 2004 >> To: full-disclosure@lists.netsys.com >> From: Darren Bounds <dbounds@intrusense.com> >> Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability >> Date: Tue, 20 Apr 2004 18:19:58 -0400 >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txtI saw this draft earlier today. RFC793 [1] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: 1) If the RST bit is set and the sequence number is outside the expected window, silently drop the segment. 2) If the RST bit is set and the sequence number is acceptable i.e.: (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. Instead, the following changes should be made to provide some protection against such an attack. A) If the RST bit is set and the sequence number is outside the expected window, silently drop the segment. B) If the RST bit is exactly the next expected sequence number, reset the connection. C) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an acknowledgment. Our original implementation of the RST sequence number checking was much more permissive than RFC 793. I submitted a patch, which was included in tcp_input.c version 1.81 that implemented steps A and B above. It was discovered that this is incompatible with certain peers, so the code was changed to match RFC 793 in tcp_input.c 1.98. I don't know if adding step C will fix the problem. There may further info in the list archives.
Frankye - ML
2004-Apr-22 04:55 UTC
Fw: [bugtraq] NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability
The NetBSD folks just released some patches to mitigate the problem, maybe
it can be of some help.
Begin forwarded message:
Date: Wed, 21 Apr 2004 14:14:35 -0400
From: NetBSD Security-Officer <security-officer@netbsd.org>
To: bugtraq@securityfocus.com
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-----
Don Lewis
2004-Apr-23 03:42 UTC
[Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)
On 23 Apr, Mike Silbersack wrote:> > On Thu, 22 Apr 2004, jayanth wrote: > >> if i remember right this was done to handle the Alteons which >> generate a RST segment that would fall within the window size but not the >> next expected sequence no. >> So they would do something crazy like rcv_nxt + rcv_win as the sequence no, >> for the RST segment rather than rcv_nxt + 1. >> This was part of the RFC though. >> >> If it is a problem we can always revert it back. >> >> jayanth > > What type of packet was causing the Alteons to emit the RST? SYN, FIN, > normal data? > > Also, has Alteon fixed the problem or do their load balancers still > exhibit the behavior?The link I posted showed it was a FIN, and after the RST was sent (and ignored by the FreeBSD stack because of the strict sequence number check), the Alteon (or whatever it was) did not respond to the retransmissions of the FIN packet. Maybe we can get by with the strict check by default and add a sysctl to revert to the permissive check.