Pwn files with gzip?
September 13, 2007
My coworker, Oscar, mentioned to me this morning that gzip appeared to change ownership of files — even those not writable to the user! Puzzled, I tested the operation out.
[mshade@opteron ~]$ sudo touch test.txt
[mshade@opteron ~]$ ls -l test.txt
-rw-r--r-- 1 root root 0 Sep 13 09:33 test.txt
[mshade@opteron ~]$ gzip test.txt && gunzip test.txt.gz
[mshade@opteron ~]$ ls -l test.txt
-rw-r--r-- 1 mshade mshade 0 Sep 13 09:33 test.txt
[mshade@opteron ~]$
As you can see, I replaced root as the owner with myself, by zipping and unzipping the file. This assumes a couple of things:
- You must have read access to the file in question
- You must have write access to the current directory
Perhaps I’m ignorant of something here, but this doesn’t look like a good thing! I’ve tested this on CentOS 4.5, RHEL4 and MacOS X.
Thoughts?
Posted in blog entries
content rss
September 13th, 2007 at 9:53 am
Well, you have write permissions to the directory — what did you expect?
September 13th, 2007 at 9:55 am
I expected not to be able to take ownership of the file. Manipulating it any other way would throw a permission denied error, since it is owned by root. I only have read access to the *file*.
gzip apparently ignores that and will happily blow it away, and recreate it in your name.
For example, the following does not work:
cat test.txt |gzip|gunzip > test.txtThat throws a permission denied error.
September 13th, 2007 at 9:59 am
Makes perfect sense.
The original file’s directory entry was removed by the original gzip operation. No modification was made to the original file’s contents, so write access to the file was not required. Any program with an open handle on the original file will _still see_ the same original data.
Then you create a _new file_ with the same _name_ as the original by any method you happen to like. Now that new file which bears no relationship (other than name) to the original is owned by you. Any new file handles created on that file name now get the new file with your user’s content.
Security hole? Only if the sysadmin is clueless
September 13th, 2007 at 10:05 am
I see. This is the same as copying the file and using ‘unlink’ on the original, then renaming the file back with the desired name.
cp test.txt test.txt.new && unlink test.txt && mv test.txt.new test.txt
September 13th, 2007 at 10:05 am
Wow. This is pretty impressive. Something tells me this shouldn’t happen.
I can confirm it also works on Gentoo linux and Solaris 10.
September 13th, 2007 at 10:19 am
Here’s the deal.
This only works on directories you own. If you tried this same operation in a place where everyone has write access (like /var/tmp, /tmp, or /var/mail) it would fail.
We tested this on Solaris 10, but other UNIX/Linux variants may have a hole. I recommend testing this (a public writeable directory) on systems you are responsible for, just in case.
B
September 13th, 2007 at 10:24 am
BJones is absolutely correct, you need to own the directory to do this. And you don’t even need the gzip trick, you can just go right ahead and do:
$ sudo touch test
$ rm test
rm: test: override protection 644 (yes/no)? y
September 13th, 2007 at 10:26 am
Thanks for the explanations, guys. It makes perfect sense now — ownership of the current directory being the necessary prerequisite.
September 13th, 2007 at 10:26 am
The w permission on the directory allows you to remove the file and replace it from the one from the archive, belonging to you.
You’re obviously new to Unix.
September 13th, 2007 at 10:27 am
Not new to unix, but I’ve been pwned by this post
September 13th, 2007 at 10:29 am
BJones: it works on directory where you have the write permission. /tmp /var/tmp are special because of the sticky bit (rwxrwxrwt – notice the last t), the sticky bit restricts the w permission in that it forbids you to delete files from other users.
Come on guys, this is basic Unix !
September 13th, 2007 at 10:34 am
Yep
September 13th, 2007 at 12:03 pm
Thanks for the additional clarificatisn Bjones and Marc!
September 13th, 2007 at 3:03 pm
That throws an error because you’re trying to change the contents of a file you can’t write to. But you can write to the directory, so you can delete the file and put a new one in its place, which is all gzip is doing. Go ahead and try this:
cp test.txt foo; rm test.txt; mv foo test.txtand you’ll see the same effect.September 13th, 2007 at 3:05 pm
Heh I guess I had this window open a while before commenting…