NetBSD Security Advisory 1999-001: select(2)/accept(2) race

From: Luke Mewburn (lukemat_private)
Date: Wed Jan 20 1999 - 01:53:52 PST

  • Next message: Nic Bellamy: "Re: Sendmail 8.8.x/8.9.x bugware"

    ------- Blind-Carbon-Copy
    
    From: Luke Mewburn <lukemat_private>
    Reply-to: lukemat_private
    To: netbsd-announceat_private
    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: lukemat_private
    
    - -----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 <rootat_private> 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
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:29:23 PDT