Directory traversal vulnerability in Archive::Tar perl module allows
user-assisted remote attackers to overwrite arbitrary files writable by user
running application using this module via an absolute path or a .. (dot dot)
sequence in filenames in a TAR archive.
Similar issues were reported and fixed for GNU tar during past several years,
e.g.: CVE-2001-1267, CVE-2002-0399, CVE-2002-1216 and CVE-2007-4131.
This issue is important when this module is used to extract tar archives from
untrusted sources. However, some of such applications either implement
workarounds / own checks (sa-update in spamassassin) or dropped module support
at all (amavisd-new).
Similar issue was reported for Python's tarfile module, see #263261.
Upstream bug report:
Is there any chance this will get addressed for fedora?
Once we have a fix for it, that fix will go into all supported versions of
fedora ASAP. We don't have a fix yet, though.
The Archive::Tar 1.38 is now available on CPAN, with the following in CHANGES:
* important changes in vesrion 1.38 14/12/2007:
- Promote 1.37_01 to stable.
* important changes in version 1.37_01 11/11/2007:
_ Address #30380: directory traversal vulnerability in Archive-Tar
- Add $INSECURE_EXTRACT_MODE which defaults to 0, disallowing
archives to extract files outside of cwd(). This is a backwards
incompatible change from 1.36 and before.
- Add a -I option to ptar to enable insecure extraction if needed
So using this version in Fedoras seems like a way to to go. The diff from 1.34
(which we have in F8 and rawhide) and 1.36 is VMS specific, and diff from 1.36
to 1.38 is exactly fix for this bugzilla, so it should be safe to rebase.
Hmmm. Should I put this note to release-specific bugzillas?
Sadly, upstream version 1.38 is still prone to the directory traversal attack
using symlinks, as described in old Willy Tarreau's BugTraq post:
That problem was already pointed out in the upstream bug report.
You are right. I should have said "diff from 1.36 to 1.38 is a partial fix for
this bugzilla and not other changes".
Is it better to wait for definitive fix, or close that one hole that 1.38
addresses, for the time being?
Maintainers; could you please punch upstream about this a bit? In case not, what
about applying Mirek's patch referred to in comment $11?
(In reply to comment #12)
> Maintainers; could you please punch upstream about this a bit? In case not, what
> about applying Mirek's patch referred to in comment $11?
Sorry, Mirek's patch does not resolve the issue.
This should now be fixed upstream.
1.40 does following to cover known vectors:
- absolute paths are rejected
- all paths that include '..' as one of the elements are rejected
- extracting to symlink directories is denied
(applies to default SECURE EXTRACT MODE)
perl-Archive-Tar is now core perl module (as of perl 5.10 / F9, iirc), so Fedora updates will have to go via perl update.
rhel5 is still vulnerable...
perl-5.10.0-52.fc10 has been submitted as an update for Fedora 10.
perl-5.10.0-52.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 514322 has been marked as a duplicate of this bug. ***
I'd like to point out that perl-Archive-Tar-1.30-1.fc6 which is in rhel5 is still vulnerable as of rhel-5.5.
We had provided an NVD statement for this regarding Red Hat Enterprise Linux 5:
It should have been noted here as well, however.
The Red Hat Security Response Team does not consider this bug to be a security issue. It is not suggested behavior to extract archives from untrusted sources without prior inspection of the archive contents.
Raising priority here to make sure perl-Archive-Tar versions in RHEL4 and RHEL5 are update to address this issue.
This flaw in perl-Archive-Tar did not affect other components shipped in RHEL using this perl module, as extract() method is not used.
It should also be noted that update Archive::Tar may fail to extract certain non-standard, but non-malicious archives that use one of the restricted paths or links (see comment #16), but don't attempt to leave current working directory during the archive extraction.
This issue has been addressed in following products:
Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 4
Via RHSA-2010:0505 https://rhn.redhat.com/errata/RHSA-2010-0505.html