Here’s some news about Firefox 28.0, which was just released on 18 March 2014.
I’ll keep this super-short, because the update pretty much writes its own story.
As you probably know, the Firefox browser (at least, Firefox on Windows) was hacked four times at the recent PWN2OWN competition, netting four security researchers $50,000 each.
That was at the end of last week, on Thursday 13 March 2014.
The PWN2OWN hacks were remote code execution exploits – the sort that are most important to fix.
→ PWN2OWN rules require full but responsible disclosure. To get your prize, you have to tell the vendor, and only the vendor (OK, and HP, the competition organisers) exactly how you did it. That means the vendor doen’t have to rush, as the exploits aren’t published for the world at large to use.
How many of those four holes were fixed in Firefox 28.0?
Mozilla Foundation Security Advisory 2014-29:
Security researcher Mariusz Mlynski, via TippingPoint’s Pwn2Own contest, reported that it is possible for untrusted web content to load a chrome-privileged page by getting JavaScript-implemented WebIDL to call window.open(). A second bug allowed the bypassing of the popup-blocker without user interaction. Combined these two bugs allow an attacker to load a JavaScript URL that is executed with the full privileges of the browser, which allows arbitrary code execution.
Mozilla Foundation Security Advisory 2014-30:
Security research firm VUPEN, via TippingPoint’s Pwn2Own contest, reported that memory pressure during Garbage Collection could lead to memory corruption of TypeObjects in the JS engine, resulting in an exploitable use-after-free condition.
Mozilla Foundation Security Advisory 2014-31:
Security researcher Jüri Aedla, via TippingPoint’s Pwn2Own contest, reported that TypedArrayObject does not handle the case where ArrayBuffer objects are neutered, setting their length to zero while still in use. This leads to out-of-bounds reads and writes into the JavaScript heap, allowing for arbitrary code execution.
Mozilla Foundation Security Advisory 2014-32:
Security researcher George Hotz, via TippingPoint’s Pwn2Own contest, discovered an issue where values are copied from an array into a second, neutered array. This allows for an out-of-bounds write into memory, causing an exploitable crash leading to arbitrary code execution.
That’ll be all four fixed, then.
There’s one more Advisory listed as critical, covering a range of possibly-exploitable bugs found by the Mozilla developers themselves, denoted by the usual words “Miscellaneous memory safety hazards.”
Note that the Firefox Extended Support Release (ESR) goes to 24.4.0.
Firefox ESR is commonly used in organisations that are happy to take security fixes frequently, but prefer more time to think about feature changes.
Nice work all round by the Mozilla team.
Image of hands (seen supporting the Firefox logo) courtesy of Shutterstock.
I upgraded from a fully working install of Firefox 27 to 28 on a Win 7 64 bit machine. End result was constant crashes and also IE 11 could no longer connect as well. I ended up uninstalling FF 28, which restored IE 11 functionality, and loading Pale Moon 64 bit , variation of FF compiled with speed and functionality in mind rather than compatibility. Not quite sure what is going on here. Could be something on my end.
You are not alone. Though here it did not affect any other browser.
Resetting the browser helped… so far.
Just for the record, I updated right away on OS X; no problems that I can tell. (And Safari is unaffected.)
Have you tried upgrading from Windows to a Mac and then installing Firefox? (Only kidding 🙂
Mine took the update with no issues anywhere that I can see
@ Paul
Draining your readership’s bank account and making them live a life in hell (using a Mac) is no laughing matter!
Updated to v28 just now and it’s doing a VERY weird post-update thing: it’s stuck in a loop. Why? Because my firewall, rightly, prevents a changed or new .exe from just connecting to the internet.
Now, Mozilla, in their infinite wisdom, see fit to make the usual Firefox executable, in the usual path, launch (supposedly POST-update, i.e. the update is DONE, not HALF-done)
immediately call a non-existent dopplenganger firefox.exe from the [usual install path]\updated\firefox.exe path.
My security software warns me, and I cannot authorise it, as I cannot audit the executable in even the simplest sense of the term – the file isn’t present!
This is basically, probable malware behaviour. If it isn’t, it is really stupid of Mozilla’s installer team to accept this convoluted method of installation/update. Stupid of me not to back up my installation.
This kind of forced-b.s. experience happens regularly.
I am severely unimpressed with Mozilla, having been using Firefox for a very long time.
Technically, you could audit the EXE if you wanted – it’s just a zero byte file (or, more precisely, *the* zero byte file, because with zero bits you can represent only 20 states, i.e. 1).
If ever that file did come into existence in a future launch of Firefox, your security software would warn you again, because it would have changed.
You sound pretty ticked off with Mozilla, saying that “this forced-b.s. experience happens regularly,” yet in the next sentence that you have been “using Firefox for a very long time.”
Why not just switch to IE 11? If you haven’t used IE for a while, you might be pleasantly surprised. (You might not, of course, but it sounds as though it could save you a lot of anxiety 🙂