[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200211301431.gAUEVReq042905@mailserver3.hushmail.com>
From: es at hush.com (es@...h.com)
Subject: Multiple pServ Remote Buffer Overflow Vulnerabilities
-----BEGIN PGP SIGNED MESSAGE-----
Dear Matthew,
Good job on this. Please come to #!electronicsouls on efnet for an
interview. We are looking for a new head to our XSS division.
The Electronic Souls Crew
[ElectronicSouls] (c) 2002
"We will blow you in the water."
On Fri, 29 Nov 2002 23:11:03 -0800 Matthew Murphy <mattmurphy@...rr.com> wrote:
>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: Hush 2.2 (Java)
Note: This signature can be verified at https://www.hushtools.com/verify
wlMEARECABMFAj3ozGAMHGVzQGh1c2guY29tAAoJEN5nGqhGcjltmb4AoJmqpiN7hsLK
sfamAuk0HnBSpGTjAJ0c0bK/OpWv8ajYy82EQNSGMlfepg==
=Fuln
-----END PGP SIGNATURE-----
Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2
Big $$$ to be made with the HushMail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427
Powered by blists - more mailing lists