[38338] in bugtraq
Re: gzip TOCTOU file-permissions vulnerability
daemon@ATHENA.MIT.EDU (Martin Pitt)
Wed Apr 13 09:51:26 2005
Date: Tue, 12 Apr 2005 13:47:01 +0200
From: Martin Pitt <martin.pitt@canonical.com>
To: Imran Ghory <imranghory@gmail.com>
Cc: bugtraq@securityfocus.com, 303927@bugs.debian.org
Message-ID: <20050412114700.GA10763@box79162.elkhouse.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <7389fc4b05040412574f819112@mail.gmail.com>
--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi Imran!
Imran Ghory [2005-04-04 20:57 +0100]:
> Vulnerable software
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> gzip 1.2.4 and 1.3.3 and previous versions running on unix.
>=20
> Vulnerability
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> If a malicious local user has write access to a directory in which a
> target user is using gzip to extract or compress a file to then a
> TOCTOU bug can be exploited to change the permission of any file
> belonging to that user.
>=20
> On decompressing gzip copies the permissions from the compressed
> gzip file to the uncompressed file. However there is a gap between the
> uncompressed file being written (and it's file handler being close)
> and the permissions of the file being changed.
>=20
> During this gap a malicious user can remove the decompressed file and
> replace it with a hard-link to another file belonging to the user.
> gzip will then change the permissions on the hard-linked file to be
> the same as that of the gzip file.
I tried this with gzip 1.3.5 and cannot reproduce this; when
gunzip'ing a file, the output file is _always_ created with 0600
permissions first, and chmod'ed to the original permission after
decompression finished. This matches perfectly to the source code in
gzip.c: treat_file() first calls create_outfile(), which does:
/* Make sure that ofname is not an existing file */
if (check_ofname() !=3D OK) {
close(ifd);
return ERROR;
}
/* Create the output file */
remove_ofname =3D 1;
ofd =3D OPEN(ofname, flags, RW_USER);
if (ofd =3D=3D -1) {
progerror(ofname);
close(ifd);
return ERROR;
}
and looks very reasonable (RW_USER equals to 0600); then the
decompression takes place, and afterwards treat_file() calls
copy_stat() to chmod the output file.
This code is the same for version 1.3.2.
Of course the file can be removed by other users after gunzip has
finished, but that is not a gzip bug, but the result of the really
dumb idea to have a group/world-writeable directory without the sticky
bit.
Maybe I understood you wrong, could you please give a small test case
which describes the vulnerability exactly?
Thanks!
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian Developer http://www.debian.org
--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCW7U0DecnbV4Fd/IRAtV0AKDAR+sT8A8iy9bm3vUPG5c6aaivqwCgw5An
7HzHk/tXbTnc9OlGiAn54go=
=dDpG
-----END PGP SIGNATURE-----
--cWoXeonUoKmBZSoM--
