It's awesome that Mozilla detailed exactly what the exploit did, even which file paths it searched for.
Firefox exploit found in the wild
131–140 of 277 posts
Re: Firefox exploit found in the wild
#132And this is why we need working sandboxing on the desktop.
Re: Firefox exploit found in the wild
#133Re: Firefox exploit found in the wild
#134Earlier quoted context omitted.
How would you handle uploads or downloads then?
Explicitly configure appropriate permissions for ~/Download/Firefox?
I organise my files, I don't put everything into the same directory. I save them all over my file system. Same for uploads, I do not put them into one directory prior to uploading.
Re: Firefox exploit found in the wild
#135I'll just chuck this old blog post of mine out there: https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sop... Specifically, the "Securing the Web browser" section. [edit] Also worth mentioning is the stuff about smartcards on that blog post. You can steal my ~/.ssh/ and my ~/.gnupg/, but because I'm using a smartcard, it wont do you any good.
That's a great post. Very thorough. However, a couple of observations concerning some security issues you might not be aware of: First, X itself is very insecure, so by allowing your web browser to share the same X server as the rest of your apps, you are making the rest of your apps more vulnerable. Second, the so-called "Trusted" Platform Module you're using for extra entropy may itself not be very trustable, despi…
Re X being insecure. Yep. People have brought this up in the comments of the blog post. It doesn't reduce security by shifting it to a different user, and no, it's not as good as running under a VM. However it does give it some extra protection. For example it would have protected your main users ~/.ssh/ and ~/.gnupg/ directories etc that this latest pdf.js vulnerability could have exposed.
Re the TPM, even in the worse case scenario where the TPM is totally evil, it can't reduce the randomness on my system. It will either keep it the same or improve it. At least on Linux, where it is just one extra source of entropy on top of the other existing ones.
Re the smart card, that may be the case, but it's probably the safest one out there, recommended and pushed by the guy who wrote GnuPG.
It's worth noting that the blog post is 4 years old now.
Re: Firefox exploit found in the wild
#136Earlier quoted context omitted.
> (a) If large amounts of code written in memory unsafe languages is such a concern then Mozilla should immediately stop adding large numbers of highly complex new features implemented in unsafe code to Firefox every year, > (b) ... mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. (a) Mozilla is working on adding/replacing parts of Fire…
>Mozilla is working on adding/replacing parts of Firefox with a language emphasizing security (among other things). The safety of the implementation language is far from the only concern when considering the security impact of modern browser features. The recent WebRTC issues are well documented, as was the HSTS 'supercookies' issue. Even something seemingly fairly innocuous like css keyframe animation can be used to…
> The safety of the implementation language is far from the only concern when considering the security impact of modern browser features. [...] Those kinds of things are not solvable with a safer language (in some cases that probably makes fixing timing attacks more difficult/impossible). I'm sure there are more of these kinds of things to be found. Some of them are realistically never going to be fixed now because they are baked into the standards and the browser vendors clearly care more about animating gizmos and not breaking existing sites than leaking users browser state.
Good points, didn't know about the SVG exploit having taken so long. Rust (which, as you say, is no silver bullet) is one data point showing Mozilla's commitment to security, but the variance in the time to fixing exploits is worth consideration. Today's exploit was fixed in one day, SVG took 18 months. Why? Did Moz do a good job at prioritizing based on the severity / availability of exploits in the wild, or was the long time to SVG fix just caused by technical difficulties? I don't know, maybe a mozillian involved can comment.
Re: Firefox exploit found in the wild
#137Earlier quoted context omitted.
In this case, it was disguised as an advertisement but it was not running on an advertisement server. My adblocker did not catch it. It was injected into the page as an iframe twice. Once disguised as an ad ([IP-address]/ad.php), another time with just the IP-address of the server. I guess it was included a second time in case and adblocker catched the first one. Because it doesn't make sense to include the same expl…
How did you detected it ?
The script triggered a file dialog showing it was trying to access a local file. I opened the Developer Tools and saw all kinds of other files being accessed, including my private and public keys. I nearly got a heart attack. I quickly revoked all SSH keys and started monitoring the requests to narrow it down before I submitted the bug ticket with all the information I had, including the exploit script that was executed.
Re: Firefox exploit found in the wild
#138Earlier quoted context omitted.
You're getting old and grumpy, Jacques, before you know it you will start your sentences with "back in the day..." :) On a more serious note, I guess this is the toll we have to pay for innovation pushing. I can understand the reasoning behind writing everything in JS: it allows you to consolidate a lot of mechanisms in a single platform. Once you have that platform secure, any application you will write will (should…
I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight b…
I disagree that you are the arbiter of defining what innovation is, and the rest of your comment is similarly far outside of the bounds of the applicability of your opinion.
Re: Firefox exploit found in the wild
#139Earlier quoted context omitted.
> It still is looking better than the plugin it replaced. Not for long if this keeps up…
For comparison, NIST NVD lists 445 CVEs for Acrobat, or at least 17 per year since introduction. However CVEs haven't been maintained since the early 90s, so that number should be much higher. I think pdf.js does just fine.
pdf.js does a lot less, of course. Really you should compare Firefox to Acrobat, as they are both rich media rendering apps with a lot of functionality.
Re: Firefox exploit found in the wild
#140Earlier quoted context omitted.
Explicitly configure appropriate permissions for ~/Download/Firefox?
I organise my files, I don't put everything into the same directory. I save them all over my file system. Same for uploads, I do not put them into one directory prior to uploading.
If you have a directory that you want to expose, you can set that up. It doesn't have to be just ~/Downloads/Firefox. If you want to expose something like ~/Documents but deny access to ~/Documents/Private you can do that. With a little effort, you can probably even configure a helper utility that toggles access on and off dynamically with a status charm in the notifications area.