Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
NetBSD Security Advisory 2011-004: Kernel stack overflow via nested IPCOMP packet
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NetBSD Security Advisory 2011-004
=================================
Topic: Kernel stack overflow via nested IPCOMP packet
Version: NetBSD-current: source prior to April 1st, 2011
NetBSD 5.0.*: affected
NetBSD 5.0: affected
NetBSD 5.1: affected
NetBSD 4.0.*: affected
NetBSD 4.0: affected
Severity: remote DOS, possible memory corruption
Fixed: NetBSD-current: April 1st, 2011
NetBSD-5-0 branch: April 3rd, 2011
(5.0.3 will include the fix)
NetBSD-5-1 branch: April 3rd, 2011
(5.1.1 will include the fix)
NetBSD-5 branch: April 3rd, 2011
NetBSD-4-0 branch: April 3rd, 2011
NetBSD-4 branch: April 3rd, 2011
Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.
Abstract
========
A malicious packet containing nested RFC 3173 - IP Payload Compression
Protocol (IPComp) headers can cause a panic due to kernel stack exhaustion
in a kernel with option IPSEC enabled. Under certain conditions, kernel
memory may get overwritten. In kernels with option FAST_IPSEC a sufficient
quantity of such packets may cause a denial of service.
This vulnerability has been assigned CVE-2011-1547.
Technical Details
=================
The option IPSEC stack recurses through packet headers, expecting them to be
ESP/AH-IPCOMP-payload. Due to compression, an IPCOMP-IPCOMP-... packet may
contain a lot of headers, so attempting to recurse over all of them may
exhaust kernel stack, triggering a panic.
The kernel stack may overflow into other memory, causing memory corruption;
on amd64 and i386 (and some other architectures) option DIAGNOSTIC in the
kernel will prevent this corruption, causing a faster panic instead.
The IPv4 FAST_IPSEC stack merely iterates through the packet headers so
there is no ressource exhaustion by one packet, but a quine packet may
essentially iterate eternally, and thus bind ressources. With FAST_IPSEC,
there needs to be a SA configured for ipcomp to be admitted at all.
Neither IPSEC nor FAST_IPSEC are enabled in NetBSD kernels by default.
Solutions and Workarounds
=========================
Workaround: If you do not expect plain ipcomp packets, filter out
incoming proto ipcomp packets (using either ipfilter, pf or npf).
This is not sufficient if you need to allow IPSEC and cannot trust
your IPSEC peers.
Fix: Patch, recompile, and reinstall the kernel, then reboot.
IPSEC
CVS branch file revision
------------- ---------------- --------
HEAD src/sys/netinet6/ipcomp_input.c 1.37
netbsd-5-0 src/sys/netinet6/ipcomp_input.c 1.36.16.1
netbsd-5-1 src/sys/netinet6/ipcomp_input.c 1.36.24.1
netbsd-5 src/sys/netinet6/ipcomp_input.c 1.36.10.1
netbsd-4-0 src/sys/netinet6/ipcomp_input.c 1.30.12.1
netbsd-4 src/sys/netinet6/ipcomp_input.c 1.30.2.1
FAST_IPSEC
CVS branch file revision
------------- ---------------- --------
HEAD src/sys/netipsec/xform_ipcomp.c 1.26
netbsd-5-0 src/sys/netipsec/xform_ipcomp.c 1.18.18.1
netbsd-5-1 src/sys/netipsec/xform_ipcomp.c 1.18.22.1
netbsd-5 src/sys/netipsec/xform_ipcomp.c 1.18.12.1
netbsd-4-0 src/sys/netipsec/xform_ipcomp.c 1.8.2.1.4.1
netbsd-4 src/sys/netipsec/xform_ipcomp.c 1.8.2.2
The following instructions briefly summarize how to update and
recompile the kernel. In these instructions, replace:
VERSION with the fixed version from the appropriate CVS branch
(from the above table)
FILE with the name of the file from the above table
ARCH with your architecture (from uname -m), and
KERNCONF with the name of your kernel configuration file.
To update from CVS, re-build, and re-install the kernel:
# cd src
# cvs update -r VERSION FILE
# ./build.sh kernel=KERNCONF
# cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd.new
# mv /netbsd /netbsd.old && mv /netbsd.new /netbsd
then reboot:
# shutdown -r now
For more information on how to do this, see:
http://www.NetBSD.org/guide/en/chap-kernel.html
Thanks To
=========
Thanks to Tavis Ormandy, Google Security Team, for finding the issue.
Revision History
================
2011-04-07 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
http://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2011-004.txt.asc
Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.org/ and http://www.NetBSD.org/Security/ .
Copyright 2011, The NetBSD Foundation, Inc. All Rights Reserved.
Redistribution permitted only in full, unmodified form.
$NetBSD: NetBSD-SA2011-004.txt,v 1.1 2011/04/06 22:06:57 tonnerre Exp $
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)
iQIcBAEBAgAGBQJNnORpAAoJEAZJc6xMSnBuYpkP/1QWKycKZdfQRBUVTDBvR9tM
+592ibJlojZjmlUYvaw911aJnKpujg7rl6Ui5T0vfhu6ThfyTbrJODLeQdM9FFWH
LIFvEU7iZE5r9HFLFSGhkZ9mdwSCQQGdCnOrPnBLTXBq7ew/4iy8uAVNnOG2ZZso
Y0ZVZgU8E2KFW8UZSuT5z8MHmmsuu2qMQfQBkPpM+OuuKov3j0iohTJ9ybgQ235j
0YLGsWOsAYYMCWX7w97p1mCaMxWTeXhGiS7nlOAEcRrR3sQfCanUIDqtdH1qppH0
PzG3zH6ETAtlXMj/61JCAHlg4ihpzhUQe+BykDn/eDLH6WlTHgmhKAGouPSc5ejm
6X6f+m1DjItyBEnm6GLTk/9ErWZyelH1YVxL/bslCmayTDlYCfetYsK9MIPg/59c
ZdqCyX7ZXF0tx7if+h7UJHxuHGZ/tdoGsSP2oUtKupSx8WhS3B2yGQsdcJNgdiZz
3YKV04CIA8DRtbmk0OfR1PrzVM7bc3dLXHepsDSaXEQcd9ZIA6mqNW/GAkzJ5c/5
q9sq+Ak56gTHrmqReyWRoV9Yn4tTnMPEOihcv2/W0lkci9utPTiBiy2kcqdeDlQl
vceuW1gb1EZAbgnCzk2KkdZ78NlStFSE7sSfBjSpy0LX0cNWeuM+/+2Fxcobil6y
5hkc1l9hur8Ea0/HsP4v
=ITT6
-----END PGP SIGNATURE-----
Home |
Main Index |
Thread Index |
Old Index