
Ask HN: How do you responsibly report security bugs to open-source projects? - WinonaRyder
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&#x27;ve only made minimal effort to contact said maintainer - no surprise I haven&#x27;t gotten a response so far.<p>I don&#x27;t want to draw any attention to it in a bug report and I&#x27;m not sure it&#x27;s OK to dig up email addresses from commit logs either.<p>It also got me thinking: why don&#x27;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&#x27;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.
======
LinuxBender
_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.

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

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

~~~
LinuxBender
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.

------
hlieberman
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.

------
tlb
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.

~~~
oefrha
> 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.

~~~
MHM5000
Off-topic:

C++ Newbie here!

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

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

------
pabs3
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...](https://www.opensourcesecuritypodcast.com/2019/12/episode-174-github-
turns-security-up-to.html)

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](https://cve.mitre.org/cve/request_id.html)

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

------
antongribok
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.

------
sb8244
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.

------
edoceo
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.

~~~
technion
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.

------
johnny_reilly
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.

------
WinonaRyder
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.

------
chrismatheson
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?

------
dependenttypes
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.

------
jve
What does MIA stand for?

~~~
andruby
Missing In Action

[https://en.wikipedia.org/wiki/Missing_in_action](https://en.wikipedia.org/wiki/Missing_in_action)

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

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

~~~
thenewnewguy
"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.

~~~
mannykannot
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.

