-
Notifications
You must be signed in to change notification settings - Fork 790
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
security: fix use-after-free in PyCapsule implementation #2481
Conversation
For 0.17.0, we might want to change name to |
It isn't visible in the diff here, but while reviewing that, I was wondering whether the closure type |
Yes, I think you are correct. This is arguably also a soundness issue so I'm now wondering whether to also backcourt that to 0.16, however it is also breaking so that's a bit of a disaster.
Arrgh that's a great point and means that in I see three possible choices for the
Think the |
After musing about it, I'd prefer
So we have three pending changes now:
I think the third problem could also be fixed in a backward-compatible manner by returning a static reference to the empty string |
Agreed, So I did some more thinking on this and I believe we can fix all issues in a non-breaking fashion as far as a 0.16 backport is concerned:
Given that the third fix could be quite annoying for users (although hopefully not many people are relying on such an edge case), I think we should also work on getting 0.17 out the door ASAP so that there's an upgrade pathway to a sound implementation. I'll try to push some PRs and a plan tomorrow. |
👍🏽 This sounds reasonable as a soundness fix to me. |
To keep the capsule rework separate from this sanitiser fix, I'm going to merge this now and open up follow-up PRs. |
Thanks to @saethlin for alerting me to this issue.
The current implementation of
PyCapsule::new
does not require a specific lifetime on thename: &CStr
argument. This is a fundamental flaw; the argument is converted to a pointer and handed over to CPython, which simply stores the pointer.This means that as soon as
PyCapsule::new
is complete, current implementations can deallocate the name and any subsequent calls toPyCapsule_GetName
will read from freed memory (including our safePyCapsule::name
wrapper).A snippet as simple as this is enough to achieve this:
The fix without any API change is to take a copy of the name as a
CString
and store that where we place the rest of the capsule data. We can then pass CPython the pointer from there, which guarantees that the name will outlive the capsule.Given this is a reasonably clear-cut soundness error, I think we should file a RustSec advisory and also yank versions 0.16.0 -> 0.16.5 (after publishing this as a 0.16.6).