Description

gpshead

opened on Sep 23, 2022

Issue body actions

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

Reacted by TErry CHao and Sajad F. Maghrebi

Activity

1. gpshead

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   type-securityA security issueA security issue

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Sep 23, 2022
2. gpshead

   self-assigned this

   on Sep 23, 2022
3. gpshead

   added

   3.11only security fixesonly security fixes

   3.10 (EOL)end of lifeend of life

   3.9 (EOL)end of lifeend of life

   3.12only security fixesonly security fixes

   on Oct 20, 2022
4. 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[/+] on Oct 20, 2022
5. gpshead

   added a commit that references this issue on Oct 20, 2022

   pythongh-97514: Don't use Linux abstract sockets for multiprocessing.

   6465b53
6. gpshead

   added

   release-blocker

   on Oct 20, 2022
7. ezio-melotti

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

   moved this to Todo in Release and Deferred blockers 🚫on Oct 20, 2022
9. Yhg1s

   added a commit that references this issue on Oct 20, 2022

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

   49f6106
10. miss-islington

    added a commit that references this issue on Oct 20, 2022

    pythongh-97514: Don't use Linux abstract sockets for multiprocessing (p…

    bf61665
11. 14 remaining items

12. gpshead commented on Nov 3, 2022

    

    gpshead

    on Nov 3, 2022

    MemberAuthor

    More actions

    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
13. mickeypash commented on Nov 4, 2022

    

    mickeypash

    on Nov 4, 2022

    More actions

    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!
14. mcepl commented on Nov 4, 2022

    

    mcepl

    on Nov 4, 2022

    Contributor

    More actions

    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)
15. vstinner commented on Nov 4, 2022

    

    vstinner

    on Nov 4, 2022

    Member

    More actions

    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

    Reacted by Mickey Pashov
16. mickeypash commented on Nov 4, 2022

    

    mickeypash

    on Nov 4, 2022

    More actions

    @vstinner I'd be up for that if it mean freeing up some time for you? 👍
17. mcepl commented on Nov 4, 2022

    

    mcepl

    on Nov 4, 2022

    Contributor

    More actions

    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.
18. fungi commented on Nov 8, 2022

    

    fungi

    on Nov 8, 2022

    More actions

    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.

    Reacted by Gregory P. Smith
19. gpshead commented on Nov 9, 2022

    

    gpshead

    on Nov 9, 2022

    MemberAuthor

    More actions

    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. :/
20. yairmzr commented on Nov 10, 2022

    

    yairmzr

    on Nov 10, 2022

    More actions

    @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

    Reacted by avivnakar and Gregory P. Smith
21. gpshead commented on Nov 10, 2022

    

    gpshead

    on Nov 10, 2022

    MemberAuthor

    More actions

    Thanks. Main description text updated to say 3.8.3.
22. zhuofeng6 commented on Nov 14, 2022

    

    zhuofeng6

    on Nov 14, 2022

    More actions

    Is there a way to reproduce it? @gpshead
23. gpshead commented on Nov 14, 2022

    

    gpshead

    on Nov 14, 2022

    MemberAuthor

    More actions

    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.
24. gpshead

    added a commit that references this issue on Nov 20, 2024

    gh-97514: Authenticate the forkserver control socket. (GH-99309)

    7191b76
25. ebonnal

    added a commit that references this issue on Jan 12, 2025

    pythongh-97514: Authenticate the forkserver control socket. (pythonGH…

    e3acd45
26. icanhasmath

    added a commit that references this issue on Oct 29, 2026

    3.7.17.x: release notes for the added fixes; pythongh-97514 does not …

    83ed748

Issue actions