Researcher Disclosure

Researchers have an especially unique challenge when reporting flaws in Open Source Software. There are countless groups that the flaw could be reported to, and many of them don't have any sort of formal security contact. The purpose of this guide is to help give unfamiliar Researchers guidance when reporting security flaws they find in Open Source Software.

Once a researcher has identified a flaw, the next logical step is to write up the findings and tell someone. In the Open Source environment, this is not always a clear objective as there are numerous possible groups that could consume this information. An even bigger challenge lies in the fact that not all Open Source projects have a security team, or a security contact. The three suggested choices for reporting flaws are:

The actual authors of the software in question. By contacting the project you can be assured that the fix will make it upstream. Many upstream projects are not terribly good at dealing with researchers though.

The “vendor” for most users. The distributions tend to be fairly good about contact upstream and ensuring that things go smoothly. Most distributions will go out of their way to keep all involved parties happy. The downside to the distributions however is that if they don't ship the particular application you've found the flaw in, they probably won't be interested.

Groups like CERT, vendor-sec, oss-security and oCERT can be good candidates for informing about security flaws. Some subset of the members will likely ensure that the fixes go upstream, and word gets out of what's being fixed. These groups tend to be quite organized and are very used to bringing all affected parties together.

Add a page for groups which handle security vulnerabilities

When you deal with an Open Source project, you will often be dealing directly with the person who write this flaw into the software. Many Open Source developers treat their bugs very seriously, and can get quite upset over the idea that they added a security flaw to their project. It is unwise to tell these people that their code sucks, or that it's written poorly. If you upset the upstream developers, it is quite unlikely that they will have nay interest in working with you, or giving you proper credit for your find.

Many Open Source projects are not familiar with the usual security protocol followed between researchers and vendors. This can be as trying for the projects as they are for the researchers. It is in your best interest to make your intentions as clear as possible. Don't assume that the project knows what you expect. Some useful things to relay to the projects are:

If you have any interest in keeping the information under wraps, let them know, and state what you expect of the embargo. Numerous Open Source projects like to commit their fixes to a public source management system before an embargo date. If you feel this is unacceptable, tell them ahead of time.

If you want your name spelled a certain way, or if you don't want to be mentioned in their announcements and changelogs, let them know. Most projects are happy to provide credit, and some don't even think of it unless they're told.

Remember these aren't security people. They won't understand much of the terminology or concepts you are going to be alerting them about. Not everyone understands that a “double free” or “buffer overflow” are anything but a bug. There are however certain limits that can be reached. If you find a project being unusually hard to work with, don't be afraid to contact one of the other groups to disclose your findings.

Please see the page CVE.