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”!

Follow @duckblog
-
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.)

Firefox 6 is out. This is the second release under Firefox’s new ‘single-line railway track with regular stations’ development and release regimen.

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.”

Follow @duckblog
-
[*] 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.

Mozilla delivered on its promise to have the Version 5 release of its browser ready by midwinter’s day, which takes place today in Australia – 22 June 2011.

The new version officially calls itself 5.0, but the Version 4 release is just three months old, and has had only one point update (to Version 4.0.1).

It looks as though Mozilla is simply copying Google’s Chrome version numbering system in order to seem more “with it.”

Chrome now increments the leftmost number in its version string with every release, which gives the impression that it is making faster progress than products which change their major version number less frequently. That’s good marketing, of course, but poor science by the observer. (Your car doesn’t really increase in speed by 60% when you switch the speedo from MPH to KPH.)

With Chrome already up to Version 12 (and 13 in beta), Mozilla clearly feels that lagging back at V4 for more than a few months would look tardy. V3 is now the previous version – the official page of “all older versions” lists V3.6.18, and that’s that.

As I’ve mentioned before, it’s no longer a simple matter, after updating Firefox to the latest version, to find out what’s changed. Even the trusty Releases page now only gets you as far as V4.0.

And before you update, there’s no easy way to find out what you’re letting yourself in for, either – except for the breathless claims that V5 has a new look, super speed, and even more awesomeness.

In case you’ve just updated and you’re wondering what’s changed, V5′s killer feature appears to be support for the Do Not Track feature on multiple platforms; it also “includes more than 1,000 improvements and performance enhancements that make it easier to discover and use all of the innovative features in Firefox”.

So if you’re looking for a conservative, low-risk, security-related update, this is not it. Since there is no V4.0.2, either, your only choice for a conservative change is to revert to V3.6.18.

If you’re committed to the new-style Firefox, and you want the latest security patches to V4.0.1, your only choice is to go to V5, which fixes five remote code execution vulnerabilities and three less serious faults.

The V5 critical fixes are:

* MFSA 2011-26 Multiple WebGL crashes
* MFSA 2011-22 Integer overflow and arbitrary code execution in Array.reduceRight()
* MFSA 2011-21 Memory corruption due to multipart/x-mixed-replace images
* MFSA 2011-20 Use-after-free vulnerability when viewing XUL document with script disabled
* MFSA 2011-19 Miscellaneous memory safety hazards (rv:3.0/1.9.2.18)

There is no security fix for V3.6, which stays at 3.6.18. I can’t help smiling at that, and wondering how many of the security fixes above were necessitated by code added since 4.0.1 to bring us those more-than-1000 enhancements and all that additional awesomeness.

My wish from Mozilla? For Firefox 6 (or 5.0.1, if there is one), please add one tiny extra step to the Check for updates button.

Let me preview a brief but informative list of security fixes I’m going to get (plus their significance), and a short list of anything which will look sufficiently different after Firefox restarts that I might scratch my head and think, “I wonder if that was supposed to happen?”

Follow @duckblog

-
P.S.Yes, I’ve updated. I wanted the security fixes and I’ve found the FF4 code base usefully quicker. Nothing unexpected has happened to my settings, and it’s so far, so good. I’ve got 3.6.18 installed in parallel, just in case. But I had that before, anyway.