lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ