Potential path traversal vulnerability through python tarfile.extractall in Kolla
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kolla |
Fix Released
|
Medium
|
Michal Nasiadka | ||
Antelope |
Fix Released
|
Medium
|
Michal Nasiadka | ||
Wallaby |
Fix Released
|
Undecided
|
Unassigned | ||
Xena |
Fix Released
|
Undecided
|
Unassigned | ||
Yoga |
Fix Released
|
Undecided
|
Unassigned | ||
Zed |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
CVE-2007-4559 [0] is getting new attention as new exploits that take advantage of it have been found [1]. Long story short is that calling tarfile.
Using https:/
Even if the risk ends up being low, addressing this isn't too difficult. Nova took this approach [3] which ended up being adopted by ec2-api when that code base moved.
[0] https:/
[1] https:/
[2] https:/
[3] https:/
CVE References
Changed in kolla: | |
importance: | Undecided → Medium |
Changed in kolla: | |
assignee: | nobody → Michal Nasiadka (mnasiadka) |
status: | New → Triaged |
information type: | Private Security → Public Security |
Mhm, so I took a look at this.
The source of this CVE in this bugtracker[0] links to this [1] redhat bugzilla, which finally links to the original bugreport [2] at python.org.
Somehow this upstream bugreport [2] is neither mentioned here on launchpad, nor at the nist site, nor on the above linked site "trellix.com" where the vulnerability was apparently exploited by using relative pathnames like "abc/../def"
However, if we look at the upstream bugreport 1044 at python.org we find the following:
tarfile does not check pathnames or linknames on extraction. This can
lead to data loss or attack scenarios when members with absolute
pathnames or pathnames outside of the archive's scope overwrite or
overlay existing files or directories.
Example for a symlink attack against /etc/passwd:
foo -> /etc
foo/passwd
and the patch in python explicitly checks for symlinks as well[3]:
@@ -2019,6 +2023,20 @@
members = self
for tarinfo in members: path(tarinfo. name) path(tarinfo. linkname) path(os. path.join( tarinfo. name, tarinfo.linkname))
+ if check_paths:
+ try:
+ self._check_
+ if tarinfo.islnk():
+ self._check_
+ if tarinfo.issym():
+ self._check_
+ except SecurityError, e:
+ if self.errorlevel > 1:
+ raise
+ else:
+ self._dbg(1, "tarfile: %s" % e)
+ continue
as stated on stackoverflow[4] the used method in kolla to check the pathname, namely "os.path.abspath" does not check if a path is a symbolic link.
you have to use realpath for that[5], which, as a bonus, calls abspath after resolving symbolic links.
So I _hope_ using realpath is enough here, but I'm no low level python expert and I don't understand the upstream solution well enough, so I would appreciate if someone else also takes a look and can verify that this is enough.
Also the tests should probably somehow mock what the upstream regression tests do, but I'm also not really familiar with python.orgs testsuite and how easy it would be to transfer these symlink security tests to kolla.
[0] https:/ /nvd.nist. gov/vuln/ detail/ CVE-2007- 4559 /bugzilla. redhat. com/show_ bug.cgi? id=263261 /bugs.python. org/issue1044 /bugs.python. org/file8339/ insecure_ pathnames. diff /stackoverflow. com/a/40311142 /hg.python. org/cpython/ file/3. 6/Lib/posixpath .py#l382
[1] https:/
[2] https:/
[3] https:/
[4] https:/
[5] https:/