The Mozilla Foundation has confirmed the existence of a critical zero-day vulnerability in its popular Firefox web-browser – but says a fix won’t arrive before the end of the month.

Posting on its official security blog, the Foundation confirmed a vulnerability which it has “determined to be critical and [which] could result in remote code execution by an attacker.”

The good news? The Foundation has already developed a fix, which is currently undergoing quality assurance testing prior to a general roll-out. The bad news? That roll-out isn’t due for at least a week, potentially leaving Firefox users vulnerable to attack.

The bug, originally discovered by security researcher Evgeny Legerov last month, was posted publicly but without the code required to carry out an attack. However, it appears that Legerov was reticent to provide detailed information to Mozilla – with ARN pointing to a now-deleted post on the researcher’s blog admitting to “ignoring e-mails” from the foundation and refusing to provide enough detail for the Foundation to reproduce the exploit.

Thankfully, the Foundation says that Legerov has now provided “sufficient details to reproduce and analyse the issue,” meaning the flaw can be fixed and the patch prepared for a planned 30th of March roll-out. Those who are itching for a fix and don’t mind running code that isn’t as well tested as a standard release are advised to grab a copy of the nightly build of Firefox 3.6.2, which contains the patch to prevent the exploit from running.

Link to article: Mozilla confirms 0-day Firefox flaw

Computer scientists say they’ve discovered a “severe vulnerability” in the world’s most widely used software encryption package that allows them to retrieve a machine’s secret cryptographic key.

The bug in the OpenSSL cryptographic library is significant because the open-source package is used to protect sensitive data in countless applications and operating systems throughout the world. Although the attack technique is difficult to carry out, it could eventually be applied to a wide variety of devices, particularly media players and smartphones with anti-copying mechanisms.

“Wherever you need to verify the origin of a piece of software or a piece of information, those building blocks come in handy,” said Karsten Nohl, an independent security researcher. Nohl has in unrelated attacks broken encryption in widely used smartcards and cordless phones. “The OpenSSL library provides much more than just SSL.”

The scientists, from the University of Michigan’s electrical engineering and computer science departments, said the bug is easily fixed by applying cryptographic “salt” to an underlying error-checking algorithm. The additional randomization would make the attack unfeasible.

An OpenSSL official, who asked that his name not be published, said engineers are in the process of pushing out a patch and stressed the attack is difficult to carry out in real-world settings.

The university scientists found that they could deduce tiny pieces of a private key by injecting slight fluctuations in a device’s power supply as it was processing encrypted messages. In a little more than 100 hours, they fed the device enough “transient faults” that they were able to assemble the entirety of its 1024-bit key.

“This is probably not as much of a threat to a server system as it is to a consumer device,” said Todd Austin, one of the scientists who devised the attack. “The place where this would be more applicable would be if you want to attack a Blu-ray player (where) you have an environment where someone is giving you a device that has a private key to protect intellectual property and you have physical access to the device.”

Servers, by contrast, would be much harder to attack because they are generally located in places that prevent people from manipulating their power supply. But that doesn’t mean they’re immune to such exploits. In events where a machine was overheating or otherwise experiencing power fluctuations, the vulnerability will cause servers to leak secret data that could be intercepted by attackers.

The scientists are also experimenting with the possibility of exploiting the bug using lasers or natural radiation sources, they said.

The attack is enabled by what the researchers described as a “severe vulnerability” in the OpenSSL innards that carry out authentication based on the RSA public key encryption algorithm. It resides in the so-called fixed window exponentiation algorithm of the open-source crypto library, which is used when errors arise. By triggering a single-bit error in a multiplication operation, the scientists were able to force OpenSSL to divulge 4 bits of the secret key.

Once they gathered about 8,800 malformed messages from the targeted device, they fed the data into an 81-machine cluster of 2.4 GHz Pentium-4 systems running a custom-designed algorithm. They applied the technique to an embedded hardware device consisting of a Sparc processor running a Linux operating system and were able to extract its 1024-bit private key in 104 hours.

The researchers said it may be possible to apply the method to other crypto libraries, such as one offered by the Mozilla Foundation.

The other two scientists working on the project were Valeria Bertacco and Andrea Pellegrini. Their paper (pdf) will be presented next week in Dresden at the Design Automation and Test in Europe conference. ®

Link to article: ‘Severe’ OpenSSL vulnerability busts public key crypto

Google is to pay up to $1,337 for each confirmed vulnerability in Chrome or Chromium - although it's first come, first served.

According to a post on the official Chromium blog – via PC World – the advertising giant is looking to pay $500 (£313) per confirmed vulnerability found in the Chromium codebase, as used in the Chrome browser for Windows, Mac, and Linux and also in the still-early Linux-based Chrome OS.

As a further incentive, any bug deemed “particularly severe or particularly clever” by the company’s panel of security experts will be boosted up to the rather amusing sum of $1,337 (a rather more prosaic £837). While the company hasn’t given an indication of exactly what criteria will be used for this judgement, the blog posting does refer to “High and Critical impact bugs” as being of particular interest.

This isn’t the first time an open-source project has had money thrown at it in order to increase the number of eyes checking for security holes: Google readily acknowledges that its latest venture is based on a Bug Bounty already in place at the Mozilla Foundation – creator of Firefox and Thunderbird – which also pays $500, along with a Mozilla T-shirt. Unlike Mozilla’s version, Google doesn’t plan to equitably split the proceeds in the event of multiple independent researchers submitting the same bug – operating instead on a first-come first-served basis.

Likewise, anyone who has worked on the particular section of code affected by the bug is disqualified from applying – in order to prevent bugs being planted for later ‘discovery.’

The act of paying for vulnerability reports often gets a mixed reception from the security community, with some seeing it as a way for companies to ‘hush’ security researchers and prevent public embarrassment while others see it as a way of encouraging ‘responsible disclosure’ of critical security flaws. As a way of pointing researchers toward the latter point of view, Google has stated that it has no problem with the details of security bugs being made public “once fixed,” although hints darkly that bugs disclosed publicly before being brought to the company’s attention are unlikely to see any cash.

The move comes as Google beefs up Chrome’s security, offering support for the Strict Transport Security HTTP header, the Origin header, the anti-clickjacking X-Frame-Options header, an in-built cross-site scripting filter, and support for the security enhanced postMessage API.

Link to article: Google to pay for Chrome bugs