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 17:00:04 +0200
From: "Peter J. Holzer" <hjp@....ac.at>
To: bugtraq@...urityfocus.com
Subject: Re: gzip TOCTOU file-permissions vulnerability

On 2005-04-12 13:47:01 +0200, Martin Pitt wrote:
> 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.
[...]
> 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.

This is not always "a really dumb" idea, but often quite necessary in a
collaborative environment. For example, several people may work together
on a project, and every person may need to create, edit and remove files
in the project directory. 

Here is a simple scenario, which might work with gzip (I haven't
actually tried it):

Alice and Eve work together on project foo, so they both have write access
to directory /projects/foo. Mallory infrequently contributes to the
project, but doesn't have write access himself.

Now Eve and Mallory conspire to get read access for a file belonging to
a different project, /projects/bar/secret_plan_for_world_domination.

Eve writes a programs, which checks for the existence of
/projects/foo/data_from_mallory, and replaces it with a symlink to
/projects/bar/secret_plan_for_world_domination if it exists. After a
second or so, it switches the file and the symlink again.

Then Mallory puts a world-readable file data_from_mallory.gz into /tmp
and sends a mail to Alice "I've put the data I promised you into
/tmp/data_from_mallory.gz, please put it into the project directory".
With a bit of luck, Alice will copy the gzipped file into the project
directory and unzip it there (she can't unzip it in /tmp, because /tmp
has the sticky bit set).  Then the following will happen:

Eve's job notices the presence of data_from_mallory while it it created,
renames it and replaces it with a symlink.

gzip will invoke chown on the symlink, thereby changing the permissions
on /projects/bar/secret_plan_for_world_domination to world-readable.

Eve's job removes the symlink and restores
/projects/foo/data_from_mallory. Alice thinks everything is ok.

Eve and Mallory read the secret_plan_for_world_domination and beat Alice
to it.

If gzip calls fchown before the file is closed, this doesn't work.

	hp

-- 
   _  | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in
|_|_) | Sysadmin WSR     \the source, and you might run into a memory leak if 
| |   | hjp@....ac.at     \you enable embedded haskell as a loadable module and
__/   | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae@....se

Content of type "application/pgp-signature" skipped