[CVE-2024-9287] venv activation scripts do not quote strings properly

[y5c4l3]

Bug report

Bug description:

Crafted paths break the script templates:

envname='";uname -a;"'
mkdir "$envname"
cd "$envname"
python3 -m venv .
. ./bin/activate

Linux archlinux 6.10.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 19 Aug 2024 17:02:39 +0000 x86_64 GNU/Linux

Like pypa/virtualenv#2768 the execution path itself is low-risk, but it enables many potential downstream attack vectors. Downstream projects that automatically initialize and activate venv at a controllable path (e.g. read from repo configuration file) could execute unexpected commands.

CPython versions tested on:

3.8, 3.9, 3.10, 3.11, 3.12, 3.13, CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-124651: Quote template strings in venv activation scripts #124712
• [3.13] gh-124651: Quote template strings in venv activation scripts (GH-124712) #125813
• [3.12] gh-124651: Quote template strings in venv activation scripts (GH-124712) #125947
• [3.12] gh-124651: Quote template strings in venv activation scripts (GH-124712) #126185
• [3.11] gh-124651: Quote template strings in venv activation scripts (GH-124712) (GH-126185) #126269
• [3.10] gh-124651: Quote template strings in venv activation scripts (GH-124712) (GH-126185) (#126269) #126300
• [3.9] gh-124651: Quote template strings in venv activation scripts (GH-124712) (GH-126185) (#126269) #126301

[sethmlarson]

Hey @y5c4l3, thanks for reporting this. We're going to treat this as a low-risk security issue. You or anyone else can submit a fix normally. If you have questions about this, send an email to [email protected].

[y5c4l3]

@sethmlarson Thanks for the reply! Could you please help me with a code review for this PR as well as #124155? The code owner for venv seems to be unavailable recently.

[gpshead]

can we keep this open until all of the security branch backports are done?

[picnixz]

We're going to treat this as a low-risk security issue

Do you want to backport it up to 3.9 as well? If so, don't forget to add the backport labels on the PR (for now, we only have 3.12+)

[vstinner]

I close the issue. The fix was applied to all branches.

[YigitElma]

Hello!

I am part of a team that uses Github's cache to store virtual environments for our CI. Our routine was working fine but for the last 2 days, I have noticed that sometimes actions that use Python 3.11 and 3.12 fail. I couldn't find any other major change that might affect it. Then, I found this change that is introduced in Python 3.11.11 and 3.12.8 recently.

My problem is, the workflow that creates the cached virtual environment and other workflows that use that cache sometimes operate with different Python versions e.g. 3.12.7 and 3.12.8 (this is probably due to some Github runner difference). When that is the case, I cannot activate the virtual environment and tests fail.

One of the solutions that I can think of is to enforce both workflows (the one that creates and the one that uses the venv) to use the exact same Python patch (for example 3.12.8), but I wanted to ask you if I am missing something? I would expect any venv created by the same minor Python version to be compatible with each other or I have never faced this issue before (I usually don't look at which Python patch I am using).

Thanks for any help!

[vstinner]

Sadly, the Python version used to create the venv should match the Python version used to run the venv. Both versions should be in sync.

[YigitElma]

Sadly, the Python version used to create the venv should match the Python version used to run the venv. Both versions should be in sync.

@vstinner Thanks for the quick response!

Was this always the case? For example, venv with 3.12.7 and 3.12.6, aren't they compatible?

Because previously creating the venv with any 3.12 (whatever patch was chosen by Github runner) and activating it with any 3.12 was working.

[vstinner]

Was this always the case? For example, venv with 3.12.7 and 3.12.6, aren't they compatible?

It's a new issue caused by the security fix.