Skip Menu |
 

This queue is for tickets about the Archive-Tar CPAN distribution.

Report information
The Basics
Id: 30380
Status: resolved
Priority: 0/
Queue: Archive-Tar

People
Owner: Nobody in particular
Requestors: anicka [...] suse.cz
smithj [...] freethemallocs.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Archive::Tar cannot handle extracted files securely
Date: Thu, 20 Sep 2007 19:59:11 +0200
To: bug-archive-tar [...] rt.cpan.org
From: Anicka Bernathova <anicka [...] suse.cz>
Download (untitled) / with headers
text/plain 1018b
Hello, this is a feature request more than a bugreport: Archive::Tar does not take any care for controlling whether the extracted files leave the current directory or not. It is willing to try to rewrite any files in the system by extracting archived files with absolute paths, following any archived symlinks and so on. This is usually considered a security problem and ie. GNU tar has many fixes to avoid this behavior. Are you willing to add some switch to enable a secure way of handling the extracted files in Archive::Tar too? I will gladly help with implementation, if you find it worth of doing. Thanks! -- Best Regards, Anna Bernathova, software developer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: anicka@suse.cz Lihovarska 1060/12 tel: +420 2 9654 2375 190 00 Praha 9 fax: +420 2 8309 5374 Czech Republic http://www.suse.cz
Download (untitled) / with headers
text/plain 1015b
Hi Anna, On Thu Sep 20 13:59:25 2007, anicka@suse.cz wrote: Show quoted text
> Archive::Tar does not take any care for controlling whether the > extracted files leave the current directory or not. It is willing to try > to rewrite any files in the system by extracting archived files with > absolute paths, following any archived symlinks and so on. > > This is usually considered a security problem and ie. GNU tar has many > fixes to avoid this behavior. Are you willing to add some switch to > enable a secure way of handling the extracted files in Archive::Tar too? > > I will gladly help with implementation, if you find it worth of doing.
Thanks for your suggestion -- you're indeed correct that A::T doesn't do any special handling of files to prevent them from leaving the current directory. To add a switch that enables this safety feature sounds like a valuable feature and one I'm interested in adding. If you have a patch or an idea on how to approach this, I'm happy to discuss this with you. Kind regards, Jos
Subject: directory traversal vulnerability in Archive-Tar
Date: Tue, 30 Oct 2007 18:37:37 -0800
To: bug-Archive-Tar [...] rt.cpan.org
From: Jonathan Smith <smithj [...] freethemallocs.com>
Download (untitled) / with headers
text/plain 740b
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 rPath is tracking an issue from awhile back [1] where perl-Archive-Tar can be coerced via a specially-crafted tar file to overwrite arbitrary files on the system, a security issue. I think we missed contacting you (many programs were affected) but as I'm not familiar with the codebase, your help in formulating a fix and including that fix in the next release would be appreciated. [1]: https://issues.rpath.com/browse/RPL-1716 smithj -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJ+m/CG91qXPaRekRAuvEAJ9Xjbc/d+UkEKjlJFkqzhYUc/horQCgjyYm /GyGdY19g8fg4J0fBheMsOQ= =QzPL -----END PGP SIGNATURE-----
Download (untitled) / with headers
text/plain 677b
On Tue Oct 30 22:44:05 2007, smithj@freethemallocs.com wrote: Show quoted text
> rPath is tracking an issue from awhile back [1] where perl-Archive-Tar > can be coerced via a specially-crafted tar file to overwrite arbitrary > files on the system, a security issue. I think we missed contacting you > (many programs were affected) but as I'm not familiar with the codebase, > your help in formulating a fix and including that fix in the next > release would be appreciated.
Thanks for bringing this to my attention. A similar report was made a few weeks ago (but seemingly unrelated to rPath) here: https://rt.cpan.org/Ticket/Display.html?id=29517 We'll take this issue under advisement.
Download (untitled) / with headers
text/plain 937b
Greetings, On Tue Oct 30 22:44:05 2007, smithj@freethemallocs.com wrote: Show quoted text
> rPath is tracking an issue from awhile back [1] where perl-Archive-Tar > can be coerced via a specially-crafted tar file to overwrite arbitrary > files on the system, a security issue. I think we missed contacting you > (many programs were affected) but as I'm not familiar with the codebase, > your help in formulating a fix and including that fix in the next > release would be appreciated. > > [1]: https://issues.rpath.com/browse/RPL-1716
I have just uploaded a development version of Archive::Tar [1] to CPAN, which should address this is issue. It may take a little while untill it has propagated around the CPAN mirrors. Please let me know if this addresses the issue fully, and we'll release it as a stable version and merge it back into the perl core. Thanks again for reporting, Jos Boumans [1] http://search.cpan.org/~kane/Archive-Tar-1.37_01/
Subject: Re: [rt.cpan.org #30380] directory traversal vulnerability in Archive-Tar
Date: Wed, 21 Nov 2007 11:05:32 +0100
To: bug-Archive-Tar [...] rt.cpan.org
From: Anna Bernathova <anicka [...] suse.cz>
Show quoted text
> Please let me know if this addresses the issue fully, and we'll release it > as a stable version and merge it back into the perl core. > > Thanks again for reporting,
Hello, the problem with absolute paths in filenames and directory traversal seems to be fixed, many thanks. But there is one more related, very similar issue, which has not been addressed yet. If you run: rm -rf dir && mkdir dir && ln -s .//..//..//..//..//..//..//..//..//..//..//etc dir/subdir && tar -cf dir.tar --numeric-owner --owner=0 --group=0 dir/subdir dir/subdir/passwd and then use Archive::Tar; my $tar = Archive::Tar->new($ARGV[0]); $tar->extract(); on your archive, you will get attempt to rewrite /etc/passwd: mkdir("/tmp/wtf/dir", 0777) = 0 symlink("./../../../../../../../../etc", "/tmp/wtf/dir/subdir") = 0 ... open("/tmp/wtf/dir/subdir/passwd", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied) I have played with a possible ways to fix this second issue and it seems that the only way to fix is to remember all the symlinks you create when deciding which ones to follow. Anicka
Subject: Re: [rt.cpan.org #30380] directory traversal vulnerability in Archive-Tar
Date: Fri, 22 Feb 2008 15:26:56 +0100
To: bug-Archive-Tar [...] rt.cpan.org
From: Lubomir Kundrak <lkundrak [...] redhat.com>
Download (untitled) / with headers
text/plain 1.7k
Anicka: Having a file in a tarball, not its parent directory, but a symlink named as its parent directory is by no means sane and useful. I would expect attempt extract from such archive to fail with an error about nonexistent path to the destination file. Show quoted text
> I have played with a possible ways to fix this second issue and it seems > that the only way to fix is to remember all the symlinks you create when > deciding which ones to follow.
You know it doesn't sound well. Possible resolution is not to follow symlinks while extracting (it's not useful, see first paragraph). That would be done like this: --- /usr/lib/perl5/vendor_perl/5.8.8/Archive/Tar.pm.orig 2008-02-22 15:22:05.000000000 +0100 +++ /usr/lib/perl5/vendor_perl/5.8.8/Archive/Tar.pm 2008-02-22 15:21:28.000000000 +0100 @@ -595,7 +595,7 @@ sub _extract_file { if( length $entry->type && $entry->is_file ) { my $fh = IO::File->new; - $fh->open( '>' . $full ) or ( + $fh->open( '>' . $full, O_NOFOLLOW ) or ( $self->_error( qq[Could not open file '$full': $!] ), return ); Note that the same would need to be done for directories and special files too. Currently it's probably not a good idea, as it would break extraction if working directory path contained a symlink due to the code below (note that I haven't tried that nor read that extensively, I might be wrong): 549 my $cwd = (defined $self->{cwd} ? $self->{cwd} : cwd()); 550 my @dirs = File::Spec::Unix->splitdir( $dirs ); 551 my @cwd = File::Spec->splitdir( $cwd ); 552 $dir = File::Spec->catdir( @cwd, @dirs ); Is something wrong with nofollow approach? -- Lubomir Kundrak (Red Hat Security Response Team)
From: msuchy [...] redhat.com
Download (untitled) / with headers
text/plain 919b
Dne pá 22.úno.2008 09:27:20, lkundrak@redhat.com napsal(a): Show quoted text
> + $fh->open( '>' . $full, O_NOFOLLOW ) or (
.. Show quoted text
> Is something wrong with nofollow approach?
No. But if you use mode (O_NOFOLLOW) in open, then '>' is not interpreted. So correct patch should be: --- Archive-Tar-1.38.orig/lib/Archive/Tar.pm 2007-12-14 13:33:55.000000000 +0100 +++ Archive-Tar-1.38/lib/Archive/Tar.pm 2008-03-18 15:03:55.000000000 +0100 @@ -650,7 +650,7 @@ if( length $entry->type && $entry->is_file ) { my $fh = IO::File->new; - $fh->open( '>' . $full ) or ( + $fh->open( $full, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_NOFOLLOW ) or ( $self->_error( qq[Could not open file '$full': $!] ), return ); Although still remain the 'open' on line 255, which create tgz. But I think it is safe to leave this unchecked, becouse with this you can not create normal files.
Download (untitled) / with headers
text/plain 540b
I've just uploaded 1.39_01, which should address the second part of this issue. Unfortunately, O_FOLLOW can't be used, as it's not portable, but i've implemented a fix on the code level with the same intention. From the changes file: * important changes in version 1.39_01 22/08/2008: - Address the second part mentioned in this report: #30380: directory traversal vulnerability in Archive-Tar Archives are no longer allowed to extract into symlinked directories, unless Insecure Extract Mode is enabled (which is off by default).


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.