Monthly Archives: September 2012

Make vendors liable for vulnerabilities?

Where does the Buck stop?


 
Should software vendors be liable for vulnerabilities in the products they sell? Are they already liable to some degree, or would new legislation be required in order to make it so? These are interesting questions, sure to provoke strong opinions on both sides of the fence.
 
In almost every case, when you buy a software product, a close inspection of the End User License Agreement (EULA) will reveal a host of exculpatory clauses, exonerating the vendor of responsibility for any kind of direct, indirect, consequential (and just about every other applicable adjective) damages “whatsoever” that may arise from the installation or use of (or inability to use) the software product. But is this reasonable or indeed fair?
 
Software products are not a tangible asset and as such escape much of the legislation that applies to the sale of goods and their fitness for purpose. However the majority of successful compromises of systems and enterprises arise from the exploitation of a vulnerability or flaw in an application or operating system, and often results in direct financial loss.
 
At first glance the case for enforcing some kind of liability on vendors seems obvious. Make the vendor legally responsible for the quality of their product and thus increase their focus on writing secure code. Lower the number of vulnerabilities in published product and create an ecosystem where vendors routinely produce more robust software. Indeed the idea is not a new one. A House of Lords Science and Technology Committee report on Personal Internet Security from 2006/7 reached the following conclusion (8.15):
 
We therefore recommend that the Government explore, at European level, the introduction of the principle of vendor liability within the IT industry. In the short term we recommend that such liability should be imposed on vendors (that is, software and hardware manufacturers), notwithstanding end user licensing agreements, in circumstances where negligence can be demonstrated. In the longer term, as the industry matures, a comprehensive framework of vendor liability and consumer protection should be introduced.”
 
Similar calls have been echoed by such luminaries as Bruce Schneier and Viviane Reding, but what might be some of the consequences and does adequate cover exist already?
 
The first and most obvious is that it may well increase the cost of developing software, the impossibility of creating invulnerable code would oblige vendors to take out unlimited liability insurance contracts against the inevitable stream of lawsuits, the cost of this being passed on to the consumer. Particularly when the temptation might exist for companies to skimp on even the most basic of security practices, passing the buck to the software vendor when a breach occurs. This could effectively be the death-knell for free software.
 
A second unintended consequence could be equally costly for the consumer. What happens when the vendor releases an updated product addressing identified flaws with an earlier version? Would cover cease for the now legacy versions, obliging consumers to commit to expensive and perhaps unnecessary upgrades to continue to benefit from their newfound legal protection?
 
Where do we truly stand right now, are those EULAs worth the bits they’re written on? Is new legislation required or even worthwhile? In the traditional last refuge of the scoundrel, I Am Not A Lawyer, so I’ll defer to the opinion of a colleague who is:
 
If a software vendor negligently exposes its software to vulnerabilities, in particular because of defects in the software or non-compliance with best practices, under current law it can be held liable for all consequences arising therefrom. Exculpatory clauses in EULAs can limit liability but the validity of such clauses have to be examined on a case-by-case basis
 
Bear this in mind though; the vast majority of breaches are the result of the exploitation of vulnerabilities for which a patch has already been released by the vendor. Even with a physical good such as a car, the vendor is not required to fix the (potentially life-endangering) fault, only to issue a recall and make the necessary changes. Is it really so different, and if you don’t respond to the recall notice, or install the patch, where do you think the liability is going to lie in those cases?
 

Internet Explorer. Better the Devil You Know?

Better the Devil We Know?

Image: Steve Dinn


 
Over the past few days, the polemic over which browser is the “most secure” has reignited, largely due to the recent zero-day vulnerability in Microsoft’s Internet Explorer. The extent of the vulnerability has led to an overwhelming chorus of well-meaning advice  to switch to an alternative browser. This  has been repeated by security experts, CEOs and even the German government (again), but just how realistic, and more importantly how helpful, is it?
 
Security is not based on knee-jerk reactions to individual events; security is dependent on building a strategy that lowers exposure and risk over a period of time. It should also avoid change for change’s sake as the unfamiliarity that adoption of any new technology engenders brings with it its own set of very human vulnerabilities.
 
The two most popular alternatives to Internet Explorer (and the ones getting most of the current recommendations) are Google’s Chrome and Mozilla Firefox; neither of these is immune to vulnerabilities or zero-days. In fact if you consider the available evidence regarding the rate of occurrence of vulnerabilities, you could certainly justify your continued use of Internet Explorer.
 
According to this blog post, in 2011 Google’s Chrome had an all time high of 275 new vulnerabilities reported, the current peak of an upward trend since its day of release. Mozilla Firefox, while currently trending down from its 2009 high, still had a reported 97 vulnerabilities. Microsoft’s Internet Explorer has been trending gradually down for the past five years and 2011 saw only 45 new vulnerabilities, less than any other browser except Apple’s Safari, which also had 45. Of course raw numbers of vulnerabilities are almost meaningless unless we consider the respective severity, but there again, of the “big three” the statistics favour Internet Explorer. If zero-day vulnerabilities have to be taken into consideration too, they don’t really do much to change the balance, Google Chrome 6, Microsoft Internet Explorer 6 and Mozilla Firefox 4. Of course different sources offer completely different statistics, and simple vulnerability counts are no measure of relative (in)security of browsers, particularly in isolation. However, it cannot be ignored that vulnerabilities exist in every browser.
 
The simple truth is that we pay undue attention to zero-day vulnerabilities such as this one, the very name strike fear even into the hearts of people who aren’t really sure what the phrase means. Enterprises, but also individuals have a hard time keeping their browsers up to date with just the patchable vulnerabilities that far outnumber the occasional zero-days that we see. In any case attacks are increasingly aimed not at browsers but at application plug-ins like QuickTime, Flash or Acrobat that can be used in multiple different flavours of browser on multiple Operating Systems. Either that or they are simply attacks aimed at the individual using the browser (like phishing, pretexting or other social engineering attacks).
 
Face facts, your browser will not keep you safe, whoever made it. You need to take steps to keep yourself safe, whichever browser you choose.
 
Every browser has its flaws, vulnerabilities and patches (or lack of them). It’s different strokes for different folks and various security tools or techniques require varying degrees of familiarity with the browser, with technology or with threats in general in order to effectively protect you without ruining your Internet experience beyond redemption.
 
In most cases the best advice is to stick with the browser with which you are most familiar but to take steps to secure it, including applying security patches as soon as they become available (MS12-063 that fixes this particular zero-day is available here). If you suddenly switch to using a browser with which you are unfamiliar, your lack of familiarity may leave you less secure than you were before.
 
Ultimately security software is as necessary for a PC as a seatbelt is for a car and it should be doing a much better job at protecting you from these kinds of vulnerability and exploit, whether or not a patch is available. If you want to get an idea of how that is working out, then this report might be a good starting point.