Firefox 42 ... answer to the ultimate question of life, security bugs and fully private browsing? Mozilla has released Firefox 42 and Firefox ESR 38 38.4, which include fixes for worrying security vulnerabilities in the web browser. The November 3 update squashes at least three bugs that can be potentially exploited to achieve remote code execution. Two Mozilla engineers, Tyson Smith and David Keeler, uncovered two flaws …
I've also had repeated random crashes - 3-4 a week. There's nothing iffy or exotic in my add-ons:
ABP
Flashblock
Classic Theme Restorer.
Anyway it shouldn't be possible for an add-on to completely take out the entire application with a fatal crash. Even if an add-on is causing problems the main Firefox application should be able to contain that within the add-on.
As I've pointed out before, and no doubt many others have as well, most or all of the commercial and open source TLS implementations have been shown to have serious, exploitable bugs over the past couple of years. I don't know of one that hasn't. (Well, maybe Certicom's, but they're not really maintaining it any more, so it can hardly be recommended.) Even the relatively obscure ones like CyaSSL.
They're all broken.
This latest round of issues in NSS is just par for the course. It's not at all surprising that there's an exploitable bug in the ASN.1 decoder, for example, because ASN.1 is a nightmare specification and BER and DER are horrendously over-complicated. (ASN.1 is a fine example of Brooks' "second system effect".) And ASN.1 is just one little part of an SSL/TLS implementation. They are very, very difficult to get right.
It would probably help somewhat to use a language that imposed many more checks - range and bounds checking in particular - and garbage collection, because then developers wouldn't have to be so vigilant (and developers are terrible at vigilance). But performance would suffer and SSL/TLS performance is very important to a lot of users, particularly people who run busy websites.
Of course security is always a matter of economics, and TLS does improve the defender's position for some prominent branches of the attack tree, which is why we continue to recommend it for many use cases. But you have to assume any implementation contains exploitable bugs.
But how can I tell if I've been the victim of one of these security exploits?
No completely accurate decision procedure exists. I'm pretty sure I (or you, or anyone else) could prove this is isomorphic to the Halting Problem with just a little effort.
These are general exploitable vulnerabilities that allow remote code execution. That means an attacker may have been able to run arbitrary code with the privileges your Firefox processes run under. You'd need an incorruptible audit trail of everything done by your Firefox processes and some way to evaluate it.
But take heart. Similar bugs probably exist in most of the software you use, and always have, so the situation has not changed.
Have they solved the 10% cpu issue in Linux? (Firefox suddenly using 10% of the CPU for no discernible reason) and making the whole of X.org lag even more than it normally does.
I have to close/open FF on a regular basis because of that, and it has been going on for almost a year. (It is not extensions, it is a javascript problem of some sort caused by random interweb pages)
Probably not, they are too busy introducing another round of web 3.0 shit no one cares about.
I don't know, I had to install NoScript because of that.
And this week, I've fully transitioned to PaleMoon for surfing the shark-infested interwebs. It comes in a nice .tar.gz DIY install package now. Runs my handrolled canvas-based game gfx editor much faster than recent Firefoxes too. Thank you Moonchild & friends!
"Have they solved the 10% cpu issue in Linux?"
Opensuse tumbleweed here with Firefox 42.0 after a couple of days of constant browsing and stuff I have not seen any spikes at all, also at the moment ( only two tabs open though) it is only using: 1% cpu ( 4core I3 lappy ).
Seems smoother as well
HTH
"Have they solved the 10% cpu issue in Linux?"
Haven't tried 42 yet but it's 100% CPU here with some javascript.
It's also extremely irritating to have to install an add-on just to do something as basic as turning off javascript. Why they removed that ability from FF itself is beyond me. Every new version seems to remove something useful that I rely on.
Very little it seems:
The programming cockups were reported by security researcher Ronald Crane. "These do not all have clear mechanisms to be exploited through web content but are vulnerable if a mechanism can be found to trigger them,"
No software bugs are good but neither are they all "cockups" – something like heartbeat would count as one of those. If you don't understand the possible attack vectors as a result of the bugs then just admit it and don't dress them up as "scary". A lot of bugs do require pretty esoteric exploits which, however, can be quickly "weaponised" once the attack vector is understood and a proof of concept has been developed. This is the nature of security.
And how about providing links to the various CVE reports?
I'm not a fan of the shit they keep on adding to the browser and the UI fuckery but there is no doubt in my mind that Mozilla is much more responsive to bugs since it switched to time-based releases.
And how about providing links to the various CVE reports?
The official ones aren't up yet. The MITRE CVE database still shows the three CVEs as "reserved", which means Mozilla requested IDs but hasn't filled in the details yet.
There's the security advisory on mozilla.org, but it doesn't have much information - nothing that's not in the article, really.
The Mozilla Bugzilla database probably has more information, but you need an account with suitable permissions to view those bugs.
Stopped using FF for all but one or two fussy sites after the Pocket nonsense got in.
Qupzilla -- yeah I know, what a name! -- works great. It also has some serendipitous extras for me. For example, if I have many tabs from the same site, and I want to enable JS on one of them, in FF+NoScript, this touches ALL the tabs and they all start reloading. In Qupzilla it's only that tab.
Now if it could only do that for cookies also, that would be grrrreat!
.deb packages The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
