Fix Path Traversal in multissltests.py

[ParzivalHack]

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

• gh-138158: Use the "data" tarfile extraction filter in Tools/ssl/multissltests.py #138147
• [3.14] gh-138158: Use the "data" tarfile extraction filter in Tools/ssl/multissltests.py (GH-138147) #138262
• [3.13] gh-138158: Use the "data" tarfile extraction filter in Tools/ssl/multissltests.py (GH-138147) #138263

[picnixz]

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.

[picnixz]

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.

[sethmlarson]

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!

[picnixz]

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)