Full Disclosure mailing list archives
Re: Re: tar alternative
From: Tim <tim-security () sentinelchicken org>
Date: Sat, 9 Sep 2006 11:47:36 -0400
What tar are you using? With every tarball I download the files within are given the owner:group of the user I extract them as. I have never seen a developer's username or group disclosed...
Yes, as a normal user, you can't create files locally owned by another user, so they aren't, but the username/group are indeed in the tar file.
From a couple of tarballs I have lying around my system:
me@localhost:/usr/local/src> tar tjvf nmap-3.50.tar.bz2 drwxr-xr-x fyodor/fyodor 0 2004-01-18 22:04 nmap-3.50/ -rw-r--r-- fyodor/fyodor 15318 2003-09-10 22:12 nmap-3.50/main.cc -rw-r--r-- fyodor/fyodor 75134 2003-12-01 20:09 nmap-3.50/nmap.cc -rw-r--r-- fyodor/fyodor 50952 2003-09-16 02:04 nmap-3.50/targets.cc -rw-r--r-- fyodor/fyodor 67425 2003-09-20 05:03 nmap-3.50/tcpip.cc -rw-r--r-- fyodor/fyodor 7490 2003-09-10 22:12 nmap-3.50/nmap_error.cc -rw-r--r-- fyodor/fyodor 22068 2003-09-10 22:12 nmap-3.50/utils.cc -rw-r--r-- fyodor/fyodor 41675 2003-09-10 22:12 nmap-3.50/idle_scan.cc -rw-r--r-- fyodor/fyodor 68759 2003-09-10 22:12 nmap-3.50/osscan.cc -rw-r--r-- fyodor/fyodor 46270 2003-12-18 16:42 nmap-3.50/output.cc -rw-r--r-- fyodor/fyodor 71462 2003-12-01 20:09 nmap-3.50/scan_engine.cc ... and me@localhost:/usr/local/src> tar tzvf wget-1.9.1.tar.gz drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/ drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/doc/ drwxr-xr-x hniksic/hniksic 0 2003-11-11 18:42 wget-1.9.1/doc/ChangeLog-branches/ -rw-r--r-- hniksic/hniksic 12928 2001-01-06 04:26 wget-1.9.1/doc/ChangeLog-branches/1.6_branch.ChangeLog -rw-r--r-- hniksic/hniksic 23252 2003-11-08 18:46 wget-1.9.1/doc/ChangeLog -rw-r--r-- hniksic/hniksic 4854 2003-10-23 18:53 wget-1.9.1/doc/Makefile.in -rw-r--r-- hniksic/hniksic 1529 2003-10-04 06:34 wget-1.9.1/doc/ansi2knr.1 -rw-r--r-- hniksic/hniksic 4022 2001-11-30 02:32 wget-1.9.1/doc/sample.wgetrc ...
Sure they are important. Would you want to manually chmod +x all executables and scripts? Manually chmod +r all documentation? Even stipulating that we could use the umask value to decide permissions it is still a PITA.
Using umask is perfectly fine, except in the case of executables, so that is a good point.
This can be mitigated if you don't blindly extract tarballs as root, and you only extract in safe locations. If you unpack stuff to '/' you deserve to hose your system.
Well, personally, I think it's just a joke that I can't extract the contents of an archive as root and feel safe. I mean, think about it for a second... It's not like I'm downloading a random executable and running it without some trust. Sure, you shouldn't run programs unnecessarily as root. That goes for any program, but that's a precaution that's supposed to prevent unforseen vulnerabilities, and shouldn't be needed to work around braindead default behavior. It's like saying: never open emails from people you don't know. Yeah, it might be a good idea, but it's a total failure of the software involved to rely on that recommendation for security. Now, beyond the root user issue, isn't it true that if I untar a malicious archive as a normal user, that my own files could be squashed too? If I always unpack source files in ~/src as a normal user, and compile them in their own subdirectories as my own user, I could still be at risk if I'm not careful. Suppose one day, I unpack foo-0.1.tar.gz to the directory ~/src/foo-0.1. Then, the next day I download bar-0.1.tar.gz, which I don't really trust. I just want to unpack it and take a look at the source before I compile and install. So, I untar it in ~/src. Let's suppose bar-0.1.tar.gz contains the following files: bar-0.1/ foo-0.1/evil.c bar-0.1/benign.c ... So, this could inject evil code into my other program. If I were naive enough to extract an archive in my home directory, my .profile could receive a lovely shellcode.
True, some boneheads don't package their stuff in a top-level directory potentially overwriting existing files in the pwd. Perhaps the GNU folks should add a 'noclobber' option....
Yes, I guess what I just described is what you were getting at. noclobber would be great and all, except not all archive extractors would behave this way, and if noclobber isn't the default, it will leave new users vulnerable. I just think it would be better to have a format that makes it easy to enforce a top level directory for all files, and removes the leaks mentioned above. I've searched around since my first posting, and I've yet to find one, unfortunately. cheers, tim _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Linux kernel source archive vulnerable, (continued)
- Re: Linux kernel source archive vulnerable Gerald (Jerry) Carter (Sep 08)
- Re: Linux kernel source archive vulnerable Hadmut Danisch (Sep 08)
- Re: Re: Linux kernel source archive vulnerable Michael Gale (Sep 08)
- Re: Re: Linux kernel source archive vulnerable Valdis . Kletnieks (Sep 09)
- Re: Linux kernel source archive vulnerable Ron (Sep 24)
- Re: Re: Linux kernel source archive vulnerable Jurjen Oskam (Sep 08)
- tar alternative Tim (Sep 08)
- Re: tar alternative Cristi Mitrana (Sep 08)
- Re: Re: tar alternative Tim (Sep 09)
- Re: Re: tar alternative darren kirby (Sep 09)
- Re: Re: tar alternative Tim (Sep 09)
- Re: tar alternative Aaron Gray (Sep 15)
- Re: tar alternative Tim (Sep 20)
- Re: tar alternative Jon Hart (Sep 20)
- Re: tar alternative Tonnerre Lombard (Sep 20)
- Re: Linux kernel source archive vulnerable Joe Feise (Sep 11)
- Re: Linux kernel source archive vulnerable coderpunk (Sep 12)
- Re: Re: Linux kernel source archive vulnerable Chris Umphress (Sep 12)
- Re: Linux kernel source archive vulnerable Schanulleke (Sep 15)
- Re: Linux kernel source archive vulnerable Troy Cregger (Sep 22)