Towards Responsible Disclosure

Vincent Danen writes:

This week was interesting, dealing with the supposed “OpenSSH 0day” vulnerability stuff… rumours, innuendo, strange logs and packet capture files… it made for a long week trying to keep an eye on this and sort fact from fiction. Instead of focusing on the issue itself like other blogs and news sites are doing, I thought it might be interesting to look at some general resources to aid in the responsible disclosure of issues. I won’t focus on whether or not this issue is fact, or fiction, or who caused it, who furthered it, who took advantage of it, or why it was done in the first place. I’m more thinking of the fallout and the general panic it caused in a lot of people. The problem with pegging OpenSSH as vulnerable is that it is a service used on most servers, and is a service that, more importantly, is perhaps one of the most *vital* on servers. As seen with one hosting company that preemptively shut SSH accessibility off entirely, a lot of people just couldn’t get things done. Other services, like DNS, are equally vital, so the fallout can be quite brutal — even when something is not substantiated.

Another thing that makes this a problem today is the how fast information spreads, and how quickly something posted online is taken as gospel. For instance, starting a rumour like this is extremely simple and can be done by one person with a bunch of email addresses and a little bit of knowledge. This kind of social engineering can be used for a lot of things beyond just phishing (money, passwords, whatever). It can be used to sow confusion, which could be used as a smoke-screen to cover other nefarious deeds and redirect attention from the truly nasty things going on, and it can also be used to perpetrate such fear that people are essentially causing a Denial of Service against themselves and/or their customers simply because of rumours spreading like wildfire.

Either way, half the battle here is dealing with this stuff smarter and better, and more responsibly. Outfits that claim inside information but aren’t willing to share it are not being responsible. I’m not saying to necessarily share it with the public at large (right away, at least), as that may not serve the public’s best interest. But to provide crucial information to affected vendors (who can then take that and develop fixes to help a much larger audience) or upstream is absolutely the responsible thing to do.

To that end, I’d like to share a few links that can help people disclose issues they are aware of, or suspect, in a more responsible fashion. Holding info tight to your chest like a bag of sour gummies doesn’t help anyone but you, and even then, it can harm more than help. Individuals or companies that claim to have inside info and are working on a fix may not be the appropriate people to work on a fix in the first place. After all, who knows code better than the folks who wrote it? It makes more sense to take the issue and all the information you have and open up communication with the vendor/upstream in order to facilitate an appropriate fix that helps *everyone*, not just yourself. Quite often the fix you suggest is quite a ways from that which the vendor or upstream would use, and may cause more problems than it corrects. So getting appropriate people involved just makes sense, and peer review is an asset that the open source community understands — and views as necessity.

So here are a few links:

• OSS Security wiki: Security-related mailing lists contains a list of mailing lists you can use to get in touch with people who care and sincerely want to help. Many vendors are represented on both public and private lists, suitable for discussing issues that are currently public (oss-security) or those that are currently private (vendor-sec)
• What to do if I encounter a security issue is a page that documents how to deal with a security or suspected security issue and how to make sure it gets to the right people
• Backporting of Security Fixes talks about why many vendors, including Red Hat, backport fixes to packages rather than just updating to new ones (I‚Äôm including this because there was a lot of misinformation about OpenSSH versions being out-of-date and presumably insecure because they aren‚Äôt the latest-and-greatest)
• Red Hat Security Contacts and Procedures is the contact page for the Red Hat Security Response Team; please use it if you think you have something as we absolutely want and love to help with this sort of stuff and if you don‚Äôt know who to contact, chances are we can take care of that on your behalf

Responsible disclosure is really important, and everyone needs to do their part when it comes to this stuff. Irresponsible disclosure, or no disclosure, hurts more people than it helps and has been the source of many a headache for a whole lot of people over the years.