bugtraq - Re: gzip TOCTOU file-permissions vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 13 Apr 2005 21:14:28 -0400
From: Derek Martin <code@...zashack.org>
To: bugtraq@...urityfocus.com
Cc: support@...p.org
Subject: Re: gzip TOCTOU file-permissions vulnerability

> Imran Ghory [2005-04-04 20:57 +0100]:
> > Vulnerable software
> > ====================
> > 
> > gzip 1.2.4 and 1.3.3 and previous versions running on unix.
> > 
> > Vulnerability
> > ==============
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.

Perusing the code seems to reveal that gzip is written this way for no
good reason...  It may have been to support operating systems which
don't allow the third argument of open(), but looking at the code, the
only supported OS which doesn't support the modes argument seems to be
MacOS (presumably not MacOS X).  However MacOS also seems not to
support chmod(), so there seems to be little point in separating the
two operations...  The code already defines the OPEN macro which
either uses or ignores the third (modes)  argument to open() as
needed.

Therefore the attached patch should apply  to gzip 1.2.4 (and quite
probably to 1.3.x as well) and fix the problem.

N.B.: I didn't actually test the patch, but it looks right to me.
Yeah, I'm that lazy... =8^)

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

View attachment "gzip-atomic-modes.patch" of type "text/plain" (2115 bytes)

Content of type "application/pgp-signature" skipped