Discussion: How can we make gsudo as secure as possible?

[gerardog]

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!

[gerardog]

Anti-debugging technique:

• https://www.apriorit.com/dev-blog/367-anti-reverse-engineering-protection-techniques-to-use-before-releasing-software
• As in https://ntquery.wordpress.com/2014/03/29/anti-debug-ntcreatethreadex/

[gerardog]

Why anti debugging? A non elevated malicious process might debug a legitimate gsudo call (also non-elevated) and inject a harmfull command, overriding the 'same binary' protection.
But I've found a much simpler anti-debugging technique. A malicious non-elevated process can only debug the non-elevated gsudo client. From the elevated gsudo I can reliably check if a debbugger is attached to the non-elevated client. I originally thought that was impossible to do because the mallicious process can intercept/hook all api calls. But it can't debug the elevated process without elevating itself first, and if it has, then why bother hooking gsudo.

[gerardog]

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.
Therefore it's impossible to secure the credentials cache.

Starting from v0.7 the credentials cache will be disabled by default.
Every gsudo call will show a UAC popup.
Unless the user opts-in to enable the cache again.

[Silvenga]

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.

[gerardog]

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.

• Use gsudo config ForceNewWindow true, the same as adding -n to every gsudo call: will elevate everything in a new window. Of course this means we have lost some convenience, but at least the attack vector is gone!

• Use gsudo config SecurityEnforceUacIsolation true to make gsudo do an unseen trick, to try not to bridge UIPI.

  • The elevated process will be launched with StdInput closed. So neither you nor a malicious process will be able to send keystrokes to the elevated process. Non-interactive apps will work as usual. But interactive apps typically detect this and terminate.
  • If you call gsudo with no arguments, a new shell will be elevated in a new window. (A shell is interactive, it would be of no use to launch it with StdInput closed.)

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.
Even if the cache is perfect, by definition it allows an unelevated process to elevate again silently. But, in windows it is trivial for a non-elevated malicious process to inject custom code into any other, such as the allowed process, and AFAIK there is nothing gsudo can do to avoid hijacking of the allowed process. Therefore, if you are not capable of keeping your system out of viruses, I do not recommend that you enable gsudo 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.
Feel free to comment here any ideas or open a new ticket.

Thanks.-

[JohnLGalt]

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 Microsoft way (and never, ever thought I'd utter those words again in my life) and adding in the gsudo config ForceNewWindows true as default, myself, sticking to the more-security-conscious method of privilege elevation, but also appreciate that you're trying to elevate via the trick method of gsudo config SecurityEnforceUacIsolation true also for those who really need / want it.

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.

[gerardog]

@JohnLGalt, I totally forgot ForceNewWindow was never pushed, because it caused a few issues. I will work on that on #97. Please suscribe to that conversation because there are a few things to consider and I appreciate feedback. Thanks

[gerardog]

ForceNewWindow released in v2.0.0 => https://gerardog.github.io/gsudo/docs/tips/elevation-in-new-window