Re: Buffer overflow in name_to_tcb

--===============7278799612208546968==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline


--wac7ysb48OaltWcw
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Message by -Joerg Schilling- from Mon 2011-06-13:
> Lasse Kliemann <[email protected]> wrote:
>=20
> > Compiled star with CFLAGS=3D"-D_FORTIFY_SOURCE=3D2 -O2" on GCC 4.5.3,=
=20
> > Glibc 2.13, Linux 2.6.39.1. Then created a file with a long name=20
> > (100 characters) and tried to pack it up:
> >
> > $ mkdir test
> > $ cd test
> > $ touch 012345678901234567890123456789012345678901234567890123456789012=
3456789012345678901234567890123456789
> > $ star -c f=3D../test.tar .
> > *** buffer overflow detected ***: /tmp/schily-2011-06-05/star/OBJ/i686-=
linux-cc/star terminated

> > 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.

> It seems that you are a victim of a C-compiler bug.
>=20
> There is nothing real that would allow you tp call that a buffer overflow=
 as=20
> it is 100% legal in the tar standard to put up to 100 chars into the t_na=
me=20
> array.

String length is 100, so strcpy will try to put 101 chars into=20
the t_name array, since it appends a null character.

> In theory I could use strncpy but this would result in a noticable slowdo=
wn or=20
> at least performance penalty.
>=20
> This is why star carefully fills up the tar header in the right order.=20

OK, but the protection mechanism has no way of knowing this.

Overstepping of array bounds often is an indication that=20
something is not working out as intended by the programmer. While=20
this is not the case here, the warning is still justified.

> A major problem with recent GCCs is that they under some circumstances ig=
nore=20
> the C standard. The code fragment:
>=20
> 	(void)write(STDERR_FILENO, "test\n", 5);
>=20
> is not expected to create a warning. It however causes a non-avoidable wa=
rning=20
> on revent Linux versions.

I get:

$ gcc test.c -Wall -fstack-protector -D_FORTIFY_SOURCE=3D2 -O2
test.c:2:6: warning: return type of =E2=80=98main=E2=80=99 is not =E2=80=98=
int=E2=80=99
test.c: In function =E2=80=98main=E2=80=99:
test.c:3:1: warning: ignoring return value of =E2=80=98write=E2=80=99, decl=
ared with attribute warn_unused_result

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

It is a security measure. Roughly 95% of my system is compiled=20
with stack protector and the fortify source feature. For a few=20
exceptions, it has to be switched off, e.g., Glibc needs some=20
special tuning and a few other packages. And for some packages,=20
I have not figured out yet how to pass CFLAGS to the build=20
system. But the vast majority of my packages is compiled with the=20
protection features turned on.

> There is a trick to make over-picky compilers quiet......
>=20
> change strcpy(ptb->dbuf.t_name, name); to:
>=20
> 	strcpy(ptb->ndbuf.t_name, name);
>=20
> and try again.....

This works.

Is it intended as a permanent fix?

> BTW: would you be interested to write automated test cases?
>=20
> I recently wrote a test case that I currently use for SCCS, but I would l=
ike to=20
> write a test suite for star too.

A test suite for star would be good. I'm not sure whether I can=20
give valuable contributions since I do not know much of the=20
internals, so I do not know all the corner cases which need to be=20
tested.

--wac7ysb48OaltWcw
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJN+Q4+AAoJEFYll6N4nhdvFtAQALbhw5i7sdWBv5B/J9MwEZ5d
StB2cMEcNavA90qYh35k2XN5BPiRa+fG5Q0ieDYODgrF89EpoS+CDY99kzMj4/se
p29pyGmVFvYAtJRNpUIkmPaW9Vbx13/uuUmgiaUjT8FEf1t+toDjucA83cFYnORo
GHBxJo65WQZtNBXgzzeIzjcVyMEerlnCoghowKnD/2RtQfCa8p0tF3e0Er/ckVPt
G0RPIbKAZ4K+QaeDDWBOoz7fU1cAD+2gpfUHTG+qD9bbgEOuZCwxP+h9zSpjDH+p
J+mooY+7LUCssoZueXAcUYHDVRHpSwzmNQ/hDZmUvlKbBlgEupm+hpogeByYtszS
9t9296EWcKxE3NYy6D8gAleW65yPTsG9c0pxdXpiDfm9GkqfVK1pycw9vf93k3FC
wiyLfGVCayq05MlzTgs0wD0uet5UjjmbkNSChsBmSPoX9FFXt+xF4rcHVos+MsI4
Xq3AU60ydZjD6GY0tRE9Ko8Ph0MzOWRGRViYOQ7DmEoouYTbw3aSbxb6ZuvxMIdY
jzQbQmFWxhNXzFv2gMxfkKUKlOq9uG11JG2TshATVX7ICpu2J60s1OPV86JleN7T
LVKLUlxWnZiY9U4UXf/GChEKKYwJC0mkQaEiAaf1XCVQF1lDsmQMpdOy57QrTrkK
RiV9QHUtUI/Zdsm3IeOV
=GCce
-----END PGP SIGNATURE-----

--wac7ysb48OaltWcw--

--===============7278799612208546968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Star-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/star-users

--===============7278799612208546968==--