Category: update

Sep 09 2015

Attack code exploiting Android’s critical Stagefright bugs is now public

Attack code that allows hackers to take control of vulnerable Android phones finally went public on Wednesday, as developers at Google, carriers, and handset manufacturers still scrambled to distribute patches to hundreds of millions of end users.

The critical flaws, which resides in an Android media library known as libstagefright, give attackers a variety of ways to surreptitiously execute malicious code on unsuspecting owners' devices. The vulnerabilities were privately reported in April and May and were publicly disclosed only in late July. Google has spent the past four months preparing fixes and distributing them to partners, but those efforts have faced a series of setbacks and limitations.

For one thing, some of the fixes—for instance, new versions of Hangouts and Messenger that blocked automatic processing of multimedia files sent over the MMS text protocol—were little more than Band-Aids. They blocked one of the most frightening of the attack scenarios while doing little to prevent others, such as exploits that relied on a user browsing to a malicious website. Also problematic, even when patches fixing the underlying cause were available to end users, at least one of them patching a flaw indexed as CVE-2015-3864 was so flawed that attackers can exploit the vulnerability anyway. Android apps such as this one from Zimperium—the security firm that first disclosed the Stagefright bugs—show that a Nexus 5 phone running all available patches remained wide open at the time this post was being prepared.

Read 2 remaining paragraphs | Comments

Feb 21 2015

Corrupt IPS definition package impacted 32-bit versions of Internet Explorer

Symantec is warning that 32-bit versions of Internet Explorer are being impacted as a result of a deployed definition package. We have released a fix for this issue through our LiveUpdate servers.
Sep 16 2011

Oracle issues rare out-of-band update for Apache DDoS vulnerability

Oracle, the giant enterprise database company – and, of course, owner of the erstwhile Sun Microsystems – has just published an out-of-band security update.

This is only the fifth time Oracle has issued an alert outside its routine quarterly patch cycle since introducing its own version of Patch Tuesday at the start of 2005.

The update introduces an updated version of the Apache web server, httpd, to Oracle’s Fusion Middleware and Application Server products. The former product includes Apache httpd 2.2; the latter includes Apache httpd 2.0.

Apache httpd was recently discovered to be vulnerable to an easily-exploited denial of service attack. The vulnerability, CVE-2011-3192, allowed even a single web client to trigger a huge number of simultaneous requests for large amounts of data. The flaw was exploited by sending a request for multiple parts of the same file at the same time.

(The Range feature of the HTTP protocol was intended to make it easy for web clients to restart interrupted downloads where they left off, or to permit large files to be fetched piecemeal and stitched together later. Apache httpd made it easy to misuse this feature by tolerating redundant Range requests which asked for many large and overlapping parts of a single file.)

Oracle doesn’t say on its public-facing web pages exactly how it patched the flawed Apache versions in its products.

The Apache Software Foundation has actually issued two official patches for httpd 2.2 relevant to the so-called byte-range flaw. Version 2.2.20 came out at the end of August, but that patch was recently superseded by 2.2.21, which is effect a patch for the 2.2.20 patch. Apache describes 2.2.21 as “[including] fixes to the patch introduced in release 2.2.20 for protocol compliance, as well as the MaxRanges directive.”

It’s not clear whether Oracle’s out-of-band fix includes the patch-to-the-patch, which appeared only three days ago.

And the previous official Apache httpd version, 2.0, hasn’t been patched since May, when 2.0.64 came out. Oracle, one assumes, has done its own back-port of the fix it applied to 2.2.

The fact that a patch-to-the-patch was necessary will no doubt cause more conservative IT administrators to say, “See. I told you that patches should never be rushed.”

In this case, however, I consider the glass half-full, not half-empty. I’d argue that the first patch greatly improved the situation, despite being imperfect. The second patch simply improved the improvement further.

However conservative you might be, if you’re an Oracle user, this patch is definitely recommended in a hurry. The general unwillingness of Oracle to deviate from its once-every-three-months patch cycle spells one word, “Importance.”

As Oracle itself points out, in bold characters:

Due to the threat posed by a successful attack, Oracle strongly recommends that customers apply Security Alert fixes as soon as possible.

Sysadmins, there you have it. A little something for the weekend!

Sep 06 2011

Firefox 6.0.2 fixes yet more DigiNotar certificate fallout

Firefox 6.0.2 has just come out, adding more protection to that provided by Firefox 6.0.1, which was necessitated by the mess caused by disgraced Dutch web security company DigiNotar.

(DigiNotar is the former Certificate Authority – or so-called “authority” – which managed to issue more than 500 bogus digital certificates in the name of major web properties such as Facebook, Twitter, Microsoft and Google; in the name of intelligence agencies such as the Mossad and the CIA; and even, it seems, in the name of other certifying authorities.)

Firefox 6.0.1 fixed Mozilla Foundation Security Advisory 2011-34, which simply pulled everything to do with DigiNotar from its list of trusted certificates. Loosely speaking, any certificate signed by DigitNotar, or any certificate signed by someone with a certificate signed by DigiNotar, and so ad infinitum, was blown out of the water.

Any website with a certificate bought through DigiNotar therefore become untrusted at once. As Mozilla quite bluntly explained in the 6.0.1 update, “sites using certificates issued by DigiNotar will need to seek another certificate vendor.” And that’s how it should be. A Certificate Authority isn’t supposed to make mistakes of this sort – not at all, let alone to this extent.

However, Firefox 6.0.1 exempted from its blockade any DigitNotar-tainted certificates signed at the root level by the Dutch government itself, using its STAAT DER NEDERLANDEN ROOT CA signing certificate. The Dutch public service was apparently convinced that none of the certificates for which it was the root signatory had been affected by signing irregularities at DigiNotar.

It turned out that the Dutch authorities had not one, but two, Certificate Authorities of its own, and its second root certificate – imaginatively named STAAT DER NEDELANDEN ROOT CA - G2 was not exempted in Firefox 6.0.1.

This was reported as a bug, and Mozilla set about adding an additional exemption for DigiNotar-tainted certificates signed by this CA. This would have reduced the impact of the Firefox certificate blockade on the web services provided by the Dutch authorities.

In the interim, however, the Dutch government changed its mind on this exemption, so the Firefox bugfix changed from “exempt DigiNotar certificates signed by the government CA we left out last time” to “remove the DigiNotar exemption for the government CA we exempted last time.”

This sort of step – vigorously disowning everything tainted by DigiNotar – is aggressive but, in my opinion, necessary. Getting into a certification relationship with company X is like buying shares in company X. If the price goes down, all shareholders lose out simultaneously. If the company goes down, you go down with it.

Let’s see whether this fiasco causes the Dutch authorities to reconsider modern public service buzzwords such as “cloud” and “outsourcing”!

NB. This article was updated following an email from Naked Security reader Boris, who pointed out I hadn’t read the Mozilla bugfix thread all the way through! The 6.0.2 patch doesn’t back off slightly from its previous position of certificate blockage, as I said at first. It actually increases its extent, following the Dutch government’s decision to abandon any certificates with DigiNotar in the signing chain. (Thanks, Boris.) And Dutch reader Beamzer suggested rewording the article to make it clear that the Dutch government’s root certifcates themselves aren’t revoked, just that having the Dutch government as a root signatory no longer exempts your DigiNotar-tainted certificates from being blocked. (Thanks, Beamzer.)