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!
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.)
Like last time, when Version 5 came out on the mid-year solstice, the official release appeared spot on target: 17 August on the Eastern side of the world, and 16 August in Mozilla’s timezone.
Code-wise, a fair bit seems to have changed – on OS X, for example, Firefox’s own self-orchestrated update is 9.8MByte, compared to a 28MBbyte download for the complete installer. Nevertheless, according to the What’s New section in the release notes, there don’t seem to be any major new features.
There is one change I really like, even though it’s minor and you might not notice it until it’s pointed out. (On second thoughts, perhaps I meant precisely because, rather than even though. Subtle changes are often the best and most useful.)
The domain name of the current URI is highlighted in the address bar (or, more accurately, the non-domain-name part of the URI is slightly dimmed) so that it stands out.
Domain names are intelligently identified. Some countries use a TLD (top-level domain) registration system, where domain names end with a country code (e.g. sophos.de in Germany). Others use a 2LD (second-level domain) system, where domain names include a domain-specific identifier to the left of the country code (e.g. sophos.com.au). And a few use a mixture of TLDs and 2LDs (e.g. sophos.jp and sophos.co.jp).
In some TLD jurisdictions, especially for little-known country codes, scammers have registered 2LD-like domain names to give them an aura of respectability.
The best-known example is probably co.cc, which is a true domain name under Australia’s ill-regulated Cocos (Keeling) Islands country code [*], unlike the well-regulated .com.au 2LD system used in mainland Australia. (Why the Australian federal regulators are so strict on .com.au yet so soft on .cc is an issue for another time.)
So this new Firefox featurette will help to remind you of domain name and hostname trickery. In particular, it will remind you that example.co.cc is not a domain name, but just a sub-domain of co.cc, and that visa.com.dodgy.example does not belong to visa.com.
As usual, there are several security-related bug fixes which are reason enough on their own to upgrade to Firefox 6.
Note that Mozilla has made a colour-coding mistake on its Known Vulnerabilities page, tagging this update with link text set against a white background, implying it is a low-impact update.
Click through to Mozilla Foundation Security Advisory 2011-29, however, and you will quickly see that it lists seven security issues, of which five are of critical impact (red text background), and two high (orange).
One of the critical issues itself relates to a whole raft of memory corruption bugs about which Mozilla says, “We presume that with enough effort at least some of these could be exploited to run arbitrary code.”
[*] Country codes don’t actually denote countries. They are issued both to sovereign independent states and to their overseas dependent territories. Australia therefore ends up with five ‘country’ codes: AU, CC, CX, HM and NF.