Linux specific local privilege escalation via the multiprocessing forkserver start method - CVE-2022-42919 #97514

gpshead · 2022-09-23T19:24:04Z

TL;DR

Python 3.9, 3.10, and 3.11.0rc2 on Linux may allow for a local privilege escalation attack in a non-default configuration when code uses the multiprocessing module and configures multiprocessing to use the forkserver start method.

Details

The Python multiprocessing library, when used with the forkserver start method on Linux, allows Python pickles to be deserialized from any user in the same machine local network namespace, which in many system configurations means any user on the same machine. Pickles can execute arbitrary code. Thus, this allows for local user privilege escalation to the user that any Python multiprocessing forkserver process is running as.

The forkserver start method for multiprocessing is not the default start method. This issue is Linux specific because only Linux supports abstract namespace sockets.

CPython before 3.9 does not make use of Linux abstract namespace sockets by default.

This issue has been assigned CVE-2022-42919.

Credit: This issue was discovered by Devin Jeanpierre (@ssbr) of Google.

Are Python 3.7 and 3.8 affected?

Not by default.

Support for users manually specifying an abstract namespace AF_UNIX socket was added as a bugfix in 3.7.8 and 3.8.3, but users would need to make specific uncommon multiprocessing API calls specifying their own forkserver control socket path in order to do that in CPython before 3.9.

What about code that explicitly asks for an abstract socket?

Applications found to be making the uncommon multiprocessing API calls to explicitly use Linux abstract namespace sockets with a forkserver are believed to be rare and should have their own specific security issues filed.

Workarounds

From Python application or library code:

import multiprocessing.util
multiprocessing.util.abstract_sockets_supported = False

This disables their use by default. You must execute that before anything else in your process has started making use of multiprocessing.

If you can patch your CPython runtime itself:

Remove these two lines from CPython's Lib/multiprocessing/connection.py:

-        if util.abstract_sockets_supported:
-            return f"\0listener-{os.getpid()}-{next(_mmap_counter)}"

(that is what our security bug fix commits do).

Or, similar to the application level fix, edit Lib/multiprocessing/util.py to always set:

- abstract_sockets_supported = _platform_supports_abstract_sockets()
+ abstract_sockets_supported = False

Alternatives to avoid the problem

If your Linux Python application can be switched from multiprocessing's .set_start_method("forkserver") to a start method such as "spawn" that will also avoid this issue.

Scope of the bug fixes

We are changing the default in Python 3.9 and higher to not use the Linux abstract namespace sockets by default.

It would be ideal to add authentication to the forkserver control socket so that it isn't even relying on filesystem permissions. This is a more complicated change and is expected to be done as a feature in 3.12.

Tasks

Cherry pick the 3.11 commit to the 3.11.0 release. 4686d77
Merge the 3.9 PR. [3.9] gh-97514: Don't use Linux abstract sockets for multiprocessing (GH-98501) #98504
After 3.11.0 is out, make sure 3.11.1 won't have a duplicate news entry about this due to the branch vs 3.11.0 release branch
Push @gpshead 's PR(s) for proper forkserver socket authentication in 3.12.

Linked PRs

PR: gh-97514: Authenticate the forkserver control socket. #99309

The text was updated successfully, but these errors were encountered:

Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches.

Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches.

…ythonGH-98501) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via python#18866 while fixing python#84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <[email protected]>

…GH-98501) (GH-98502) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <[email protected]> Automerge-Triggered-By: GH:gpshead

…GH-98501) (GH-98503) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <[email protected]> Automerge-Triggered-By: GH:gpshead

…GH-98501) (GH-98502) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <[email protected]> Automerge-Triggered-By: GH:gpshead

…H-98501) (#98504) Linux abstract sockets are insecure as they lack any form of filesystem permissions so their use allows anyone on the system to inject code into the process. This removes the default preference for abstract sockets in multiprocessing introduced in Python 3.9+ via #18866 while fixing #84031. Explicit use of an abstract socket by a user now generates a RuntimeWarning. If we choose to keep this warning, it should be backported to the 3.7 and 3.8 branches. (cherry picked from commit 49f6106) Co-authored-by: Gregory P. Smith <[email protected]>

vstinner · 2022-11-03T13:27:27Z

I created https://python-security.readthedocs.io/vuln/multiprocessing-abstract-socket.html to track this vulnerability.

gpshead · 2022-11-03T22:51:24Z

Canonical is tracking it for Ubuntu (and ultimately Debian?) here: https://ubuntu.com/security/notices/USN-5713-1

RedHat seems to be tracking it for RHEL and Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=2138705

mickeypash · 2022-11-04T00:17:09Z

Thanks for this @gpshead!
Apologies for the newbie question.
Here Canonical mentions that for Python 3.9~20.04 (focal) the status is Needed.

With these changes you've effectively fixed it for 3.9? What are the next steps?
I assume a new version would be released (something like 3.9~20.04.2 ?)
But how long would that take? How could I track this?

Thank you in advance!

mcepl · 2022-11-04T07:45:28Z

Canonical is tracking it for Ubuntu (and ultimately Debian?) here: https://ubuntu.com/security/notices/USN-5713-1

RedHat seems to be tracking it for RHEL and Fedora as well: https://bugzilla.redhat.com/show_bug.cgi?id=2138705

openSUSE https://bugzilla.suse.com/1204886 (aka https://bugzilla.suse.com/show_bug.cgi?id=CVE-2022-42919)

vstinner · 2022-11-04T09:17:29Z

I added links to my page. Well, it would be even better if people other than me would maintain the vulnerability list. It's a long YAML page: https://github.com/vstinner/python-security/blob/main/vulnerabilities.yaml#L2049

mickeypash · 2022-11-04T09:35:08Z

@vstinner I'd be up for that if it mean freeing up some time for you? 👍

mcepl · 2022-11-04T09:51:50Z

I added links to my page. Well, it would be even better if people other than me would maintain the vulnerability list. It's a long YAML page: https://github.com/vstinner/python-security/blob/main/vulnerabilities.yaml#L2049

Generally, for openSUSE, https://bugzilla.opensuse.org/show_bug.cgi?id=CVEid should work (I think, for the Red Hat as well, doesn’t it?). And yes, bugzilla.opensuse.org, bugzilla.suse.com, and bugzilla.novell.com are the same thing, just DNS aliases.

fungi · 2022-11-08T17:19:32Z

Note that the NIST NVD record linked from the Python Security tracker contains misleading information. At the bottom it claims "Known Affected: up to (excluding) 3.10.8" which is confusing folks into thinking 3.10.8 is unaffected by this vulnerability. It would be great if someone with authority for Python's vulnerability disclosure could reach out to NIST and get that corrected, since it may be causing some organizations to not realize they need to patch their builds.

gpshead · 2022-11-09T17:55:59Z

Yes, I'm disappointed with my interactions with Mitre regarding getting the CVE text updated. The clear categorized information I provided to them via their cve request web form when reserving the CVE id was mostly discarded when they flipped it from "Reserved" to publish it with information.

This process should in theory go smoother once Python is setup as its own CNA (we're planning to do this).

Anyways the good news is that it can be updated and now that I finally got them to make the record public in some form, doing so should be easier. I'll see what I can do to clean the CVE record that winds up in the NVD up. It is ultimately a JSON blob following a defined schema and now that it is public I believe I can do so via a PR against https://github.com/CVEProject/cvelist/blob/master/2022/42xxx/CVE-2022-42919.json - we'll see. It's a byzantine process. :/

yairmzr · 2022-11-10T13:24:11Z

@gpshead I would like to point out that the bugfix with support for abstract namespace sockets was added in Python 3.8.3, not Python 3.8.4.
The bugfix was in March 2020, and Python 3.8.3 was released in May 2020 so it was already merged.

See the following:
https://github.com/python/cpython/blob/v3.8.3/Lib/multiprocessing/util.py#L116

gpshead · 2022-11-10T20:24:53Z

Thanks. Main description text updated to say 3.8.3.

zhuofeng6 · 2022-11-14T02:19:46Z

Is there a way to reproduce it? @gpshead

gpshead · 2022-11-14T03:51:50Z

Yes. But it is basically a demo exploit so we're intentionally not releasing that ourselves. I'll leave an exploit as an exercise for others.

To scan a Linux system for such vulnerable sockets being open. ss -lx | grep @listener. The @ is the ss token for null which means abstract namespace socket, the Python forkserver code uses a socket name similar to listener-{forkserver_pid}-0 by default. If one of those exists, something is likely running an unpatched python forkserver:

~$ python3.9
...
>>> import multiprocessing
>>> multiprocessing.set_start_method("forkserver")
>>> p = multiprocessing.Pool()
>>> ^Z
[1]+  Stopped                 python3.9
~$ ss -lx | grep @listener
u_str        LISTEN        0              128          @listener-1247748-0   196275393          *   0

If there are multiple network namespaces you probably need to do more to scan all of those from a sufficiently priviledged user.

This adds authentication to the forkserver control socket. In the past only filesystem permissions protected this socket from code injection into the forkserver process by limiting access to the same UID, which didn't exist when Linux abstract namespace sockets were used (see issue) meaning that any process in the same system network namespace could inject code. We've since stopped using abstract namespace sockets by default, but protecting our control sockets regardless of type is a good idea. This reuses the HMAC based shared key auth already used by `multiprocessing.connection` sockets for other purposes. Doing this is useful so that filesystem permissions are not relied upon and trust isn't implied by default between all processes running as the same UID with access to the unix socket. ### pyperformance benchmarks No significant changes. Including `concurrent_imap` which exercises `multiprocessing.Pool.imap` in that suite. ### Microbenchmarks This does _slightly_ slow down forkserver use. How much so appears to depend on the platform. Modern platforms and simple platforms are less impacted. This PR adds additional IPC round trips to the control socket to tell forkserver to spawn a new process. Systems with potentially high latency IPC are naturally impacted more. Typically a 1-4% slowdown on a very targeted process creation microbenchmark, with a worst case overloaded system slowdown of 20%. No evidence that these slowdowns appear in practical sense. See the PR for details.

…-99309) This adds authentication to the forkserver control socket. In the past only filesystem permissions protected this socket from code injection into the forkserver process by limiting access to the same UID, which didn't exist when Linux abstract namespace sockets were used (see issue) meaning that any process in the same system network namespace could inject code. We've since stopped using abstract namespace sockets by default, but protecting our control sockets regardless of type is a good idea. This reuses the HMAC based shared key auth already used by `multiprocessing.connection` sockets for other purposes. Doing this is useful so that filesystem permissions are not relied upon and trust isn't implied by default between all processes running as the same UID with access to the unix socket. ### pyperformance benchmarks No significant changes. Including `concurrent_imap` which exercises `multiprocessing.Pool.imap` in that suite. ### Microbenchmarks This does _slightly_ slow down forkserver use. How much so appears to depend on the platform. Modern platforms and simple platforms are less impacted. This PR adds additional IPC round trips to the control socket to tell forkserver to spawn a new process. Systems with potentially high latency IPC are naturally impacted more. Typically a 1-4% slowdown on a very targeted process creation microbenchmark, with a worst case overloaded system slowdown of 20%. No evidence that these slowdowns appear in practical sense. See the PR for details.

gpshead added type-bug An unexpected behavior, bug, or error type-security A security issue stdlib Python modules in the Lib dir labels Sep 23, 2022

gpshead self-assigned this Sep 23, 2022

gpshead added 3.11 only security fixes 3.10 only security fixes 3.9 only security fixes 3.12 bugs and security fixes labels Oct 20, 2022

gpshead changed the title ~~Placeholder issue for a specific pending security fix.~~ Linux specific local priviledge escalation via the multiprocessing forkserver start method - CVE-2022-42919 Oct 20, 2022

bedevere-bot mentioned this issue Oct 20, 2022

gh-97514: Don't use Linux abstract sockets for multiprocessing #98501

Merged

gpshead mentioned this issue Oct 20, 2022

multiprocessing.connection.Listener fails to close with null byte in AF_UNIX socket name. #84031

Closed

gpshead added the release-blocker label Oct 20, 2022

ezio-melotti added this to Release and Deferred blockers 🚫 Oct 20, 2022

ezio-melotti moved this to Todo in Release and Deferred blockers 🚫 Oct 20, 2022

bedevere-bot mentioned this issue Oct 20, 2022

[3.11] gh-97514: Don't use Linux abstract sockets for multiprocessing (GH-98501) #98502

Merged

This was referenced Oct 20, 2022

[3.10] gh-97514: Don't use Linux abstract sockets for multiprocessing (GH-98501) #98503

Merged

[3.9] gh-97514: Don't use Linux abstract sockets for multiprocessing (GH-98501) #98504

Merged

gpshead changed the title ~~Linux specific local priviledge escalation via the multiprocessing forkserver start method - CVE-2022-42919~~ Linux specific local privilege escalation via the multiprocessing forkserver start method - CVE-2022-42919 Oct 20, 2022

gpshead assigned pablogsal and ambv Oct 20, 2022

gpshead moved this from Todo to In Progress in Release and Deferred blockers 🚫 Oct 21, 2022

gpshead mentioned this issue Oct 23, 2022

preloading '__main__' with forkserver has been broken for a long time #98552

Open

gpshead closed this as completed Nov 2, 2022

Repository owner moved this from In Progress to Done in Release and Deferred blockers 🚫 Nov 2, 2022

bedevere-bot mentioned this issue Nov 10, 2022

gh-97514: Authenticate the forkserver control socket. #99309

Merged

3 tasks

dbadura mentioned this issue Nov 10, 2022

Apply workaround for python CVE kyma-project/kyma#16061

Merged

gpshead mentioned this issue Nov 20, 2022

gh-61460: Stronger HMAC in multiprocessing #20380

Merged

MingcongBai mentioned this issue Dec 13, 2022

python-3: update to 3.10.9 AOSC-Dev/aosc-os-abbs#4337

Closed

dawnmy mentioned this issue Jan 9, 2024

Address already in use hzi-bifo/RiboDetector#46

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Linux specific local privilege escalation via the multiprocessing forkserver start method - CVE-2022-42919 #97514

Linux specific local privilege escalation via the multiprocessing forkserver start method - CVE-2022-42919 #97514

gpshead commented Sep 23, 2022 •

edited by arhadthedev

Loading

vstinner commented Nov 3, 2022

gpshead commented Nov 3, 2022

mickeypash commented Nov 4, 2022

mcepl commented Nov 4, 2022

vstinner commented Nov 4, 2022

mickeypash commented Nov 4, 2022

mcepl commented Nov 4, 2022 •

edited

Loading

fungi commented Nov 8, 2022

gpshead commented Nov 9, 2022

yairmzr commented Nov 10, 2022

gpshead commented Nov 10, 2022

zhuofeng6 commented Nov 14, 2022

gpshead commented Nov 14, 2022 •

edited

Loading

Linux specific local privilege escalation via the multiprocessing forkserver start method - CVE-2022-42919 #97514

Linux specific local privilege escalation via the multiprocessing forkserver start method - CVE-2022-42919 #97514

Comments

gpshead commented Sep 23, 2022 • edited by arhadthedev Loading

TL;DR

Details

Are Python 3.7 and 3.8 affected?

What about code that explicitly asks for an abstract socket?

Workarounds

From Python application or library code:

If you can patch your CPython runtime itself:

Alternatives to avoid the problem

Scope of the bug fixes

Tasks

Linked PRs

vstinner commented Nov 3, 2022

gpshead commented Nov 3, 2022

mickeypash commented Nov 4, 2022

mcepl commented Nov 4, 2022

vstinner commented Nov 4, 2022

mickeypash commented Nov 4, 2022

mcepl commented Nov 4, 2022 • edited Loading

fungi commented Nov 8, 2022

gpshead commented Nov 9, 2022

yairmzr commented Nov 10, 2022

gpshead commented Nov 10, 2022

zhuofeng6 commented Nov 14, 2022

gpshead commented Nov 14, 2022 • edited Loading

gpshead commented Sep 23, 2022 •

edited by arhadthedev

Loading

mcepl commented Nov 4, 2022 •

edited

Loading

gpshead commented Nov 14, 2022 •

edited

Loading