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/