Potential path traversal vulnerability through python tarfile.extractall in Kolla

[Clark Boylan]

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.extractall() on a carefully crafted tarball can potentially lead to remote execution.

Using https://codesearch.opendev.org I've identified Kolla as a potentially vulnerable code base. This block of code [2] in particular appears to extract archives without pre validation. I don't know enough about the Kolla codebase to say if this is problematic or not. I figured I would report this and someone who understands the code base can weigh in.

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://nvd.nist.gov/vuln/detail/CVE-2007-4559
[1] https://www.trellix.com/en-us/about/newsroom/stories/threat-labs/tarfile-exploiting-the-world.html
[2] https://opendev.org/openstack/kolla/src/branch/master/kolla/image/build.py#L431-L434
[3] https://opendev.org/openstack/ec2-api/src/branch/master/ec2api/api/image.py#L1059-L1067

[Sven Kieske (s-kieske)]

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:
+ if check_paths:
+ try:
+ self._check_path(tarinfo.name)
+ if tarinfo.islnk():
+ self._check_path(tarinfo.linkname)
+ if tarinfo.issym():
+ self._check_path(os.path.join(tarinfo.name, tarinfo.linkname))
+ 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
[1] https://bugzilla.redhat.com/show_bug.cgi?id=263261
[2] https://bugs.python.org/issue1044
[3] https://bugs.python.org/file8339/insecure_pathnames.diff
[4] https://stackoverflow.com/a/40311142
[5] https://hg.python.org/cpython/file/3.6/Lib/posixpath.py#l382

[Dr. Jens Harbott (j-harbott)]

IMO this whole thing is largely a non-issue. If someone can tamper the source tarballs that we install our software from, we have much more to worry about than path traversal.

[Sven Kieske (s-kieske)]

I took the assumption as a given, that the assumed trust boundary for kolla is, that it is expected to be secure to install untrusted tarballs.

if the security boundary for kolla is: don't trust tarballs, always check them or build them yourself, then this whole patch is moot or at best a simple hardening.

at the very least it would be good to document what the expected trust boundary is for the end user.

if we expect users to check tarballs or only use tarballs from trusted source we need to tell them that.

[Sven Kieske (s-kieske)]

I wrote to the security irc channel about it, especially since similar code might be used in other openstack projects to process untrusted tar files, which would be a problem.

as discussed in IRC, I tend to agree that you should not use untrusted tar files in the kolla context, because these are also used to install software so that would not be a good idea anyway.

it's up to the securityteam now.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/kolla/+/880186
Committed: https://opendev.org/openstack/kolla/commit/779aa83f4448df2ad4db7309cca496301b777ff8
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 779aa83f4448df2ad4db7309cca496301b777ff8
Author: Michal Nasiadka <email address hidden>
Date: Fri Mar 31 11:16:50 2023 +0000

    Fix test malicious tarball fail

    Since I650fcbc8f773fad8116338f6fb0cf7b4f4f17b33 builds from git fails
    on plugins with an exception: 'tarfile.ReadError: not a gzip file'
    because the test checks only gzip compressed archives but plugins
    created as plain tar files. This change fixes the issue using
    transparent compression support and also adds some debug info.

    Closes-Bug: #1990432
    Change-Id: If0f9b4dd058a257d0653332d1b663e150c717304
    Signed-off-by: Maksim Malchuk <email address hidden>
    Co-Authored-by: Michal Nasiadka <email address hidden>
    (cherry picked from commit 143765fb67221cc51f1dc56a41ac2b67dddc453f)
    (cherry picked from commit 5da2ff0828c7376a2f16a2673cd03420da038bca)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla 13.10.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla 16.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla 14.10.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla 15.2.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla wallaby-eol release.