-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-122133: Authenticate socket connection for socket.socketpair()
fallback
#122134
Conversation
Co-authored-by: Gregory P. Smith <greg@krypto.org>
alternative approach: check |
Misc/NEWS.d/next/Security/2024-07-22-13-11-28.gh-issue-122133.0mPeta.rst
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the last call_socketpair
refactorization, I personally don't have anything else to say on that PR so I'll leave it to experts now :)
🤖 New build scheduled with the buildbot fleet by @sethmlarson for commit d1bc408 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to solve the primary issue of allowing unintended potentially malicious connection from another process. I don't think adding a looping retry for the connection is worthwhile - at least as part of this issue resolution - the main goal is preventing the undesirable connection which this now does.
…r()` fallback (pythonGH-122134) * Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
GH-122426 is a backport of this pull request to the 3.11 branch. |
…r()` fallback (pythonGH-122134) * Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
GH-122427 is a backport of this pull request to the 3.10 branch. |
…r()` fallback (pythonGH-122134) * Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
GH-122428 is a backport of this pull request to the 3.9 branch. |
GH-122429 is a backport of this pull request to the 3.8 branch. |
…ir()` fallback (GH-122134) (GH-122425) Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
…ir()` fallback (GH-122134) (GH-122424) Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
|
|
…ir()` fallback (GH-122134) (#122426) Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
…ir()` fallback (GH-122134) (#122427) Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
…r()` fallback (GH-122134) (#122428) Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org>
…r()` fallback (GH-122134) (GH-122429) Authenticate socket connection for `socket.socketpair()` fallback when the platform does not have a native `socketpair` C API. We authenticate in-process using `getsocketname` and `getpeername` (thanks to Nathaniel J Smith for that suggestion). (cherry picked from commit 78df104) Co-authored-by: Seth Michael Larson <seth@python.org> Co-authored-by: Gregory P. Smith <greg@krypto.org> Co-authored-by: Łukasz Langa <lukasz@langa.pl>
My apologies for missing the review window of the fix, but it looks good to me 👍 |
@sethmlarson Flagging that this PR is causing a problem with the iOS buildbot (on both 3.x and 3.13). It's causing a number of tests in I'm still poking around to see if I can make sense of this; if you've got any ideas, don't be a stranger :-) The stack trace in the failed tests is mostly consistent:
|
Some code smell: That default argument assignement to patching the test to avoid reinitializing that would be a gross hack. we should do better. must we really use |
Not having Lib/socket.py use a conditional definition of two different versions of the function but instead always defining the pure python socketpair, just as a minor downside: a little more memory use for the new |
Confirming that commenting out the new test that does the |
FYI: I was seeing the same failures with the same stack trace on Android, which also runs all tests in a single process. This was also fixed by #122493. |
yep, see the issue. We reworked the test to not use |
Only for (easier) tracking purposes (because searching for this CVE doesn't yield any results in this repo), it seems CVE-2024-3219 is now linked to this PR: |
Socket connection for the
socket.socketpair()
fallback isn't authenticated. This changes this connection to authenticate the connection is the same expected process.