Bug 263261 (CVE-2007-4559) - CVE-2007-4559 python: tarfile module directory traversal
Summary: CVE-2007-4559 python: tarfile module directory traversal
Keywords:
Status: NEW
Alias: CVE-2007-4559
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody
QA Contact:
URL: http://nvd.nist.gov/nvd.cfm?cvename=C...
Whiteboard:
Depends On: 315281 315291 2141077 2141078 2141079 2141080 2141081 2141082 2141083 2141084 2141085 2141086 2141317 2141318 2141319 2141320 2141321 2141322 2141323 2141324 2141325 2141326 2141327 2141328 2203890 2203905 2207691 2207692 2207715 2207997 2217897 2217902 2217916 2217917 2218233 2218234 2218235 2218237 2218240 2218241 2218243 2218246 2218247 2218248 2218249 2218267 2218274 2218275 2218277 2218870 2218873 2218875 2218876 2219388 2219407 2219408
Blocks: 2129409
TreeView+ depends on / blocked
 
Reported: 2007-08-29 13:17 UTC by Tomas Hoger
Modified: 2024-03-23 00:30 UTC (History)
37 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A flaw was found in the Python tarfile module. Extracting a crafted TAR archive with the tarfile.extract or tarfile.extractall functions could lead to a directory traversal vulnerability, resulting in overwrite of arbitrary files.
Clone Of:
Environment:
Last Closed: 2010-12-22 22:25:48 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Debian BTS 440097 0 None None None Never
Red Hat Product Errata RHBA-2023:6800 0 None None None 2023-11-08 09:36:08 UTC
Red Hat Product Errata RHSA-2023:6324 0 None None None 2023-11-07 08:12:54 UTC
Red Hat Product Errata RHSA-2023:6494 0 None None None 2023-11-07 08:18:20 UTC
Red Hat Product Errata RHSA-2023:6659 0 None None None 2023-11-07 08:22:24 UTC
Red Hat Product Errata RHSA-2023:6694 0 None None None 2023-11-07 08:22:40 UTC
Red Hat Product Errata RHSA-2023:6793 0 None None None 2023-11-08 08:17:10 UTC
Red Hat Product Errata RHSA-2023:6914 0 None None None 2023-11-14 15:16:05 UTC
Red Hat Product Errata RHSA-2023:7024 0 None None None 2023-11-14 15:18:45 UTC
Red Hat Product Errata RHSA-2023:7034 0 None None None 2023-11-14 15:19:11 UTC
Red Hat Product Errata RHSA-2023:7050 0 None None None 2023-11-14 15:19:21 UTC
Red Hat Product Errata RHSA-2023:7151 0 None None None 2023-11-14 15:22:08 UTC
Red Hat Product Errata RHSA-2023:7176 0 None None None 2023-11-14 15:22:19 UTC
Red Hat Product Errata RHSA-2024:0374 0 None None None 2024-01-23 17:24:45 UTC
Red Hat Product Errata RHSA-2024:0430 0 None None None 2024-01-24 16:49:30 UTC
Red Hat Product Errata RHSA-2024:0587 0 None None None 2024-01-30 13:25:23 UTC

Description Tomas Hoger 2007-08-29 13:17:48 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2007-4559
to the following vulnerability:

Directory traversal vulnerability in the (1) extract and (2) extractall
functions in the tarfile module in Python allows user-assisted remote attackers
to overwrite arbitrary files via a .. (dot dot) sequence in filenames in a TAR
archive, a related issue to CVE-2001-1267.

References:

Issue and additional attack vectors were discussed in following thread on
python-dev mailinglist:

http://mail.python.org/pipermail/python-dev/2007-August/074290.html

Upstream bug tracking possible fixes for the issue:

http://bugs.python.org/issue1044

Comment 1 James Antill 2007-08-29 14:34:50 UTC
 Ok, so they seem confused about whether they wanted to fix anything or just
define what it currently does as "correct".
 Also the patches they are proposing only "fix" paths in a tarfile prefixed with
"../" or "/" ... they are trying to fix the symlink attacks by just checking the
result of the link (which is very different from what GNUtar does).
 And I'm not sure that's all of the known tar attacks, is it?

 Summary:

. symlinks linking to just ".." work (can be used repeatedly to walk up the tree).
. symlinks pointing to absolute paths can't be used.
. path checking doesn't check for either "./../foo" or "xyz/../../foo" type attacks.
. failure against the security checks results in an exception being thrown.
. I'm pretty sure self._check_path(os.path.join(tarinfo.name, tarinfo.linkname))
is wrong, I think they meant "current path inside the tarfile" not "path of
symlink" ... so that "foo.html -> ../src/foo.html" works if the link is in a
docs directory.


Comment 2 Tomas Hoger 2007-08-30 14:34:07 UTC
James, thanks for feedback.

I've re-checked list of directory traversal vulnerabilities reported against tar
in past few years.  Not very surprisingly, reported attack vectors use either
absolute paths or paths with '..'s.  Such path can be used in file/directory
name or in (directory) symlink.  Additionally, there were some issues specific
to implementation of the checks ('/../' detected correctly, but not '//../').


. symlinks linking to just ".." work (can be used repeatedly to walk up the tree).

Good point.  You seem to be right with that.

. symlinks pointing to absolute paths can't be used.

All "suspicious" symlinks are ignored / not extracted.

. path checking doesn't check for either "./../foo" or "xyz/../../foo" type attacks.

It does.  Patch is using normpath() to normalize paths, hence both of your
example paths get normalized to: ../foo and are tested after normalization.

. I'm pretty sure self._check_path(os.path.join(tarinfo.name, tarinfo.linkname))
is wrong, I think they meant "current path inside the tarfile" not "path of
symlink" ... so that "foo.html -> ../src/foo.html" works if the link is in a
docs directory.

Yes, that part seems to be incorrect...  I assume tarinfo.name is
dir/in/tarfile/symlink.  So in your example tarinfo.name would be docs/foo.html
and join + normpath would yield docs/src/foo.html ... not correct.


Current upstream opinion seems to be that module's behavior conforms to
standards and it just should not be used to extract archives from untrusted sources.


Comment 3 James Antill 2007-09-04 14:57:04 UTC
> . symlinks pointing to absolute paths can't be used.
> All "suspicious" symlinks are ignored / not extracted.

Right, it's just I could see it being "common" to have symlinks to /home/* or
/var/*. So people might treat that as a regression. But, yeh, it's also possible
people have a use for tarfiles with symlinks to ../foo in them.

> . path checking doesn't check for either "./../foo" or "xyz/../../foo" type
attacks.
> It does.  Patch is using normpath()

 Ahh, my bad, I don't see how that can do the right thing in the general case
but it'll be secure :).

> Current upstream opinion seems to be that module's behavior conforms to
standards and it just should not be used to extract archives from untrusted sources.

 Fair enough, I'm not sure we should care anymore than upstream then (although
maybe maybe more specifically say don't use the module with any tarfiles you
haven't created).


Comment 4 Tomas Hoger 2007-09-18 14:46:34 UTC
Upstream bug report resolved with following update to documentation:

Never extract archives from untrusted sources without prior inspection.
It is possible that files are created outside of 'path', e.g. members
that have absolute filenames starting with "/" or filenames with
two dots "..".


There probably not much we can do without diverging significantly from upstream
version.

Comment 6 Vincent Danen 2010-12-22 22:25:48 UTC
Upstream has resolved this issue (http://bugs.python.org/issue1044#msg55464):

"After careful consideration and a private discussion with Martin I do no
longer think that we have a security issue here. tarfile.py does nothing
wrong, its behaviour conforms to the pax definition and pathname
resolution guidelines in POSIX. There is no known or possible practical
exploit.

I update the documentation with a warning, that it might be dangerous to
extract archives from untrusted sources. That is the only thing to be
done IMO."

And the documentation "fix":

http://svn.python.org/view/python/trunk/Doc/library/tarfile.rst?r1=57764&r2=57763&pathrev=57764

If upstream does not feel this is a security issue, as stated in comment #4, neither should we.

Comment 7 Guilherme de Almeida Suckevicz 2022-11-08 17:21:28 UTC
Due to recent media attention about this vulnerability upstream is considering fixing this issue.

Upstream discussion about the fix: https://github.com/python/cpython/issues/73974

Comment 8 Guilherme de Almeida Suckevicz 2022-11-08 17:25:39 UTC
Created mingw-python3 tracking bugs for this issue:

Affects: fedora-all [bug 2141078]


Created python2.7 tracking bugs for this issue:

Affects: fedora-all [bug 2141079]


Created python3.10 tracking bugs for this issue:

Affects: fedora-all [bug 2141084]


Created python3.11 tracking bugs for this issue:

Affects: fedora-all [bug 2141085]


Created python3.12 tracking bugs for this issue:

Affects: fedora-all [bug 2141086]


Created python3.6 tracking bugs for this issue:

Affects: fedora-all [bug 2141080]


Created python3.7 tracking bugs for this issue:

Affects: fedora-all [bug 2141081]


Created python3.8 tracking bugs for this issue:

Affects: fedora-all [bug 2141082]


Created python3.9 tracking bugs for this issue:

Affects: fedora-all [bug 2141083]


Created python34 tracking bugs for this issue:

Affects: epel-all [bug 2141077]

Comment 17 Petr Viktorin (pviktori) 2023-02-27 17:12:57 UTC
I've posted a technical solution for upstream approval: https://peps.python.org/pep-0706/
(It is important, in the long term, that this is coordinated with the larger Python ecosystem.)

For RHEL we're planning additional (system-specific) ways to configure the default. Refusing to unpack some (potentially dangerous) tarballs is, obviously, a behavior change, so there's a trade-off between security vs. backwards compatibility.

Comment 37 errata-xmlrpc 2023-11-07 08:12:51 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:6324 https://access.redhat.com/errata/RHSA-2023:6324

Comment 38 errata-xmlrpc 2023-11-07 08:18:17 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:6494 https://access.redhat.com/errata/RHSA-2023:6494

Comment 39 errata-xmlrpc 2023-11-07 08:22:20 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:6659 https://access.redhat.com/errata/RHSA-2023:6659

Comment 40 errata-xmlrpc 2023-11-07 08:22:37 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:6694 https://access.redhat.com/errata/RHSA-2023:6694

Comment 41 errata-xmlrpc 2023-11-08 08:17:08 UTC
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7

Via RHSA-2023:6793 https://access.redhat.com/errata/RHSA-2023:6793

Comment 42 errata-xmlrpc 2023-11-14 15:16:02 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:6914 https://access.redhat.com/errata/RHSA-2023:6914

Comment 43 errata-xmlrpc 2023-11-14 15:18:40 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:7024 https://access.redhat.com/errata/RHSA-2023:7024

Comment 44 errata-xmlrpc 2023-11-14 15:18:41 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:7024 https://access.redhat.com/errata/RHSA-2023:7024

Comment 45 errata-xmlrpc 2023-11-14 15:19:08 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:7034 https://access.redhat.com/errata/RHSA-2023:7034

Comment 46 errata-xmlrpc 2023-11-14 15:19:18 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:7050 https://access.redhat.com/errata/RHSA-2023:7050

Comment 47 errata-xmlrpc 2023-11-14 15:22:05 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:7151 https://access.redhat.com/errata/RHSA-2023:7151

Comment 48 errata-xmlrpc 2023-11-14 15:22:15 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:7176 https://access.redhat.com/errata/RHSA-2023:7176

Comment 55 errata-xmlrpc 2024-01-23 17:24:41 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.6 Extended Update Support

Via RHSA-2024:0374 https://access.redhat.com/errata/RHSA-2024:0374

Comment 56 errata-xmlrpc 2024-01-24 16:49:27 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.6 Extended Update Support

Via RHSA-2024:0430 https://access.redhat.com/errata/RHSA-2024:0430

Comment 57 errata-xmlrpc 2024-01-30 13:25:20 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.8 Extended Update Support

Via RHSA-2024:0587 https://access.redhat.com/errata/RHSA-2024:0587

Comment 60 Fedora Update System 2024-03-16 01:51:12 UTC
FEDORA-2024-ebb3c95344 (python3.6-3.6.15-27.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 63 Fedora Update System 2024-03-23 00:30:54 UTC
FEDORA-2024-46374d2703 (python3.6-3.6.15-27.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.