Subject: Re: gzip buffer overflow found
To: Jeremy C. Reed <reed@reedmedia.net>
From: Simon Burge <simonb@wasabisystems.com>
List: current-users
Date: 01/19/2001 14:12:27
"Jeremy C. Reed" wrote:
> This is some notes from some research. I still need to send-pr these if
> applicable. This is 1.5.1_ALPHA (i386).
>
> Seg faults with 99999-character long argument.
>
> gzip via zmore (zmore runs "gzip -cdfq")
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x805a7a2 in ?? ()
> (gdb) bt
> #0 0x805a7a2 in ?? ()
> #1 0x8048db7 in ?? ()
> #2 0x8048acd in ?? ()
> #3 0x80481bd in ?? ()
>
> Built with debugging:
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x805a7a2 in strcpy ()
> (gdb) bt
> #0 0x805a7a2 in strcpy ()
> #1 0x80a7100 in ifname ()
> #2 0x8048db7 in treat_file ()
> #3 0x8048acd in main ()
> #4 0x80481bd in ___start ()
>
> How do I look at this backtrace to find out where the trouble routine is?
>
> (Of course, maybe the 18 strcpy()'s in gzip.c should be checked, replaced,
> fixed.)
When debugging with gdb it's useful to build debugging versions of
the programs. On my main development machine, I have in /etc/mk.conf:
COPTS+= -g
LDFLAGS+= -g
so all programs and libraries get built with debugging information.
From there, it's easy to spot that it's the strcpy at line 1009 of
gzip.c. There appears to be a few other places in gzip where it could
do with some changes from strcpy to strncpy or strlcpy too - I'll look
into these now.
Simon.
--
Simon Burge <simonb@wasabisystems.com>
NetBSD CDs, Support and Service: http://www.wasabisystems.com/