Always pass SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION when opening a named pipe

[DemiMarie]

By default, opening a named pipe on Windows allows the server to impersonate the client. This is a security vulnerability. Pass SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION to prevent this.

Since it fixes a security hole, I don’t think this needs an RFC.

[sfackler]

Where do we use named pipes?

[DemiMarie]

Nowhere, but it is possible to open a named pipe as a file.

…

On May 16, 2017 1:29 PM, "Steven Fackler" ***@***.***> wrote: Where do we use named pipes? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42036 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB3pg-HsW7L2lwyxGumdyCyDYzRWHks5r6d0VgaJpZM4Ncg1j> .

[Mark-Simulacrum]

@DemiMarie Could you be more clear? What exactly needs to change inside Rust? I assume we'd have to add some form of detection around file opening in windows..?

[DemiMarie]

Whenever libstd calls CreateFileW(), it needs to pass these flags to avoid a local privilege escalation exploit.

…

On Jun 22, 2017 7:47 PM, "Mark Simulacrum" ***@***.***> wrote: @DemiMarie <https://github.com/demimarie> Could you be more clear? What exactly needs to change inside Rust? I assume we'd have to add some form of detection around file opening in windows..? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42036 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB7_FxvJuGupfVWCvnl2Sv06mK7FWks5sGv0XgaJpZM4Ncg1j> .

[pitdicker]

@mattico can you tell anything about what potential issue you hit when trying to work on this in #44556? Or do you have WIP code of the test you where working on?

[pitdicker]

A simple explanation of the security problem: https://flylib.com/books/en/1.287.1.242/1/.

What could be a problem with setting these flags always: the flag SECURITY_SQOS_PRESENT is the same as FILE_FLAG_OPEN_NO_RECALL. The first is supposed to be used with named pipes, the other for files and directories. So if we start to unconditionally add SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION, it will in reality set the FILE_FLAG_OPEN_NO_RECALL in almost all cases.

Now I've never seen a system with 'hierarchical storage' where FILE_FLAG_OPEN_NO_RECALL would be necessary. It is intended for systems that combine fast store like hard drives, with slow bulk storage like tapes. File operations like indexing, searching, or backup that want to work well on such systems should open files that have the attribute FILE_ATTRIBUTE_OFFLINE with this flag. Otherwise a lot of data from tape may be put back online on hard drives. See two descriptions at The Old New Thing.

While investigation this, I found another issue with security_qos_flags: one of the values it takes is SECURITY_ANONYMOUS, whis is simply 0x0. Currently, when you set SECURITY_ANONYMOUS, it will silently be ignored unless you also happen to set SECURITY_SQOS_PRESENT (which our API is supposed to set automatically). Easy to fix though.

Now I don't care much for working well with hierarchical storage. But we should not break it without having some sort of workaround available.

• We can say that if user code contains custom_flags it should be able to handle Windows-specific oddities such as this one. We could make it so that even custom_flags(0) is enough to disable automatic sqos flags. But it doesn't feel great to just drop a security measure when the user could be doing something unrelated, such as the buffering hint custom_flags(FILE_FLAG_RANDOM_ACCESS).
• Only set SECURITY_SQOS_PRESENT|SECURITY_IDENTIFICATION when we know what we are trying to open is a named pipe. I think all named pipes start with \\.\pipe\, and we know the filename when setting the flags. But I am not sure if this really works, or if it is possible for an unprivileged process to create a symbolic link to one in the object manager.

I don't know if I'll get to making a PR and doing the required testing, just writing down what I've found so far.