21–30 of 54 posts
Good article, but I wish the author would've addressed securing these named pipes. Consider that if a user-mode application can send messages to a privileged process (like a Windows service). What prevents any user-mode application from doing that? And if your Windows service is running as "NT_AUTHORITY/SYSTEM" and even executes privileged commands, well you might find you've got a simple privilege escalation vuln. R…
Good article, but I wish the author would've addressed securing these named pipes. Consider that if a user-mode application can send messages to a privileged process (like a Windows service). What prevents any user-mode application from doing that? And if your Windows service is running as "NT_AUTHORITY/SYSTEM" and even executes privileged commands, well you might find you've got a simple privilege escalation vuln. R…
I think the package he used, also has some kind of pipe authorization access control.
Named pipes have been in Windows for many years https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
Been using them since 1992 but at this point I would naturally turn to sockets, even on the same machine. I can't even really say why though. Named pipes are nice because they are really more like a file but at this point sockets feel more natural because they exist and are supported everywhere.
Good article, but I wish the author would've addressed securing these named pipes. Consider that if a user-mode application can send messages to a privileged process (like a Windows service). What prevents any user-mode application from doing that? And if your Windows service is running as "NT_AUTHORITY/SYSTEM" and even executes privileged commands, well you might find you've got a simple privilege escalation vuln. R…
The server needs to call ImpersonateNamedPipeClient() on the incoming client connection to assume the client’s security token, that would lower the server’s privilege to the level of the client. That’s it!
A guest level client can connect to the server. The server’s privilege becomes guest, and cannot access any resources that guest has no permission to access.
[1] https://docs.microsoft.com/en-us/windows/win32/api/namedpipe...
Good article, but I wish the author would've addressed securing these named pipes. Consider that if a user-mode application can send messages to a privileged process (like a Windows service). What prevents any user-mode application from doing that? And if your Windows service is running as "NT_AUTHORITY/SYSTEM" and even executes privileged commands, well you might find you've got a simple privilege escalation vuln. R…
Good to address the security aspects of named pipe. However none of those describes how to secure the server. The server needs to call ImpersonateNamedPipeClient() on the incoming client connection to assume the client’s security token, that would lower the server’s privilege to the level of the client. That’s it! A guest level client can connect to the server. The server’s privilege becomes guest, and cannot access…
Earlier quoted context omitted.
Been using them since 1992 but at this point I would naturally turn to sockets, even on the same machine. I can't even really say why though. Named pipes are nice because they are really more like a file but at this point sockets feel more natural because they exist and are supported everywhere.
You can apply permissions to named pipes and, well, they're named which is useful since you can use a unique and deterministic enough name that you don't need an extra band of communication for the client to know what port the server ended up starting on.
Named pipes have been in Windows for many years https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...
Been using them since 1992 but at this point I would naturally turn to sockets, even on the same machine. I can't even really say why though. Named pipes are nice because they are really more like a file but at this point sockets feel more natural because they exist and are supported everywhere.
Just to clarify something at the start of the article... If you are using full Visual Studio to develop with .NET 6, you will need 2022. If not, (eg. VS Code), will work with the command line sdk.
Pretty sure there isn't anything you can't do in Jetbrains Rider EAP. Edit: would like to know why I'm being downvoted.
- Create a architecture diagram out of .NET and native compiled code.
- Integration with SharePoint and Dynamix SDKs
- SQL Server and Azure SDKs
- Using the Fakes mocking framework for MSIL rewriting
- Debugging the GPU shaders
Just a couple of examples, I can take plenty more out of VS enterprise.
I really don't get how people can think JetBrains does better than platform owners.
They will ever play catch-up with platform capabilities and only offer a subset of the package.
Good article, but I wish the author would've addressed securing these named pipes. Consider that if a user-mode application can send messages to a privileged process (like a Windows service). What prevents any user-mode application from doing that? And if your Windows service is running as "NT_AUTHORITY/SYSTEM" and even executes privileged commands, well you might find you've got a simple privilege escalation vuln. R…