-
Notifications
You must be signed in to change notification settings - Fork 13k
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
[WIP] windows: Enable default security parameters on file creation to avoid named pipe exploit #44556
Conversation
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
… named pipe exploit Fixes rust-lang#42036 As noted in [this paper][1], the threat model for the exploit is a priveleged Rust process which accepts a file path from a malicious program. With this exploit, the malicious program can pass a named pipe to the priveleged process and gain its elevated priveleges. The fix is to change the default OpenOptions to contain the proper security flags. [The .NET FileStream][2] has this same behavior by default. We're using the `SecurityIdentification` security level which is more permissive, but still blocks the exploit. This is technically a breaking change. If someone were using a named pipe to impersonate a program *on purpose*, they would have to add `.security_qos_flags(0)` to their `OpenOptions` to keep working. [1]: http://www.blakewatts.com/namedpipepaper.html [2]: http://referencesource.microsoft.com/#mscorlib/system/io/filestream.cs,837
8571699
to
d55c2d7
Compare
|
I'm aware. I thought that settings both flags at the start was more clear. Don't care much either way.
Yes. Creating files and named pipes both works fine. I suppose I could add a test for the positive case (creating a named pipe with
I can't find the future paper. |
Adding [WIP] so this doesn't get merged before I write a test of some sort. |
Friendly ping @mattico to make sure this doesn't get lost! Do you know when you'll be getting back to this PR? |
I haven't forgotten about this PR, but writing tests has exposed some potential issues that warrant a deeper investigation than I have time for at the moment. |
Set secure flags when opening a named pipe on Windows Fixes rust-lang#42036, see also the previous attempt in rust-lang#44556. Whether this is correct depends on if it is somehow possible to create a symlink to a named pipe, outside the named pipe filesystem (NPFS). But as far as I can tell that should be impossible. Also fixes that `security_qos_flags(SECURITY_ANONYMOUS)` does not set the `SECURITY_SQOS_PRESENT` flag, and the incorrect documentation about the default value of `security_qos_flags`.
Set secure flags when opening a named pipe on Windows Fixes rust-lang#42036, see also the previous attempt in rust-lang#44556. Whether this is correct depends on if it is somehow possible to create a symlink to a named pipe, outside the named pipe filesystem (NPFS). But as far as I can tell that should be impossible. Also fixes that `security_qos_flags(SECURITY_ANONYMOUS)` does not set the `SECURITY_SQOS_PRESENT` flag, and the incorrect documentation about the default value of `security_qos_flags`.
Set secure flags when opening a named pipe on Windows Fixes rust-lang#42036, see also the previous attempt in rust-lang#44556. Whether this is correct depends on if it is somehow possible to create a symlink to a named pipe, outside the named pipe filesystem (NPFS). But as far as I can tell that should be impossible. Also fixes that `security_qos_flags(SECURITY_ANONYMOUS)` does not set the `SECURITY_SQOS_PRESENT` flag, and the incorrect documentation about the default value of `security_qos_flags`.
Set secure flags when opening a named pipe on Windows Fixes #42036, see also the previous attempt in #44556. Whether this is correct depends on if it is somehow possible to create a symlink to a named pipe, outside the named pipe filesystem (NPFS). But as far as I can tell that should be impossible. Also fixes that `security_qos_flags(SECURITY_ANONYMOUS)` does not set the `SECURITY_SQOS_PRESENT` flag, and the incorrect documentation about the default value of `security_qos_flags`.
Fixes #42036
As noted in this paper, the threat model for the exploit is a privileged Rust process which accepts a file path from a malicious program. With this exploit, the malicious program can pass a named pipe to the privileged process and gain its elevated privileges.
The fix is to change the default
fs::OpenOptions
to contain the proper security flags. The .NET FileStream has this same behavior. We're using theSecurityIdentification
security level which is more permissive, but still blocks the exploit.This is technically a breaking change. If someone were using a named pipe to impersonate a program on purpose, they would have to add
.security_qos_flags(0)
to theirOpenOptions
to keep working.