-----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-----