[NEWS] Multiple pServ Remote Buffer Overflow Vulnerabilities

From: support@securiteam.com
Date: 12/01/02

  • Next message: support@securiteam.com: "[NT] Moby NetSuite POST Denial of Service Vulnerability" 
    From: support@securiteam.com
To: list@securiteam.com
Date: 1 Dec 2002 13:13:18 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Beyond Security would like to welcome Tiscali World Online
    to our service provider team.
    For more info on their service offering IP-Secure,
    please visit http://www.worldonline.co.za/services/work_ip.asp
    - - - - - - - - -

      Multiple pServ Remote Buffer Overflow Vulnerabilities
    ------------------------------------------------------------------------

    SUMMARY

    The aim of <http://sourceforge.net/projects/pserv> pServ (pico Server) is
    to create a portable, small webserver. Coded in portable C with UNIX being
    the main reference platform, but porting is encouraged. Portability and
    small footprint should enable the use of pServ on a workstation as well
    as. A vulnerability in the product allows remote attackers to cause the
    server to overflow its internal buffers.

    DETAILS

    The pServ package contains several exploitable buffer overflow errors that
    may allow remote attackers to gain the privileges of the web server
    userid. As pServ has no setuid capability, this is typically uid=0/gid=0
    (root).

    Technical details:
    pServ reads in a 1024 byte line each time from the socket. After this
    occurs, several flaws in intermediate processing allow attackers to
    overrun internal buffers used by the server. This document assumes that
    the Unix newline (0x0A or '\n') is used.

    * One Byte Overflow in Stream Reading
    pServ allocates 1024 bytes for a string buffer on the stack, and then
    attempts to read the full size of the block. It is possible to zero a
    single byte of EBP (x86) by sending a TCP stream message that is exactly
    1024 bytes in length to the server.

    * Request method buffer overrun
    pServ accepts 1024 bytes in each line of the request, but then only
    allocates 16 bytes (according to the definition of "request.method" in
    main.h) for this data, so a request like:

    [buffer] / HTTP/1.0

    Will overwrite 1008 bytes of memory, and possibly allow for arbitrary code
    execution, as this structure is stored on the stack.

    In main.c:analyzeRequest():
        /* first line: method, path and protocol version */
        i = j = 0;
        while (reqArray[0][i] != ' ' && reqArray[0][i] != '\0')
            reqStruct->method[j++] = reqArray[0][i++]; <--- No check of
    'method' index
        reqStruct->method[i] = '\0';
        i++;

    * HTTP version specifier buffer overrun
    pServ only allocates a 16 byte buffer for "request.protocolVersion" in
    main.h, and then proceeds to copy the remaining data on the request line
    into this small buffer, so:

    GET / HTTP/1.[buffer]

    Will corrupt a 1008 byte range of memory.

    In main.c:analyzeRequest():

        j = 0;
          while (reqArray[0][i] != ' ' && reqArray[0][i] != '\0')

            reqStruct->protocolVersion[j++] = reqArray[0][i++]; <--- index of
    'j' not checked
        reqStruct->protocolVersion[j] = '\0';

    * User-Agent buffer overrun
    pServ only allocates a 256 byte buffer for a string that can be as large
    as 1011 bytes, allowing for the corruption of 755 bytes of stack data in
    the server process:

    GET / HTTP/1.0
    User-Agent: [buffer]

    In main.c:analyzeRequest():

            if (!strncmp(reqArray[i], "User-Agent:", strlen("User-Agent:")))
                strcpy(reqStruct->userAgent,
    &reqArray[i][strlen("User-Agent:")]);

    * Possible request parsing buffer overflow
    pServ allows 1024 bytes to be read from a line, but it then tries to merge
    the file path buffer (which can be as large as 1024 bytes, hypothetically)
    and the document root buffer (which is given the same size), resulting in
    a possible overflow. If we look at the bare minimum for an HTTP 1.0 GET
    request:

    GET / HTTP/1.0[\n]

    This gives us 1010 bytes for the file path. If the document root is 14
    bytes or larger, memory may be corrupted. The server may also append the
    default file name, which could result in denial of service if the buffer
    is overrun by this concatenation.

    In main.c:handleMethod():

                strcpy(completeFilePath, homePath); <--- the buffer could
    already be full!
                strcat(completeFilePath, req.documentAddress); <--- overflow
         ...
                    strcat(completeFilePath, defaultFileName);

    Analysis:
    Buffer overflows are a chronic security problem for many vendors. There
    are three things that make these buffer overflows more severe than some
    others:

    1) Application must run root/setuid (Privileged ports)
    2) Remote/Daemon
    3) Multiple vulnerabilities

    These overflows ALL occur on the stack, and all therefore can be easily
    used to overwrite EBP/EIP and cause the daemon to SEGV or execute
    arbitrary code.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:mattmurphy@kc.rr.com>
    Matthew Murphy.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

    Relevant Pages