Vulnerability in rinetd

From: Martin Schulze (joeyat_private)
Date: Thu Apr 17 2003 - 02:44:13 PDT

  • Next message: Roland Postle: "Re: Exploit/DoS in MS Internet Explorer 6.0 (OBJECT Tag)"

    Sam Hocevar discovered a security problem in rinetd, an IP connection
    redirection server.  When the server maintains 64 connections and the
    connection list is full, rinetd resizes the list in order to store the
    new incoming connection.  However, this is done improperly, resulting
    in a denial of service (rinetd may crash, hang or simply refuse new
    connections) and potentially execution of arbitrary code.
    
    The bug is triggered when 64 connections are active and a 65th is opened.
    
    In rinetd.c:handleAccept(), when the connection list is full, rinetd
    resizes it in order to store the current incoming connection.  There
    are two problems in the code that performs the resizing:
    
      - one table (coClosing) is not resized.
    
      - after the resizing is done, the new index is set to a bad value
        that is outside the tables.
    
    The bugfix is attached below.
    
    Thomas Boutell released version 0.62 with this bugfix.
    
    This problem is referenced as CAN-2003-0212 at the Common
    Vulnerabilities and Exposures project.
    
    --- rinetd.c.orig	2003-04-11 19:41:16.000000000 +0200
    +++ rinetd.c	2003-04-11 19:41:08.000000000 +0200
    @@ -1071,6 +1071,11 @@
     		{
     			goto shortage;
     		}
    +		if (!SAFE_REALLOC(&coClosing, sizeof(int) * o, 
    +			sizeof(int) * coTotal)) 
    +		{
    +			goto shortage;
    +		}
     		if (!SAFE_REALLOC(&reClosed, sizeof(int) * o, 
     			sizeof(int) * coTotal)) 
     		{
    @@ -1140,7 +1145,7 @@
     				goto shortage;
     			}
     		}
    -		index = coTotal;
    +		index = o;
     	}
     	coInputRPos[index] = 0;
     	coInputWPos[index] = 0;
    
    
    
    Regards,
    
    	Joey
    	Debian Security
    
    -- 
    Let's call it an accidental feature.  -- Larry Wall
    



    This archive was generated by hypermail 2b30 : Thu Apr 17 2003 - 08:40:16 PDT