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@xxxxxxxxx \you enable embedded haskell as a loadable module and __/ | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae@xxxxxx
Attachment:
pgpvyG7zOzHDU.pgp
Description: PGP signature