Home > Security

Computerworld - The annual summer bug parades at Black Hat and Defcon always leave me questioning motives. This year, as in the past, we witnessed a deluge of vulnerability disclosures, and many of them seemed to me to be beyond irresponsible. They were attempts at naked glory mongering, and that just plain stinks.

Before I defend my claims, I'll say that I am a huge fan of freedom of speech. I don't begrudge anyone the right to publish the results of their work. That's not my point. My point is that it isn't always responsible to exercise one's rights.

I'll use two of the vulnerabilities disclosed last week to illustrate what I'm talking about: the Apple iPhone SMS vulnerability and the Computrace LoJack laptop firmware vulnerability. Please note that I'm basing my statements on published reports of these vulnerabilities. I have no inside knowledge of how these issues were handled either by the product vendors or by the analysts who discovered and reported them.

According to the published reports, both of these vulnerabilities were reported to the respective vendors a fairly short time prior to Defcon and Black Hat, which were held at the end of July, and neither vendor had repaired its respective security defect by the time it was unveiled at the security conferences. There are people who would have you believe that this demonstrates how irresponsible these vendors are. Not so. It's the researchers who publicized the vulnerabilities who have been irresponsible. That's not to say that the product vendors are blameless. I'll address that below. (For the record, Apple rushed out a fix the day after the iPhone vulnerability was revealed.)

Call me a radical, but I find it irresponsible for someone to tell a vendor, "Hey, we found this vulnerability in your product, and we're going to let the world know about it well before you could possibly verify and repair the problem. Good luck with the fallout from that." Fixing a security problem can be a complex task that involves significant amounts of time and effort. If you give the vendor an artificial time limit that's unworkably brief, the vendor might well come up with a patch that stops the attack but doesn't fix the problem.

I'll explain that by using the case of an SMS vulnerability as an example. Let's say that we uncover a vulnerability in which a text message containing the string "<foo>" could crash the phone (or worse). So, we go to the vendor and demonstrate a text containing "<foo>" and how it clearly crashes the phone. Now we tell the vendor we're going to publish this in a short period of time unless it releases a patch.