Date: Wed, 20 Jan 1999 13:49:57 -0500 (EST) From: Matt Behrens <matt@zigg.com> To: security@FreeBSD.ORG Subject: NetBSD Security Advisory 1999-001: select(2)/accept(2) race condition in TCP servers (fwd) Message-ID: <Pine.BSF.4.05.9901201349300.34610-100000@megaweapon.zigg.com>
next in thread | raw e-mail | index | archive | help
Does this affect us, and is a similar patch planned? (Sorry, I haven't the talent.) :) - Matt Behrens <matt@zigg.com> Network Administrator, zigg.com <http://www.zigg.com/>; Engineer, Nameless IRC Network <http://www.nameless.net/>; ---------- Forwarded message ---------- Date: Wed, 20 Jan 1999 20:53:52 +1100 From: Luke Mewburn <lukem@GOANNA.CS.RMIT.EDU.AU> To: BUGTRAQ@netspace.org Subject: NetBSD Security Advisory 1999-001: select(2)/accept(2) race condition in TCP servers ------- Blind-Carbon-Copy From: Luke Mewburn <lukem@netbsd.org> Reply-to: lukem@netbsd.org To: netbsd-announce@netbsd.org Subject: NetBSD Security Advisory 1999-001: select(2)/accept(2) race condition in TCP servers Date: Wed, 20 Jan 1999 20:53:52 +1100 Sender: lukem@goanna.cs.rmit.edu.au - -----BEGIN PGP SIGNED MESSAGE----- NetBSD Security Advisory 1999-001 --------------------------------- Topic: select(2)/accept(2) race condition in TCP servers Version: All current versions of NetBSD Severity: Problem may allow denial of service. Abstract ======== A problem has been identified which allows remote attackers to wedge many TCP services running on 4.4BSD-derived systems, including X servers and all services run from inetd. Other (non-BSD) systems are believed to be affected as well. Technical Details ================= Many TCP servers open a TCP socket in the default blocking mode, use select(2) to wait for connections, and then accept(2) connections in blocking mode. Under some circumstances, the accept(2) may hang waiting for another connection, denying service to clients trying to connect to other ports. The scenario which causes this is: * Connection is initiated by client; 3WHS completes. * Server process is awakened and select(2) succeeds. * Connection is closed by client (e.g. by sending a RST). Connection is removed from accept(2) queue on server. * Server process does an accept(2), which hangs waiting for a connection. This scenario is sometimes difficult to reproduce, particularly if the server is very fast and the network is relatively slow. It is most effective if the server is slow and/or must do a lot of work between the select(2) and accept(2). Solutions and Workarounds ========================= Two solutions are possible: 1) Modify all TCP servers to use non-blocking listening sockets. Unfortunately, this requires changing a large amount of code, much of it maintained by third parties. 2) Modify the kernel to not remove sockets from the accept(2) queue when they are closed. A change that implements this has been added to NetBSD-current, and is available at: ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990120-accept Thanks To ========= Thanks go to Fyodor for providing nmap, with which this vulnerability was discovered. See http://www.insecure.org/nmap/ for more information. Thanks to Charles M. Hannum <root@ihack.net> for providing the solution. More Information ================ Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 1999, The NetBSD Foundation. All Rights Reserved. - -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNqWj/D5Ru2/4N2IFAQF3AwP7B/sbL1Ar8NCP/vLIaeYq698bSR2SIQRC 21yFSNY7h0qGxpsEtJ0132wIHVYp4Ho3Pbd1308ZOykx22zfZr11IlkgInW8kFKf 7K2yQOc47RAKxyaAZvgR/oqUCQE+FiZ4DYv4WDjkbUluYpcxnHmbhO/tIqbYHJqE ue/dnlXwvcA= =GHyB - -----END PGP SIGNATURE----- ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901201349300.34610-100000>