Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

mattico
Copy link
Contributor

@mattico mattico commented Sep 14, 2017

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

@rust-highfive
Copy link
Collaborator

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
@pitdicker
Copy link
Contributor

c::SECURITY_SQOS_PRESENT is set automatically when security_qos_flags is not 0 (see line 251).
I wrote the first version of this code, but have not tested these flags. Can you confirm it works?

@mattico
Copy link
Contributor Author

mattico commented Sep 14, 2017

c::SECURITY_SQOS_PRESENT is set automatically when security_qos_flags is not 0 (see line 251).

I'm aware. I thought that settings both flags at the start was more clear. Don't care much either way.

Can you confirm it works?

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 fs::File::create still works). I thought about adding a test for the negative case (who doesn't want to add an exploit implementation to their test suite?) The exploit paper mentioned that it can be flaky, however:

Additionally, at times the privilege to assign a primary token to a new process will be disabled. This more advanced exploitation will be covered in a future paper.

I can't find the future paper.

@alexcrichton alexcrichton added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 14, 2017
@mattico mattico changed the title windows: Enable default security parameters on file creation to avoid named pipe exploit [WIP] windows: Enable default security parameters on file creation to avoid named pipe exploit Sep 15, 2017
@mattico
Copy link
Contributor Author

mattico commented Sep 15, 2017

Adding [WIP] so this doesn't get merged before I write a test of some sort.

@arielb1 arielb1 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 19, 2017
@carols10cents
Copy link
Member

Friendly ping @mattico to make sure this doesn't get lost! Do you know when you'll be getting back to this PR?

@mattico
Copy link
Contributor Author

mattico commented Sep 26, 2017

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.

@mattico mattico closed this Oct 1, 2017
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
 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`.
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
 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`.
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
 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`.
bors added a commit that referenced this pull request Mar 2, 2019
 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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Always pass SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION when opening a named pipe
7 participants