Mozilla patches Firefox zero-day abused in the wild
zdnet.com
zdnet.com
You can't be sure the same bug was exploited.
Your friend should probably be browsing as a non-admin in a continuously-reimaged VM, separate from an air-gapped machine, if you have those kinds of attackers after you. Spooky..
How come?
It's worth noting that a professional security and pentest company I know of had a Python-based exploit authoring DSL that automatically generated exploit code across a very wide range of processor architectures and OSes. This was about fifteen years ago.
Makes sense. If entire OSes can be written in an intermediate representation, then exploits can be as well.
If the bug is really that old, it's certainly possible it might have been abused in the wild, perhaps in more ways than the just the "targeted attacks" mentioned the report.
[1] https://hg.mozilla.org/releases/mozilla-release/rev/99a829d2...
[2] https://hg.mozilla.org/releases/mozilla-release/rev/6bfcb81d...
simple code best code, the less opportunity you give people to shoot themselves in the foot the better
I'm at a loss imagining how this might work, can anyone expound on this? How might this actually occur?
We merged that thread (https://news.ycombinator.com/item?id=20220804) into this one.
Say you had class A and class B and they are confused with each other.
Suppose they have the following layout:
struct A {
int x
void *f()
}
struct B {
int x
int y
int z
}
Then if you have a class A and you make the program think it's actually class B. You can imagine that if you control an object B you can update the fields x, y of a object B. Once this is prepared you can then use the object as type A and then run some code to trigger the call to A.f()Obviously this is a trivial example but with depending on the vulnerability you can perhaps use it call protected functions and all kinds of memory corruption.
Attacks on JavaScript arrays tend to edit the 'size' field and change it to a really really large number, thus by simply indexing the array you can have unrestricted read/write access to a large section of memory.
but won't the memory protection (write xor execute) stop the function pointer from jumping to the array body (since that's write memory)? Meh, i guess in actual practise, it's much more complicated than that...
[0]: https://download.mozilla.org/?product=firefox-latest-ssl&os=...
https://incoming.debian.org/debian-buildd/pool/main/f/firefo...
...
channels:
stable: 67.0.3-1 2019-06-18 (230) 221MB -
It is already available to use.The alternative, and likely why no one has applied a great deal of pressure to that workflow, is to use the Firefox Sync account they've been pushing so hard
My personal reason to use the snap is because it limits access to the home directory. So I can disconnect my home directory, camera and microphone and have a second layer of confidence that my browser won't leak any personal data.
That and it avoids Firefox leaking config files in my home directory.
If I want to upload a file, I simply move the file into a Downloads folder in it's SNAP home directory. This way, Im in control of what the browser can access.
You would need to copy once (or `rsync`) from `~/.mozilla/firefox/` to `~/snap/firefox/current/.mozilla/firefox/`.
Hamburger menu -> Help -> About Firefox
Your version number is listed under the big heading, and if there’s an update available there should be a button next to that.
My question, I'm on beta channel and updated to 68.0b11 today and don't see detailed release notes.
67.0.3 (normal channel) lists "Security fix" https://www.mozilla.org/en-US/firefox/67.0.3/releasenotes/
But beta channel only says 68.0beta released May 22nd, no info on newer beta versions. This is the link in the about box: https://www.mozilla.org/en-US/firefox/68.0beta/releasenotes/
I totally get not wanting to write fine grained release notes on every single beta version, but 0-day fixed feel the kind of thing that ought to be explicitly pointed out. I'm assuming that the same fix from release channel was also pushed in the 68.0b11 update but a release note about that would be swell.
I'm sometimes disappointed, but after seeing some of the bugs they've caught during the Fedora-specific testing/QA builds, I can understand why they do it.
https://www.mozilla.org/en-US/firefox/android/nightly/all/
Does it contain the fix?
[1] https://download-installer.cdn.mozilla.net/pub/mobile/nightl... although the ESR builds are coming in fine, so maybe something broke the build script?
[2] https://play.google.com/store/apps/details?id=org.mozilla.fe...
> Is Mozilla Firefox ESR available for Android and iOS?
> No. Firefox ESR will only be offered for Windows, macOS and Linux for desktop computers.
Play Store is confusing, because the actual version is "depends on your device".
If one has critical personal data on a computer and use it to casually browse the web, one should probably rethink that approach and use different physical devices for different purposes.
I find it really gross that they do not allow others to access it. This behavior damages the forks.
Plus, you assume that the select few developers that are given the exploit information are trustworthy. The exploit being public from the first day is better than if even a single developer is untrustworthy or compromised.
I say used to because I notice that the security issues fixed in Firefox 66.0 (released in March according to the release notes) still appear to be private. I suspect the internal people that cared about it have left, and their process is now broken. Somebody might read this thread and poke people to open access, but it would have to be done as an exceptional step (given that it hasn't been the first time I've noticed this happening).
Security bugs are opened up once in-the-wild usage of affected versions is low enough, if I recall correctly. This usually takes a while after the fix is shipped. At no point were bugs opened up immediately after the Firefox release with the fix shipped. It's usually a year or so between the fix being shipped and the bug getting opened up, in my experience.
The security issues in 60.0.2 (June 6 2018) is now public.
Security bug reports are often restricted for some time after a new release to help prevent reverse engineering to find the bug.
The user experience was degraded at FF57 for many individuals who need extensions that will not work with ff>56 or that developers have abandoned out of frustration with Mozilla. When all the extensions I find necessary are functional (or with suitable replacements) I will switch.
If you still want to use your extensions AND receive browser updates, you should move to a different browser (maybe waterfox?)
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
Also I'm curious, what extensions are missing? Most of my pre-quantum extensions, such as Tree Style Tabs, have been updated now.
There are a couple I sorely miss. Disable Ctrl-Q died, and so did Toggle Animated GIFs. Now I have to keep an extra tab open with a warn-on-page-close handler to prevent Ctrl-Q fat-fingering from killing my session. And I've just disabled video/GIF animations entirely, instead of using the cool extension which let me start/stop them on demand.
I also used to have a cool cookie exporter extension, which was useful in combination with wget for scraping sites that required a login. I admit I haven't searched for a replacement, though, so maybe there is one.
EDIT: s/the only person/the main person/
Doubly so when the advice given is basically "bend over and take it" --- especially when Mozilla has made statements like this in the past:
https://blog.mozilla.org/security/2013/01/29/putting-users-i...
"Users should have the choice of what software and plugins run on their machine."
In any case, I hope NoScript is one of the extensions you're already using, because this is another vulnerability that requires JS to exploit. JS off by default already gets rid of the vast majority of them.
It's not just Mozilla, it's the whole "update culture": "you must take these important fixes for remotely-exploitable vulnerabilities, and also all of that other stuff" --- of which everyone would probably want the former, but no one really wants the latter.
When the "choice" of browsers that can view the majority of sites, including advanced JavaScript, is basically between Firefox or the various flavours of Chrom(e/ium), there is no real choice!
tl;dr: To say I am annoying with the state of things is an enormous understatement. The browser culture is getting more and more user-hostile and "security" is being used as an excuse to put users under the noose, this encouragement of "learned helplessness" is insane. Fuck this idiotic "it's for your security" bullshit.
I actually have highly specialized profiles that make heavy use of XUL addons that I have developed over the years for very specific things, and I hate how careful I have to be that an update won't come and delete them. It would be one line of code to make a backup of a profile before "upgrading" it...
[1]: https://news.ycombinator.com/item?id=19527615
Anyway, it's a much bigger problem, and it's cultural as much as technological. And you're not alone and you're not crazy for seeing it.
Latest Android Nightly build is 68.0a1 from 2019-05-04.
Latest Android Beta build is 68.0beta, from May 21, 2019 (actually from APK name it's 68.0b11).
Latest iOS Release build is 16.0, from April 15, 2019.
By the way, latest Desktop Beta build is 68.0beta, from May 22, 2019, and latest Desktop Nightly build is 69.0a1, from May 20, 2019 - and there's no information about whether they affected too.
For the Desktop version at least, if you download the current beta (68.0beta11), you'll notice that it was built two days ago. The latest nightly was built today. The changelog for these is just not kept up to date.
The report doesn't include anything about which version introduced the bug. Is this a recent bug, or has it been around for many years? If it's old, is there any information available that might indicate how long malicious actors have been exploiting this vulnerability? Apparently the answer to the last question is "yes", as Mozilla claims that "We are aware of targeted attacks in the wild abusing this flaw." For how long? How many people might be affected?; "targeted" could mean a single individual or a very large group with some specifically targetable attribute.
There is a lot more to security than "just upgrade to the latest release". Also, while fears about public malicious actors learning from disclosure rarely outweigh the important benefits gained by allowing the public to defend themselves and learn form the incident, in this particular case where malicious actors are already exploiting the bug in the wild, there is little to be gained by keeping information hidden from the public.
HN users frequently complain that "automatically check for updates" is somehow an invasion of privacy. Meeting your demand, revealing the target of an attack publicly, would certainly be an invasion of privacy — one a thousand times more trust-violating than any auto-update check could be.
What of your needs is met by making such a request? What is your direct and personal benefit from knowing the target of the attack? Why are you willing to sacrifice the privacy of that target for that personal benefit?