Another good idea is to never visit news sites based in Russia. Not only you won't get infected with random malware, you also won't have to read blatant propaganda that passes as "news" over here.
Firefox exploit found in the wild
81–90 of 277 posts
Re: Firefox exploit found in the wild
#82Earlier quoted context omitted.
The networks themselves rely almost exclusively on javascript nowadays so the websites have little choice, the ad networks then in turn pass some or all of this trust to whoever makes the creatives, which up until recently were quite frequently done in flash and are now sometimes in javascript. Personally I think all ads should be served up in a totally passive visual format (png, jpeg, gif) and have no other attribu…
I agree. It's actually the animation of the adverts that I find most distracting. Text, and/or a static image - not an animated gif would be fine. I would enable ad networks that could guarantee that is all they will serve up.
The distraction is the point. It's no use enabling only the ads that you're easily capable of ignoring.
Re: Firefox exploit found in the wild
#83Earlier quoted context omitted.
> And what a pdf reader has to do with javascript is a mystery as well. The whole reader is written in Javascript: https://mozilla.github.io/pdf.js/
Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if jav…
Hindsight and all that but still, this is not a good idea.
Do you mean the browser, or just this particular feature?
Recommended reading: http://lcamtuf.coredump.cx/postxss/ and http://lcamtuf.coredump.cx/tangled/.
If you do choose to read them, I recommend doing it earlier in the day--fitful sleep has been observed after evening reading of the above.
Re: Firefox exploit found in the wild
#84I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given? All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript…
You can disable the PDF reader quite easily: https://support.mozilla.org/en-US/kb/disable-built-pdf-viewe...
Would this stop the exploit from working? Or is the file still kept around and a malicious website could request it’s use for a different purpose?
Re: Firefox exploit found in the wild
#85Earlier quoted context omitted.
Docker would seem to me to be the wrong solution in this case.
Instead of $ firefox you start $ docker run mozilla/firefox and get instant process isolation and protection from these kinds of exploits. Heck, mozilla could use the same underlying mechanisms internally (cgroups, namespaces) that docker already uses without introducing the dependency on docker (if that's whats bothering you). So while the implementation may not be ideal (installing docker is an overhead, I acknowle…
The new Firejail app [1] may be worth exploring as it is designed to run locally installed apps like browsers and games in sandboxes, as opposed to more chroot oriented container managers like LXC, Docker or Nspawn. They all use namespaces.
If you want to use a chroot oriented container manager its better to use an unprivileged container so you are not running as root. Currently only LXC has support for unprivileged containers. We have an experimental GUI app container with Chrome that can be used in unprivileged mode. [2]
You can even run your own sandbox with a simple command like this 'unshare -fp --mount-proc' That gives you a bash shell in its own pid space. You can expand this command further to use more namespaces like mount, net, user to get yourself a sandbox.
That is what apps like firejail and container managers are using, but its useful to know what's happening underneath. We are currently working on a guide on how to use unshare that may help. [3]
[1] https://l3net.wordpress.com/projects/firejail/
Re: Firefox exploit found in the wild
#86Earlier quoted context omitted.
Hi, I reported this 0-day. It used a PDF.JS same origin policy violation to access local files. You should be safe because you have javascript disabled and pdfjs.disabled set to true. There's no way for the script to run. It was on a international news website operating from Russia. The exploit was not on an ad network. The exploit was simply injected on every news article page through an iframe. Therefore I assume t…
Please identify the exact international news website. Was it rt.com?
No it was not. I'm not sure if I should mention which website it was (yet). The exploit is still active. I am trying to get in touch with them to get it removed.
Re: Firefox exploit found in the wild
#87Earlier quoted context omitted.
Oh great. What could possibly go wrong, give javascript access to local storage through some 'hard to trigger' gate. That's just asking for it. Hindsight and all that but still, this is not a good idea. A browser should not use it's own internal language sandboxed for the web to have access to the local system through some loophole. It's only a matter of time before such a loophole becomes an exploit. I wonder if jav…
You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits were being found at a rate measured in tens per year. Since introduction PDF.js has only had 2 holes that were directly exploitable, neither leading to remote code execution which was the default behaviour for pretty much any bug found in Acrobat. If you don't…
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, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons.
Just like switching to PDF.js was a decision taken to try and reduce the security attack surface, the decisions to add webgl, webrtc, webfonts, webm, websockets, new css features and so on were all decisions taken in the full knowledge that adding those things would vastly increase the attack surface and inevitably lead to security exploits. These new web features are responsible for a slew of new vulnerabilities and new classes of information leaks.
Re: Firefox exploit found in the wild
#88I'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.
Thanks for posting! I bookmarked the page and will use it when setting up my next laptop.
Re: Firefox exploit found in the wild
#89Earlier quoted context omitted.
You haven't the slightest understanding of software security, PDF.js was written to replace a component authored in a memory-unsafe language for which exploits were being found at a rate measured in tens per year. Since introduction PDF.js has only had 2 holes that were directly exploitable, neither leading to remote code execution which was the default behaviour for pretty much any bug found in Acrobat. If you don't…
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, mostly to do things that have absolutely nothing to do with displaying web pages but are enabled by default for political reasons. Just like switching to PDF.js was a decision taken to try and reduce the…
[deleted]
Re: Firefox exploit found in the wild
#90Since the vulnerability is in pdf.js, is the Tor Browser Bundle vulnerable?
the latest versions come with noscript, so not unless you explicitly enable javascript on that site