-
-
Notifications
You must be signed in to change notification settings - Fork 139
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
Discussion: How can we make gsudo as secure as possible? #20
Comments
Why anti debugging? A non elevated malicious process might debug a legitimate |
Debugging other processes, Dll Injection, or faking your parent process Id are all trivial and almost unrestricted on Windows. Also, Anti-Debugging controls can be workarounded. Starting from v0.7 the credentials cache will be disabled by default. |
There's also the CLR Profiling API (See https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/profiling-overview) that's purely controlled by environment variables as a .NET runtime (Framework or Core) is started. The profiling API allows the modification of IL during JIT, which could do the same as the debugging API you mentioned. The CLR Profiling API works by loading a DLL into the runtime's memory space based on the environment variables given, so only access to the environment variables are required + the ability to write a file to somewhere on the system. To modify the elevated process, access to the system environment variables would be needed, but modification of the non-elevated would be rather trivial. The profiling API also allows attaching "profilers" to running CLR runtimes executing under the same user. I'm not 100% sure the scope of what callbacks are allowed when running in that mode (I don't work with attaching profilers). E.g. is Rejit'ing IL allowed. Super small attack surface that I haven't seen exploited, but maybe something to consider. I know some anti-virus software block this sort of attack, but most don't. |
I´ve had thousands of thoughts about this. In a nutshell: a sudo for Windows (specifically to elevate inside a preexistent non-elevated window) is impossible to achieve in a 100% secure way, otherwise Microsoft would have already done it. Microsoft response to shatter attacks was to isolate processes with admin permissions (elevated) and without (unelevated). This isolation is named UIPI. Unelevated processes can't access elevated ones. The mere concept of any sudo for windows implies a bridge between elevated and unelevated processes that breaks the UIPI isolation. For example, an unelevated console window invoking sudo, would then host an elevated process. Now another unelevated process can access the console window and drive the elevated process. (best case: send keystrokes, read console content as an admin). This opens the escalation-of-privilege vector that UIPI prevents. The Microsoft team working at Windows Terminal recently dismissed the development of several features for this reason: there is no way to do this without introducing this attack vector, at least without changes in the operating system itself. There is no known workaround: Whoever accepts using any sudo for windows, is trading convenience for risk. gsudo introduces two experiments to mitigate this risk. None of them are perfect.
Both options allows to enforce the UIPI isolation, in different ways. Finally the second elefant in the room: The credentials cache. Again, without changes in the operating system, there is no way to create a 100% secure cache. This issue has been open for 18 months. I will close this issue now as I don´t see any actionable items. Thanks for all the contributions. Thanks.- |
No ideas, just commenting that the UIPI was exactly what I was referring to in another issue thread. I like the idea of following with the I'm primarily using gsudo to elevate both PS (native) and CMD in Terminals, and it's worked great for native PS and CMD thus far, so I'm excited to test these newer methods to see which works better for my purposes. Thanks again. |
@JohnLGalt, I totally forgot |
|
It's in everybody interest to make gsudo as secure as possible. The current Windows security model makes almost impossible to make a risk-less
sudo
for Windows. Otherwise, Microsoft would have already made one.Therefore, using
gsudo
has inherent risks, and my vision is that it should expose as few attack vectors or risks as possible, document each risk, and provide a way to disable every feature that results in new risks/attack vectors.As a start, I created issue #19 requesting help from the community willing to review / audit
gsudo
source or perform a PenTest. Let's use this thread instead to discuss more general security-hardening related ideas. Such as feedback on what are the gsudo weak points and/or proposals on how to be more secure.Get involved please! Thanks!
The text was updated successfully, but these errors were encountered: