Sounds extremely targeted, if an attacker is porting the attack to Macs (presumably a lot of work), and combining it with other loaders... I wonder how long this 0-day was in the wild.
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..
if an attacker is porting the attack to Macs (presumably a lot of work)
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.
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.
Makes sense. If entire OSes can be written in an intermediate representation, then exploits can be as well.
Just speculation, but "targeting" in this case may be as trivial as checking the user agent header, or other "device recognition" tricks common in web development nowadays. I am sure there are hundreds of libraries that do this for you...
I don't know why you are addressing me, I can't even downvote. Your "conspiracy theory" comment is certainly valid, unfortunately I'm not willing to provide more information so I suppose it will remain a "conspiracy theory" albeit one I believe is true.
Assuming this[1] test for sparse indexes with extra properties in the unfixed version of the file as part of the bugged code, the annotations suggest that the bug MIGHT have been (partially?) introduced by this[2] changeset. If so, that means all versions of Firefox >= 38.0a1 (21 Apr 2015) might be vulnerable to the bug.
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.
"This simplifies the code a bit because ElementAccessHasExtraIndexedProperty
checks for length-overflow and sparse-indexes so the callers don't have to
do that anymore."
simple code best code, the less opportunity you give people to shoot themselves in the foot the better
"A type confusion vulnerability can occur when manipulating JavaScript objects due to issues in Array.pop. This can allow for an exploitable crash. We are aware of targeted attacks in the wild abusing this flaw."
I'm at a loss imagining how this might work, can anyone expound on this? How might this actually occur?
One of the most obvious attacks is if two different typed objects have similar memory layouts you can use it to read/write fields.
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.
> 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...
I've looked at moving to the snap before but last I heard there's no way to import your current profile? And netflix doesn't work? If those two things are fixed I'd happily change over!
Netflix for me works fine. You just need to tick the 'Play DRM content' setting.
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.
For the former, I would imagine `rsync -Pav $whatever_old_ff_profile/ $HOME/snap/firefox/whatever/` would do that, since AFAIK snaps store user-specific persistent state outside of privileged directories
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
They're usually pretty quick, as in nearly as quick as rolling releases (and sometimes faster). Sure, they're not as fast as Mozilla, but usually it's out within a day or so if release, often quicker.
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.
Are there not comparable or identical shortcuts for keyboard users on most nix boxes and Macs? I admit to not being up to speed on Command/Option/Splat Mac shortcuts, but I wouldn't have expected the chrome to diverge that much between systems from a common code base.
I'm grateful to QubesOS for being able to easily browse in a disposable VM whilst waiting for the build. Even without QubesOS starting a disposable VM manually is probably worth the effort..
It's easy to get mad at Fedora when we don't have the latest-greatest at the time the announcement drops. But they hold the packages so that they can do additional QA beyond what Mozilla has already done and protect their users.
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.
I don't like dealing in absolutes. There are valid reasons to hold a security patch for some period of time if the cure is worse than the poison. See, for example, some of the early Spectre/Meltdown mitigations that caused a 20% performance hit.
Looks like nightly builds aren't being published. Even if you browse the directories manually, they're not there[1]. On google play[2] it's showing as updated, though.
it looks like it specifically targets cryptocurrency owners.
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.
Firefox is supposed to have sandboxing, right? Does this sandboxing help against such attacks? As in: is there a second attack on the sandbox needed to get RCE?
From the article: "Following a request for additional details from ZDNet, Groß said "the bug can be exploited for RCE [remote code execution] but would then need a separate sandbox escape" in order to run code on an underlying operating system."
Some one mentioned this is being used against crypto owners; get in and perhaps read session cookies for a web wallet? Or combine with another zero-day. Any one with this has serious resources and probably a good team.
It is important to also understand what causes the issue, how it was exploited, etc. Plus I am pretty sure that they had the bug report before the fix was released.
Mozilla can still give access for the developers of forks without opening it to the public before they (and the forks!) have managed to rollout a full update.
Anyone can run a fork though, I right now might be running my personal fork. This is part of the point of free software.
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 don't understand this logic. It's better to have everyone see it and to guarantee it is seen by a malicious actor, instead of only a small few seeing it and there being some small potential for it to be seen by a malicious actor?
It will be seen by a malicious actor anyway after the fix is released. The difference is that there will be more time for a malicious actor to act against a fork if an embargo is applied.
Mozilla used to open up the security bugs after the fix is out for a while.
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).
The same people who were in charge of opening up security bugs are still around and still in charge of it.
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.
Unless things have changed dramatically since I left Mozilla, forks that are willing to be active in the Mozilla security community are able to get access to security bugs.
The only additional information on that mozilla link is that the issue is "fixed in Firefox 67.0.3 and Firefox ESR 60.7.1". The only information about affected versions is that
an unspecified set of "Firefox, Firefox ESR" are vulnerable.
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.
What right would the Firefox team have to invade the privacy of the "target" to detail who they are to the Internet as a whole?
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?
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.
The iOS version should be unaffected, as Firefox for iOS does not include its own JS engine (it uses the one provided by the system), which is where this vulnerability is.
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.
Please do not assume people are not running current release just because they are lazy and have not upgraded.
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.
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.
I get the annoyance with deprecating extensions. But seriously the <edit>main</edit> person you are harming by running vulnerable un-patched software is yourself.
If only this was true. People with unpatched software running are prime targets for inclusion in a botnet and then they are damaging other with their reckless behavior.
This is exactly the problem with the culture that's formed around software and the security industry in general --- people are using the excuse of "security" to force other utterly unwanted and hostile changes, and then act surprised and angry when people don't update.
Doubly so when the advice given is basically "bend over and take it" --- especially when Mozilla has made statements like this in the past:
"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.
Mozilla has been very destructive, and I have had to restrain Firefox in a number of different ways. It's Updater.app will disregard your wishes and repeatedly download updates over and over again. This happened to me when I had to turn in an assignment and I was on a 2G connection a few years ago. Most of their updates are unidirectional, even though they don't need to be. And major features are quietly removed, as if it is just normal for your car's speedometer to disappear one morning. This ends up feeling like gas-lighting. At least Chrome's updates are small and hard to notice, but Firefox has all the same disregard for users, except they are very clumsy about it. And the official response from them has been that if their updates destroy your profile folder, that you should have made a backup and it was your fault for assuming that their software wouldn't do a destructive update.
The tone-deafness of the comments here is astounding. The fact that these posts are rapidly downvoted further reinforces my point.
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'm sorry you are getting downvoted. You are absolutely correct. I've gotten in many discussions about this exact same thing on HN. I at one point I had an exchange with someone about terrible bad Pale Moon was because it let users do things like override HSTS settings, and otherwise undo decisions that Mozilla had made.[1]
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...
