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:





Stay in touch