Re: Buffer overflow in name_to_tcb

Lasse Kliemann <[email protected]> wrote:

> Compiled star with CFLAGS=3D"-D_FORTIFY_SOURCE=3D2 -O2" on GCC 4.5.3, =

> Glibc 2.13, Linux 2.6.39.1. Then created a file with a long name =

> (100 characters) and tried to pack it up:
>
> $ mkdir test
> $ cd test
> $ touch 01234567890123456789012345678901234567890123456789012345678901234=
56789012345678901234567890123456789
> $ star -c f=3D../test.tar .
> *** buffer overflow detected ***: /tmp/schily-2011-06-05/star/OBJ/i686-li=
nux-cc/star terminated
> =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D
> /usr/lib/libc.so.6(__fortify_fail+0x40)[0xb77a17d0]
> /usr/lib/libc.so.6(+0xe37ea)[0xb779f7ea]
> /usr/lib/libc.so.6(__strcpy_chk+0x3f)[0xb779eb3f]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x8070c84]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x80610cf]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x8061f71]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x806217e]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x804c14b]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x8051b4b]
> /usr/lib/libc.so.6(__libc_start_main+0xe6)[0xb76d2de6]
> /tmp/schily-2011-06-05/star/OBJ/i686-linux-cc/star[0x804a591]
> [ ... snip ... ]
>
> I tracked this down to line 158 in longnames.c, i.e.,
>   strcpy(ptb->dbuf.t_name, name);
>
> A look in star.h tells that t_name is only NAMSIZ long, which is 100.
>
> So something is not going well here.
>
> The problem may have been there for a long time, but recent GCCs =

> appear to be more strict with FORTIFY_SOURCE. I recently switched =

> from 4.3.x to 4.5.x.

It seems that you are a victim of a C-compiler bug.

There is nothing real that would allow you tp call that a buffer overflow a=
s =

it is 100% legal in the tar standard to put up to 100 chars into the t_name =

array.

In theory I could use strncpy but this would result in a noticable slowdown=
 or =

at least performance penalty.

This is why star carefully fills up the tar header in the right order. =


A major problem with recent GCCs is that they under some circumstances igno=
re =

the C standard. The code fragment:

	(void)write(STDERR_FILENO, "test\n", 5);

is not expected to create a warning. It however causes a non-avoidable warn=
ing =

on revent Linux versions.

Did you have a specific reason to use special compiler options?
Array bound checking causes a slow down of the code.

There is a trick to make over-picky compilers quiet......

change strcpy(ptb->dbuf.t_name, name); to:

	strcpy(ptb->ndbuf.t_name, name);

and try again.....

I expect that your compiler will detect more false buffer overflows, so you =

would need to continue checking.

BTW: would you be interested to write automated test cases?

I recently wrote a test case that I currently use for SCCS, but I would lik=
e to =

write a test suite for star too.

J=F6rg

-- =

 EMail:[email protected] (home) J=F6rg Schilling D-13353 Be=
rlin
       [email protected]                (uni)  =

       [email protected] (work) Blog: http://schily.blogs=
pot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily