From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Multiple pServ Remote Buffer Overflow Vulnerabilities

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are multiple buffer overflow bugs in pServ that could lead to a remote
(root?) compromise of public servers running the daemon:

ABSTRACT

Pico Server (pServ) is a freeware web server available at
pserv.sourceforge.net running on many POSIX compliant platforms.  The
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).

DESCRIPTION

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.

DETECTION

Vulnerabilities discovered during source code analysis of pServ 2.0b5.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x990EB050

iQA/AwUBPehkgza4rCCZDrBQEQIBgwCg+esgQwTsEFpHB+XLlw/PZHa8PvAAnjFC
fjo1pZgwby3rnLioEHq68tuk
=wYEw
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists