Users login

Create an account »


Users login

Home » Hacking News » Multiple pServ Remote Buffer Overflow Vulnerabilities

Multiple pServ Remote Buffer Overflow Vulnerabilities

by Nikola Strahija on December 2nd, 2002 There are multiple buffer overflow bugs in pServ that could lead to a remote (root?) compromise of public servers running the daemon:


Pico Server (pServ) is a freeware web server available at 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).


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] != '')
reqStruct->method[j++] = reqArray[0][i++]; <--- No check of 'method'
reqStruct->method[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] != '')

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

* 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

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);


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.


Vulnerabilities discovered during source code analysis of pServ 2.0b5.

Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.


Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »