Tag Archives: patches

Android – Bitcoin vulnerability – Exploit in the wild.

Photo credit: Katarzyna Kieliszek

A blog post over at bitcoin.org alerts currency holders using an Android wallet to a serious underlying vulnerability that could leave their wallets open to would be thieves.

The blog post says only that “an underlying component of Android” contains the flaws that leave Android bitcoin wallet holders at risk of pilfering. However bitcoin wallet app developer Mike Hearn posted to the bitcoin developer mailing list that the exact component is the Android implementation of the Java class SecureRandom.
Continue reading

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?

Disable Java not Bob’s Java Jive (or JavaScript)

This is not Java

It is a common misconception that there is a strong relationship between Java and JavaScript, many people even use the two words interchangeably. In fact this similarity is based entirely on a technology name change from LiveScript to JavaScript by Netscape,who developed the technology back in 1995. This name change was widely seen as a marketing ploy at the time. In the long term it has been responsible for much confusion.
Java is not JavaScript is not Java. It’s not even the World Famous Bob’s Java Jive. With the recent zero-day vulnerability in Java that has come to light this week, understanding that this distinction exists has become crucial to your online security.
A vulnerability in the most recent version of Java means that attackers can fool you into visiting a malicious or compromised web site and, without any interaction use the vulnerability to install malicious code onto your computer. It has already been used to install a well known backdoor, giving criminals remote control over the infected machine and been incorporated into several attack tool-kits, both professional and criminal.
The fact that Java is a cross-platform environment means that it is relatively simple to create attack code for most major operating systems.
You are vulnerable to these attacks if you have Java 1.7.anything installed. This version is the most current and default version for Microsoft Windows computers. If you are using MacOS, the latest version of Java available through Apple’s Software Update is and is not vulnerable. However, if you have been keen to keep yourself patched against past vulnerabilities by staying up-to-date (normally very good advice), then you may have visited java.com where Oracle is serving up the latest, vulnerable, version to MacOS users as well.


In the absence of a patch for this widespread and already abused vulnerability, the best advice is simply to disable Java in your web browser and this is where the distinction between Java and JavaScript becomes key, otherwise you may very well end up disabling the wrong thing and remaining at risk.


To disable Java in Internet Explorer:
In the Tools menu of Internet Explorer, select Manage Add-Ons and disable Java™ Plug-in SSV Helper and Java 2™  Plug-in 2 SSV Helper

To disable Java in Firefox (MacOS & Windows):
In the Tools menu select Add-ons and disable the Java Deployment Toolkit, Java™ Platform and/or Java Applet Plug-in


To disable Java in Google Chrome:
Select the Wrench icon in the top right of the Chrome browser window, choose Settings and right at the bottom choose Show advanced settings. Find the Privacy section and click the Content Settings button. Find the Plug-ins section and click the Disable individual plug-ins, look for Java and hit the Disable link. That one is well-buried!


To disable Java in Safari for MacOS:
In the Safari menu, open the Preferences dialogue box and select Security. untick the box Enable Java
To disable Java in Safari for Windows:
Click the Gear wheel in the top right of the browser window and choose Preferences, select Security and untick the box Enable Java.
JavaScript is a whole different security conversation, but for the purposes of this current vulnerability it is irrelevant.
Image credit: Homini:)’s Flickr Photostream under creative commons.