The Problem with Open Source Software Security

Reporting bugs in open-source software is a nightmare. Reporting bugs to proprietary software vendors is easy. Apple lets you submit a report on the web and track its progress. Microsoft has its own security response center. Choose any company and I bet you can at least find a point of contact to report a bug. Corporate software vendors are motivated to make this process as streamlined as possible because they make money on their software; I’m sure there is an inverse relationship between the number of bugs and the amount of profit. This is not the case with open-source software. Let’s walk through this hypothetical.

Say you find a write-what-where primitive leading to code execution in some package hosted on Ubuntu’s package repository What’s your first move? Do you alert the Ubuntu security team? What about the upstream package provider, like Debian’s package repo? They’re motivated to ensure that end-users of their distribution are protected and safe, but they probably can’t help you resolve the bug. At most, they can apply a git patch you send them; they didn’t write the flaw.

The Original Maintainers

Notifying the project’s original maintainers is probably the best way to get the bug patched, but this also has problems. Ubuntu supports a lot of packages. Like 60,000. Not all of those packages are current and maintained. You’re lucky if the maintainer is listed and the project is still active. I often see an outdated or broken reference to some SourceForge or Mozilla community that probably hasn’t worked in years. Relatedly, some users will archive these old projects (from SourceForge or wherever) onto their own GitHub accounts. Now there are two levels of indirection to sort through. Can you find the original author? Do you report the bug to the archivist (who may or may not have contributed to the source)? What if multiple archivists aren’t linked together by some common fork?

CVE ID

What about getting a CVE ID, sending it to MITRE, and being done with it? CVE IDs are actually kind of difficult to get if you go through MITRE. It takes ages to hear back (in my experience, tho maybe I’m just not finding hot enough bugs). Furthermore, now you have to consider if you want to publicly announce the bug before a fix is in place (called full disclosure).

DIY

You could patch the bug yourself and share your fix with the world. I genuinely think this is the best-case scenario. Even if you can’t find the original authors, the distribution package maintainers will at least apply your patch to their hosted source. Yet, it is more involved than just shaking out a bug and writing a report. You might not have expertise in the domain. It might just be time-consuming. It’s not feasible in many cases.

Existing Solutions

For their part, GitHub and GitLab have done a great job wrestling this problem. On GitHub, users can privately notify developers of a security issue. If it’s enabled. It’s never enabled. I’m curious why it’s not enabled by default. I’m picturing a private issue that would be created for developers and researchers to collaborate. GitLab has this natively for all tiers with confidential issues. This makes it super easy. It’s a plus that many GNU projects make GitLab their home. On GitHub, what usually happens, is that you open a public issue, you and the maintainer exchange PGP keys, and then communicate over e-mail. It’s a pain.

Outside of source code hubs, some companies have sprung up to try and tackle this issue. The prime example is huntr.dev. You can report failing test cases there and automatically notify maintainers if they are active in the program. They’ll even pay you for some of your bugs. However, it’s not a notification platform. It’s a marketplace. You’re selling them your bugs. If it’s a good bug, both parties make money. If it’s a meh bug, at least it promotes their platform. Nothing against them, but it’s not my thing.

A more established open-source community is the OSS Security mailing list. Everything is public, and there is no engaging directly with the maintainers. They may help you patch the bug, though. 🤷One nice thing is that OSS Security provides a mechanism for uniquely identifying bugs with their Open Vulnerabilities and Exposures ID (OVE ID). They are super easy to generate.

Taking it to the Logical Extreme

In the hypothetical, we considered just one bug. What about more? What about 179? Seriously, how do you report 179 de-duplicated failing test cases to a maintainer (if you find them)? Do you triage all of them and write multiple reports, consuming months of your life? Do you send over all of the failing test cases and say, “have fun”? Do you yourself become a maintainer on the project?

Now, what if it’s not all in one project? What if this represents one bug in 179 projects? Now reconsider the hypothetical in this case. How do you go about reporting all of those? The methods we have now are not scalable to accomplish this.

Addressing the Issue

There is no solid conclusion. I ask a lot of questions because I have not yet figured out the answer. The fragmented system is frustrating. Maybe together we can come up with something great. Like a pipeline for reporting bugs that doesn't suck. How would you approach it? I’d love hear over on LinkedIn.