Unpatched 15-year old Python bug allows code execution in…

702 shares, 852 points

Unpatched 15-year old Python bug allows code execution in 350k projects (CVE-2007-4559)

Like it? Share with your friends!

702 shares, 852 points


Your email address will not be published.

  1. While I do believe that APIs should be save and sane by default, and the issue could be fixed better than just documenting it, I have several problems with (this kind of) article and the way it is written. The security research field is driven by impact and fame, which leads to a lot of click-bait or even maliciously exaggerated articles like these.

    **Never trust numbers you did not forge yourself**

    * They hand-picked 257 projects that are likely impacted, hand-checked 175 of them and found out that a high percentage (61%) is ‘impacted’. Surprise!
    * They do not define what ‘impacted’ means. Simply using this API does not mean it is exploitable. You have to feed untrusted data to it. Extracting trusted tar files is perfectly fine. So, the number of projects actually affected by this may be much lower, or even zero. We do not know.
    * They then used this strongly biased estimate of 61% and applied it to the total number (588,840) of all projects that merely import `tarfile`, without checking if these projects actually use the APIs in question! Lowering the bar to get a high number? This is again highly biased in favor of the authors.

    They basically checked how many sports cars get speeding tickets and applied that percentage to all cars ever created, including broken or scrapped cars no one drives anymore.

    **Path traversal != code execution**

    Yes you can overwrite executable files with this and hope that these are executed with enough privileges later on, but these are still two completely different error classes. CVE-2007-4559 may be used as a part of a code execution attack on a specific piece of software (targeted attack), but it is not a code execution flaw in itself. This is misleading, but the author knows that. Code execution just sounds scarier.

    **Dangerous APIs are everywhere, this does not imply vulnerability**

    Using an API that can potentially be misused does not make a project vulnerable. You need an application-specific attack vector (targeted attack) to actually cause harm. To execute code, you need to find a situation where *untrusted* data *you control* is fed into `tarfile.extractall()`, which is clearly documented as dangerous and should be rare. You also need to know the system well enough to find a file to overwrite that is run by a (privileged) user or script at some time and the user running the application needs write permissions to that file or folder.

    So, we are talking about a targeted attack against a (hypothetical, not actually presented) application that uses an API in a way that is clearly documented as dangerous. But it is sold as a major flaw in the python standard library that directly affects hundreds of thousands of projects. Again, this is highly exaggerated. I wonder why a security firm would write articles like that?

    Pythons `subprocess.run()` can run commands directly, not requiring the path traversal dance. A high percentage of projects that import `subprocess` also call `subprocess.run()`. Are all these projects in even greater danger now? I should become a ‘security researcher’!

  2. So wait, this thing got reported in 2007 and then everyone just… forgot? For an RCE in the standard library? WTF?

    I mean it’s not like Python was an understaffed little fringe project in 2007, either…

    edit: Okay, I get it now, the article is just clickbait bullshit. This isn’t a code execution vulnerability, it’s just tar archives behaving like tar archives do and people not understanding the risks of directory traversal.

  3. If you go into a dangerous neighbourhood with a stack of money you may end up leaving it barehanded? Damn, such an unfair world!

  4. Yes, opening untrusted files is a security risk. A lot of projects might import tarfile but do they all open untrusted files?

    Are they now seriously spamming all GitHub repos with pull requests? GitHub should ban them. They are not even talking modules, but random python projects.

  5. Love all the python devs. Anyone surprised?

    Maybe if we just add 45 more dependencies, everything will work itself out.

  6. How are you supposed to fix that, other than by sonehow verifying files beforehand or only using this on files you trust?

    Arguably it’s not the job of tarfile extraction to prevent incidental problems…

  7. Tomorrow, every small bank CTO who last did hands on tech work in the 90s bans Python and causes their company to fold under the weight of not actually being able to do anything meaningful with data.

  8. `libtar` exists since forever. Does this package uses it…? If yes, is `libtar` vulnerable? If not, if it is that python package own bug, then, putting Captain Obvious hat:

    * Don’t rewrite lightly

    * take fucking responsibility if you do; 15 years…?

  9. million eyeballs on open source code looked elsewhere for 15 years? I just ported inherited Python2 code to Python3 because Python2 End of life after 20 years “why don’t the needed packages install any more Pikachu”