FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Fix Path Traversal in multissltests.py · Issue #138158 · python/cpython · GitHub

Repository navigation

Fix Path Traversal in multissltests.py #138158

Closed

Description

Tools/ssl/multissltests.py suffers from a possible Path Traversal attack. The vulnerability allows for a crafted tarball to write an arbitrary file to a location outside of the intended build directory due to a lack of sanitization in the _unpack_src() method's handling of tarball member names.

A comprehensive, self-contained PoC script was used to demonstrate the issue (and shared with the Python Security Response Team, henceforth PSRT), confirming the Path Traversal. The fix implemented in this PR ensures that each tarball member is manually extracted with a path check, preventing any file from escaping the designated directory. This approach provides a clear and robust solution to the issue.

As this is a test script, and not a production component, the PSRT has advised me to submitt it as a public enhancement. This fix ensures the integrity and robustness of the tool, by preventing an unprivileged file write that could lead to unexpected behavior.

I am submitting this enhancement to improve the overall quality of the CPython test suite. If necessary, I'm available to provide any additional information required for review.

PoC: https://github.com/ParzivalHack/PT-PoC.

Linked PRs

Activity

  1. picnixz commented on Aug 30, 2025

    Member

    I'm forwarding my rationale for accepting this issue:

    I thought about this a lot, because I originally didn't want un-necessary churn, even if it's helpful. However, it's actually possible for the user to skip the download part and directly specify a directory where the lib sources are. So, assuming that this directory is untrusted, it's entirely possible to have a bad archive out there. The attack surface is really small as this requires executing the script in a non-standard way, but I think it's a legitimate improvement.

    Now, in Python 3.14 and later, the data filter is the default, but if PYTHON_FOR_REGEN is Python 3.13 or below, then it won't be the default. I'm not sure whether we should backport this up to 3.9 because there might be users (downstream distros?) relying on this script but that don't download remote sources in an offline environment (and the sources are shipped in the installation disk for instance, I don't know). Anyway, for now, I'm only planning to backport this up to 3.13.

  2. added a commit that references this issue on Aug 30, 2025
  3. added 2 commits that reference this issue on Aug 30, 2025
  4. picnixz commented on Aug 30, 2025

    Member

    We could theoretically backport this up to 3.9 but I don't think I'm going to do it. The vulnerabililty is too theoretical to be considered as a true security issue IMO, but maybe the PSRT has something else to say here.

    @sethmlarson AFAICT, it's possible to make something bad here, but it's a test-only script so, unless downstream distributions are worried about this, I don't think it's necessary to commit more stuff to security-only branches for this one, but if you want to do it, feel free to add the backport labels on the PR.

  5. added a commit that references this issue on Aug 30, 2025
  6. added
    type-refactorCode refactoring (with no changes in behavior)
    and removed on Aug 30, 2025
  7. sethmlarson commented on Aug 30, 2025

    Contributor

    Yeah this isn't a security issue (and we discussed that in PSRT). Doesn't need to be backported, either, as it doesn't make tests any more reliable/passing. Just a nice to have into the future!

  8. picnixz commented on Aug 30, 2025

    Member

    Oh I already backported it to 3.13. Should I revert it? (3.14 backport is not yet merged). Should we still merge the 3.14 backport? (by backports in my previous comment, I meant the 3.9 to 3.12 ones)

  9. zware commented on Aug 30, 2025

    Member

    I don't think it's worth reverting or backporting further, but the 3.14 PR should be merged eventually just to avoid being the odd one out between 3.13 and 3.15.

  10. added a commit that references this issue on Aug 31, 2025
  11. hugovk commented on Aug 31, 2025

    Member

    Thanks, 3.14 merged!

  12. added a commit that references this issue on Sep 9, 2025
  13. added a commit that references this issue on Sep 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    testsTests in the Lib/test dirtype-refactorCode refactoring (with no changes in behavior)

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL