Skip to main content

Why doesn't Windows have a sudo command? Should it have one?​

To answer this question, we first have to take a look back at the history.

In August 2002, Chris Paget released a white paper describing a form of attack against event-driven systems that he termed Shatter Attack. It allowed processes in the same session to bypass security restrictions by abusing Windows Message loop.

Microsoft's response was to add "User Interface Privilege Isolation" (UIPI) and the "User Access Control" (UAC) popup to the next major release: Windows Vista. Privileged processes would then run "elevated" at high integrity level, out of reach of processes at lower, non-admin, levels.

I assume that at this point, Microsoft decided not to make a sudo tool for windows. It would be an unwanted bridge between two worlds that intended to isolate.

However, that insulation quickly proved to be weak. Let me quote Raymond Chen from Microsoft:

There’s a setting that lets you specify how often you want to be prompted by UAC. You can set any of four levels:

  • Always notify
  • Notify only when apps try to change settings, use the secure desktop (Default mode)
  • Notify only when apps try to change settings, don’t use the secure desktop
  • Never notify

Although it looks like there are four settings, in a theoretical sense, there really are only two settings.

  • Always notify
  • Meh

The reason why all the other options collapse into Meh is that the Notify only when apps try to change settings option can be subverted by any app simply by injecting a thread (... a hacking technique explained ...)

And, up to this day, Windows 10 & 11, defaults corresponds to that "Meh". Microsoft's default stance is user convenience at the expense of lesser security.

Vista UAC [Windows 11 UAC Settings: Default mode is recommended only if you don't run untrusted software.]

Over time, more than a hundred UAC-bypass techniques have been disclosed. Many of them still work in an updated Windows 11. It is Windows Defender, or your antivirus of choice, who may stop them (hopefully). But if you disable your AV, UAC bypass is easy.

And Microsoft can't just patch them all without loosing 'convenience' features. They instead, they assumed publicly that UAC/UIPI in default mode is not a security boundary. I will quote Microsoft documentation :

Same-desktop Elevation in UAC isn't a security boundary. It can be hijacked by unprivileged software that runs on the same desktop. Same-desktop Elevation should be considered a convenience feature.

Which to me, it means: UAC is a convenience tool. It does not protect you from threats, it works as a warning that protects you from shooting yourself in the foot.

And if UAC is a convenience tool, in my opinion it's not doing the best possible job:

  • You waste important time by switching between elevated and unelevated windows. You must manually carry your command and context to the elevated window, each time, back and forth.
  • ... or you suffer from "elevation fatigue". For example, you elevate a whole console beforehand, and you do all your stuff there, likely running non-admin or untrusted stuff as admin.

In conclusion:

  • Same-desktop UAC is a vulnerable convenience feature.
  • gsudo is also a vulnerable convenience feature.
  • Whether you use gsudo or not, the only thing that protects you from malware is not UAC, it is you and your Antivirus..

So, if you decide to use gsudo, here are the risks:

What are the risks of running gsudo?​

gsudo could be used as an attack vector for escalation of privileges. Using antivirus software and avoiding running untrusted software

  • Abusing an elevation made with gsudo:

    A medium integrity process could drive the gsudo-elevated process.

    When gsudo elevates in the same console, it creates a connection between a medium and a high integrity process. A malicious process (at medium integrity) can then drive the medium integrity console: sending keystrokes to the high integrity app, or scrapping its screen.

    In my opinion, this is a mild risk that you are already exposed when using UAC in default mode. In the end, your only protection is your AV.

    Ways to avoid this risk:

    • Elevating on a new console either per-command (using -n/--new) or force it using config setting NewWindow.Force.
    • Experimental setting SecurityEnforceUacIsolation: makes the elevated command run redirected, w/input redirected to NULL. Hence it will be non-interactive, so nobody will be able to drive it. Enable with gsudo config SecurityEnforceUacIsolation true

  • Abusing an active gsudo's Credentials Cache to elevate a process silently:

    The Credentials Cache allows many elevations with only one UAC popup. But there is a reason why the cache is disabled by default.

    When the cache is active, it allows elevation from one invoker process and its children, which are running at the unprotected medium integrity level. A malicious process also at medium level can inject it's code into an allowed process and make it call gsudo to request elevation silently.

    You avoid this risk by default, by not enabling the credentials cache.