Ask HN: How do you responsibly report security bugs to open-source projects? | Hacker News Reader

Ask HN: How do you responsibly report security bugs to open-source projects?

84 pointsWinonaRyder37 comments

I found a DOS vulnerability in an Open Source project whose maintainer seems to be MIA at the moment. I found it in-the-wild, but not as an exploit so I've only made minimal effort to contact said maintainer - no surprise I haven't gotten a response so far.

I don't want to draw any attention to it in a bug report and I'm not sure it's OK to dig up email addresses from commit logs either.

It also got me thinking: why don't we have a Bug Bounty-like program for Open Source projects as a whole. What I mean is somewhere where we can post sensitive bugs (even for no pay) and have someone who knows what they're doing guide the process of reporting it responsibly. I know some big projects have this, but e.g. look at the mountain of dependencies that most projects are built on - many of them barely maintained.

View on HN

not sure it's OK to dig up email addresses from commit logs

By all means, grab emails from commit logs, email the authors. I do it all the time and they most certainly appreciate the opportunity to fix an embarrassing bug before the entire OS community is aware of it.

Yes

Aye, this is what the commit logs are for, and why it's important to be reachable at your git config user.email. Git user's email addresses are not private.

I'd be much happier getting security concern inqueries via my git log email than the recruiter spam I've gotten in practice!

Yes, if it is a small project by all means do that

For bigger projects there's usually a security@ email address or similar

I do that too, though I usually also give the code author a heads up first, so they are not surprised when their SOC reach out to them. Sometimes security orgs can be a little abrasive or terse which can be unnerving.

If the software is packaged in the big distros, you should feel free to go to their security teams and report it there. They can do the fix directly if the maintainers are truly MIA, and they may have the ability to get in touch with people easier than you will alone.

If the vulnerability is really severe, you could also report it to US-CERT; they can walk it through the coordination process for you, even anonymously.

Keep in mind that many pieces of software are not intended to be resistant to DoS vulnerabilities. For example, any C++ compiler can be made to use exponentially large amounts of memory and CPU time by feeding it a specially crafted program; this is not normally considered a DoS vulnerability because you aren't supposed to feed untrusted input to your compiler.

> any C++ compiler can be made to use exponentially large amounts of memory and CPU time by feeding it a specially crafted program

Doesn’t even need to be specially crafted, I wrote a <100 line C++ program to solve a Project Euler problem just yesterday that runs in 0.5s with ~2.5GB of RAM but takes clang++ 50GB of RAM to compile. I could easily tweak a param to make it use any multiple of that to exhaust the RAM on any workstation. Surprised me a bit honestly.

Off-topic:

C++ Newbie here!

I would like to see that code and its tweaked version. If at all possible.

Quick way to do it would be to calculate some high index in a fibbonacci sequence at compile time using templates.

I think this might be considered a bug if it's a reasonable program

Probably just over-(ab)use of templates. :)

My program’s much more mundane than using templates as a Turing complete language at compile time. Just a slightly tricky static node pool for a persistent segment tree. Allocating a larger pool causes more RAM usage at compile time, at a 20+x ratio. Probably not gonna share code since I didn’t bother to distill it down to the cause.

+1 on this. DOS are usually not considered security vulnerabilities. There is really no need to go to extreme length to keep one confidential. Just fill a github issue in the project.

Security vulnerability or not, it's still a DOS. Imagine having just a few requests (like less than 10) to your site consume 100% CPU until the server process is killed or restarted.

It depends on the exploit but DOS ARE security vulnerabilities and their impact can range from very low to high severity.

And please OP don't listen to this and report the vulnerability responsibly even if you're not so sure if it's a security vulnerability or not

If it is on GitHub, they recently launched a bunch of security related features, including guiding the reporting process, obtaining CVEs and a bounty program:

https://www.opensourcesecuritypodcast.com/2019/12/episode-17...

Otherwise, try to go through the CVE process so that redistributors of the project (such as Debian or RedHat) fix the issue in their copies of the project:

https://cve.mitre.org/cve/request_id.html

Thanks for the links. That Github Security Lab looks particularly interesting.

If you are talking about a project with a single maintainer, why is not OK to search for emails in the commit logs?

For a small project I think it's perfectly fine if you feel this DOS attack is a legitimate concern.

I'll take this time to say that every open source project should have a contributing file with a way to report security bugs properly. It's as simple as providing an email address for security bugs.

In this case, yes. Dig up any info to try to contact the author privately.

Is this where that .well-known/security.txt could help or is that not workable?

There are dozens of bounty like programs but authors have to opt-in to those.

You could also make a fork, with one commit to fix that issue publish with no fanfare. Then at least the fix is out there.

I think security.txt[1] would definitely help here!

[1] https://securitytxt.org/

It kinda depends on where in the dependency chain the vulnerability is.

For instance, if someone found a security bug through Twitter's verification process, then a security.txt might be a good place to start. However, if the problem lies with the server software they're using, or the DB software, then emailing twitter won't really do all that much for everyone else using the software and you can't really expect Twitter to bring it up the chain, so to speak.

A recurrent discussion around security.txt is the question "would it actually solve the problem?".

In this case, we've been advised the project's maintainer is MIA. A security.txt file containing a maintainer's email address wouldn't change anything, as WinonaRyder indicates they have already tried to contact them. Given we appear to be talking about a software product, it's also not clear whether security.txt would just contain contact details for a web developer not related to the software itself. There are many projects living on Github that can't use the /.well-known/ URL after even if they wanted to.

That's assuming the author opted in to created a security.txt, which they would have to do in just the same way as any other program.

I maintain a number of widely used open source projects. A number of years ago I received an email from an ethical hacker who (if memory serves) works for GitHub.

He had identified that my 2FA was off and that my password had been leaked in a hack. He was able to prove to me that he was able to update the source of my projects and publish to npm.

I was initially terrified and massively taken aback. I quickly 2FA-ed all the things and I remain very grateful for the report.

Send the email. The MIA problem is tricky; if there's no maintainer (and you don't want to fork, fix and become a maintainer) then I'm not sure what you can do.

Too many to reply to directly, but thanks for all the links and advice. I will try to contact the maintainer via email and see what happens.

A little more context:

This project is a library that can appear in internet-facing servers and when the bug is triggered, the process can proceed to consume 100% CPU.

In my case I found it due to bots, but they only triggered it by accident.

Could you write it up and submit it as a usual bug report/ issue, but take the important bits and encrypt them using the public keys of any active contributing members?

Publish it to the wide world, preferably by sending it to a public security mailing list that also has an html viewer - but make sure to also mail the maintainer and all maintainers of forks and distros that you can find in the same email.

It is important everyone who is using the software is aware of any issues right away so that they can patch it themselves if they need to. It is also important that the maintainers of forks are not disadvantaged.

Remember, after all the maintainer of the "original" could be a malicious actor, or it could be possible that they were replaced by one such malicious actor.

What does MIA stand for?

Missing In Action

https://en.wikipedia.org/wiki/Missing_in_action

Publish it on the internet. Keeping it to yourself and the company is security by obscurity which the security community frowns on.

'Security by obscurity' is deprecated because obscurity alone does not lead to security. This in no way promotes, endorses or justifies irresponsible disclosure.

"Responsible disclosure" is a buzzword made up by companies to bully security researchers into keeping quiet about vulnerabilities for months. If the OP is unable to contact the maintainer because they are missing it would be irresponsible to keep quiet about the bug.

Responsible disclosure is a valid concept that some companies attempt to abuse. In the scenario you propose here, I would probably contact CMU's CERT division.

Non-disclosure continues to allow security issues to slide by. Companies need to know security is their absolute #1 priority to the extent that it will damage the business every time one of these issues is exposed. Today they have no incentive to fix issues and prevent future ones as the exposure is minimized.

Publishing can be reasonable but it seems like OP wanted to contact the author first, which is a good idea IMHO.

Reply on news.ycombinator.com