Help wanted: Could you Review/Audit or PenTest `gsudo` source code?

[gerardog]

I've already heard opinions like: "I can not use this on the enterpise." or "This other sudo is just a few lines RunAs script that I can audit myself." (Sure, but building a feature-rich sudo takes far more lines than that.) and the next one probably will be: "I won't run as administrator something from a nobody on the internet."

This is a trust problem. And I cannot create trust by myself.

The only way that I can think of gaining trust in a free open-source project made in spare-time is by incremental contributions from the community. What if anyone could get involved and deposit a small unit of trust?

So, I thought: Well lets create a place where anyone who has read the code can pass a message to the next one.

Contributions should contain:

• A description of your expertise area, or relevant certifications if any: (for example, Information Technology Student, Senior C++/C# Windows Security Analyst, Developer, Certified PenTest/CISA, etc.) (All contributions are worthy)
• What kind of audit/review have you done, for example:
  • I've read all the code and I couldn't find any intentional backdoor or unintentional security hole.
  • I've analyzed the code and the security measures of X seems appropriate.
  • As certified "x" I can certify that...
• Commit ID and timestamp of the audited code (master branch only!)

If a review or audit finds issues, the best path forward would be to create an issue with the findings so we can first triage each one and create proposals appropriate issues for each matter.

The scope of the Audit is just those parts of gsudo that are distributed on each release. (tree link). (i.e. build scripts/unit tests are not distributed nor used by end-users, so IMHO I see no point auditing that.)

Thank you very, very much.

[SeeminglyScience]

@gerardog You may want to explicitly define how you would like vulnerabilities to be disclosed. I could be missing it, but I only see how you would like positive analysis to be reported (i.e. is there some way to responsibly disclose, or would you like those to be public as well).

[gerardog]

If you consider that the vulnerability is critical, please first report by mail to gerardog (at) gmail.com. That would give more time to review the scenario and fix if needed. Other findings could be reported by creating an issue here on gsudo github repo. I want to be as transparent as possible. But if the vulnerability could put users at risks, then some time in advance for bugfixing is appreciated.

[johnyesberg]

Do you think having a formal vulnerability disclosure policy would perhaps encourage researchers to review the code? A couple of examples:

• https://github.com/bugcrowd/disclosure-policy/blob/master/setting_up_a_vulnerability_disclosure_program.md
• https://www.hackerone.com/blog/Vulnerability-Disclosure-Policy-Basics-5-Critical-Components

[brad-jones]

As you do, I just published https://github.com/brad-jones/winsudo & then stumbled over this.

In terms of helping to solve the trust problem. It would be nice to just have a simple layman's terms description of how it currently works. I'm no low level Windows kernel expert and I'm unlikely to ever be one but just having a basic understanding of what this tool actually does under the hood would go along way to people like myself trusting it. I know that's still not good enough for the enterprise client but it's a start right.

It looks like this tool has gone through a few different mechanisms of achieving the elevation with the latest being this "TokenSwitch" mode. I'd love to understand what's going on here.

At a glance it also appears to use some sort of RPC perhaps not dissimilar to what I have done with my winsudo package?

How does the caching work?

Apologies if there is a nice blog post or some other doco covering all this off but I couldn't find anything obvious.

[gerardog]

Do you think having a formal vulnerability disclosure policy would perhaps encourage researchers to review the code?

Hi @johnyesberg, and all, what do you think of the new disclosure policy?

See e817b78df7a61005b1929b07d2351338c914d281

In terms of helping to solve the trust problem. It would be nice to just have a simple layman's terms description of how it currently works. I'm no low level Windows kernel expert and I'm unlikely to ever be one but just having a basic understanding of what this tool actually does under the hood would go along way to people like myself trusting it. I know that's still not good enough for the enterprise client but it's a start right.

It looks like this tool has gone through a few different mechanisms of achieving the elevation with the latest being this "TokenSwitch" mode. I'd love to understand what's going on here.

You are 100% right @brad-jones. To be honest, I wrote a few things but never reached a quality level that I was proud enough to publish. Besides, it is a quite extensive matter.

In a nutshell this are the modes, in the order they were developed, each one deprecating the former:

Piped mode: The elevated instance runs with it's I/O redirected, and sends all I/O to the unelevated via named pipes. The user experience worse than using TELNET. VT mode: The elevated instance runs a VT pseudoconsole, and sends all I/O it to the unelevated via named pipes. Do not resize the window in this mode, please. Attached mode: The elevated window 'attaches' to the non elevated. The bridge is done by windows and CONHOST. Doesn't work with I/O redirected (where piped excels) TokenSwitch Mode: (current default) Using an undocumented api, the unelevated creates the new process in paused mode, then the elevated replaces it's token via WinApi, and its execution is resumed.

Or configurations: SecurityEnforceUacIsolation=true: This is piped mode with a hack where the Input is closed, making theoretically impossible for an unelevated process to drive the elevated world. I don't have real proof that this is less exploitable than the default, hence I never publicily documented this setting. ForceNewWindow: An idea (spec still pending), to add a config setting where all elevations are done in new windows, so no isolation is broken. If I/O is redirected, the result may be streamed to the unelevated. This is still only and idea because the user experience would probably be .

Probably a few things didn't make sense? Full documentation is still debt.

Bottom line: I probably need help from a Windows Security Team, or InfoSec experts: to discuss how deep the rabbit hole is and to what extent something more secure is achievable.

[shoogle]

Bitwarden regularly hires external security companies to audit their code. This is probably way too expensive for you, but might be within reach of a GoFundMe or similar campaign.

Or to take your idea of community audits further, you could try to find organisations that are already using gsudo and publish their names under a list titled "Who is using gsudo?". It's possible that one of these organisations already conducted an internal audit of gsudo before they approved it for internal use (banks insist on this for example). Perhaps they would be willing to share their findings with the community?