Why is anyone still using this browser anyway? Firefox is the new IE6.
"...the new IE" has been thrown about so much it is basically an empty statement I'm afraid
https://www.google.com/webhp?q=%22chrome+is+the+new+IE%22
Firefox exploit found in the wild
11–20 of 277 posts
Re: Firefox exploit found in the wild
#12Earlier quoted context omitted.
I'm roughly in the same boat as you but what I don't get is if your work is that sensitive then why don't you run with at least ghostery, umatrix and adblock on your machine? The last thing I need is to have to contact a customer to tell them their data might have escaped my desktop computer because I took my browser to some unsafe site. Also: start your browser in a VM.
I do run with the browser locked up tight. It runs basically no plug-ins by default, and I have multiple privacy and blocker plug-ins active. I also have a complete log of every piece of software and update to it that has been manually/voluntarily installed in the entire lifetime of every affected system. What I don't know right now is whether any of that actually helps me in this case.
I really recommend you use a VM for browsing, or even a physically separate computer from the one that you keep your sensitive stuff on. It's a pain but it's a lot better than any of the alternative scenarios.
Re: Firefox exploit found in the wild
#13Some more details would be helpful here. Specifically: 1. If PDF files aren't set to open using Firefox's built-in PDF viewer, was the relevant system still vulnerable? (That is, if under Options->Applications, PDFs were set to something other than "Preview in Firefox", would this attack still work?) 2. Which were the 8 popular FTP clients potentially affected? 3. Was this specific case all that could be done or was…
I'm roughly in the same boat as you but what I don't get is if your work is that sensitive then why don't you run with at least ghostery, umatrix and adblock on your machine? The last thing I need is to have to contact a customer to tell them their data might have escaped my desktop computer because I took my browser to some unsafe site. Also: start your browser in a VM.
Given that the company that makes the closed source Ghostery add on make their living selling user data I was say that for sensitive work this addon should probably be avoided.
Some combination of script and adblocker would probably be a good idea though.
Re: Firefox exploit found in the wild
#14Why is anyone still using this browser anyway? Firefox is the new IE6.
Because it is the only browser that is not tied hand-and-foot to some major global commercial player, and because each and every browser ever launched had security issues.
Even lynx is not immune:
http://www.cvedetails.com/vulnerability-list/vendor_id-5836/...
Re: Firefox exploit found in the wild
#15I 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…
> 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/
Re: Firefox exploit found in the wild
#16Earlier quoted context omitted.
I'm roughly in the same boat as you but what I don't get is if your work is that sensitive then why don't you run with at least ghostery, umatrix and adblock on your machine? The last thing I need is to have to contact a customer to tell them their data might have escaped my desktop computer because I took my browser to some unsafe site. Also: start your browser in a VM.
Given that the company that makes the closed source Ghostery add on make their living selling user data I was say that for sensitive work this addon should probably be avoided. Some combination of script and adblocker would probably be a good idea though.
If you're referring to 'Ghostrank' that's opt-in and off by default.
If there is something else going on then I'd really like to know about it!
Their sources are open and you can inspect them to make sure they don't do anything nefarious so that would have to be quite an elaborate play on their part with the downloads being different than the published source in critical parts.
Re: Firefox exploit found in the wild
#17I 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…
Actually, I'm pretty sure that's used to let you read webpages stored on file://. That's a feature that has been present in browsers since ~1993. I don't think you can deactivate it.
> And what a pdf reader has to do with javascript is a mystery as well.
It's a pdf reader written in JavaScript, just as there are other pdf readers written in other programming languages.
Re: Firefox exploit found in the wild
#18I 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…
Actually, I'm pretty sure that's used to let you read webpages stored on file://. That's a feature that has been present in browsers since ~1993. I don't think you can deactivate it. > And what a pdf reader has to do with javascript is a mystery as well. It's a pdf reader written in JavaScript, just as there are other pdf readers written in other programming languages.
In that case, is the issue actually specific to pdf.js? If it's written entirely in javascript, could this not be exploited some other way? Or does pdf.js have special permissions in this context?
Re: Firefox exploit found in the wild
#19I 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…
> 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 javascript has access to devices such as cameras and microphones through similar loopholes. That would be a bit of a problem.
Re: Firefox exploit found in the wild
#20Earlier quoted context omitted.
I do run with the browser locked up tight. It runs basically no plug-ins by default, and I have multiple privacy and blocker plug-ins active. I also have a complete log of every piece of software and update to it that has been manually/voluntarily installed in the entire lifetime of every affected system. What I don't know right now is whether any of that actually helps me in this case.
I really recommend you use a VM for browsing, or even a physically separate computer from the one that you keep your sensitive stuff on. It's a pain but it's a lot better than any of the alternative scenarios.
In principle I agree, but unfortunately running in a VM is the one otherwise reasonable precaution that I can't realistically take on the machines in question. I do a lot of web development, so if I'm running everything in a VM all the time then I'm not testing using the same browsers that my clients' customers will be. Maybe it would have given some reassurance in this specific case, but in general if those client sites incorporate any third party resources this sort of attack is still a concern.