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
Help wanted: Could you Review/Audit or PenTest gsudo
source code?
#19
Comments
@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). |
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. |
Do you think having a formal vulnerability disclosure policy would perhaps encourage researchers to review the code? A couple of examples: |
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. |
Hi @johnyesberg, and all, what do you think of the new disclosure policy? See e817b78
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. Or configurations: 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. |
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? |
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:
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.
The text was updated successfully, but these errors were encountered: