Software vendors and vulnerability policies
It is pretty much an accepted fact thatvulnerabilities are everywhere these days. They can affect every pieceof software available, whether it is from major vendors (Microsoft,Cisco, etc.) or if it has been written by hobbyist programmers (thosebuilding a Web app, for example). These vulnerabilities can surface onthe public landscape in a wide range of situations; from zero-dayattacks, all the way over to the other side of the spectrum withresponsible disclosure. However, the responsibility does not restsolely on the shoulders of the vulnerability researchers—vendors should(and do, in most cases) have an obligation to be responsible as well.The bottom line is, software vendors should hold some responsibilityfor their customer’s computer security. If a vendor’s software somehowthreatens a user’s security by containing a vulnerability, the vendorshould take responsibility for it and do what they can to protect theuser.
In light of this, I believe that Apple Computer’s actionssurrounding the potential vulnerability in Apple’s wireless securitytechnology that was exposed by Johnny Cache and David Maynor (at BlackHat in August) could be brought into question. Following thepresentation, Apple declined to directly acknowledge the potentialvulnerability. Their public announcements seemed to only focus on debunking the research.They didn’t release an advisory, or any sort of public notificationthat outlined advice on safe wireless use while they attempted toverify and fix, if necessary, the potential vulnerability.Additionally, they didn’t announce that they would start their ownresearch and notify their users of problems if and when they werefound. Apple’s actions made it seem that they believed that theirproduct was not flawed; therefore, they may have put their users atpotential risk—if indeed their wireless software did contain a securityflaw.
As a consequence, Apple’s response prompted a number of technicallyunqualified bloggers within the Apple “community” to attack the BlackHat researchers with impunity. The number of articles and blogs thatcondemned the researchers out of hand was quite astounding. It wasastounding, not only because of their zeal, but also because of thecontext of computer security in this day and age. After such majorevents as Code Red and Slammer (to name but two), we should all realizethat highly critical vulnerabilities are common and deserve properattention! This is compounded by the fact that Apple has released asteady flow of responsible security fixes over the last few years on aregular basis. In this context, I wish that Apple’s reaction had beenmore appreciative and inquisitive, instead of how it came across:apparently trying to sweep a potentially critical issue “under thecarpet.”
Even more surprising is the fact that Apple released multiplesecurity patches for their wireless technology shortly after the BlackHat presentation. Apple still seemed unwilling to acknowledge anysuggestion that the security patches were related to Cache and Maynor’spresentation; however, they did admit that the vulnerabilities werefound after an internal audit was launched, because of Cacheand Maynor’s presentation. So, albeit indirectly, I think Maynor andCache should be credited with those findings. Also, Apple is nowworking directly with Maynor’s company (SecureWorks) and although thenature of that relationship is currently undisclosed, it will likelyexpose more vulnerabilities. However, Apple still denies that there maybe a critical vulnerability in their software, which I think continuesto put their users in a potential risky situation.
So, what actions should Apple (or any software vendor) take whenfaced with potential security risks? An advisory should be made,stating that there is a possibility of a critical vulnerability. Tipsfor users on safe computing habits (specifically designed to defendagainst the potential vulnerability) should be posted until furtherinformation becomes available, and then updated with any newremediation advice once that information is compiled. The vendor shouldalso publicly initiate an internal audit and invite any researchersalong that could make a positive contribution. In a case such as this,upon finding a vulnerability it should be disclosed publicly and thevendor can shortly follow up with a patch. I believe that is theresponsible route to take. I can only hope that going forward, Apple,as well as all software vendors will learn from this and continue tomove away from denial and towards acceptance, followed by swiftremediation. Ultimately, vendors will become more confident in takingresponsibility for their vulnerable code when the need arises.