Firefox exploit found in the wild
161–170 of 277 posts
Re: Firefox exploit found in the wild
#162If you need it too, here's the list
Re: Firefox exploit found in the wild
#163If at all possible it would be worth naming and shaming the advertising network that is allowing this exploit through. Why do advertising networks allow advertisers to exectue Javascript? What need is there for it? Every time one of these exploits that use advertising networks is found, it just increases the value of blockers such as uBlock. Whether you accept adverts or not, you shouldn't have to accept javascript b…
Re: Firefox exploit found in the wild
#164Earlier quoted context omitted.
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.
It is closed source. https://en.wikipedia.org/wiki/Ghostery
See:
Ghostery was acquired in January 2010 and is no longer open source. This is an old version of the extension. See http://www.ghostery.com/ for a current version.
https://github.com/jonpierce/ghostery
They even have a link up to their 'sources' in the FAQ but that leads nowhere.
Re: Firefox exploit found in the wild
#165Earlier quoted context omitted.
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
#166Earlier 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'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…
Re: Firefox exploit found in the wild
#167Browsers are supposed to browse that's all. More and more stuff like this will come up with HTML5/JavaScript and people will begin to wonder why the world is jumping through all the JavaScript hoops to build a web app that is essentially a rich client app when they could use tools that are designed for that. Are they more or less secure, neither, once you can touch the user's filesystem the risk is the same which is…
To me browsing would include all the JS stuff we have now plus all kinds of things we haven't dreamed up yet. Call me old fashioned but I'm all for continuing to move the web forward.
There will be vulnerabilities in native apps, there will be vulnerabilities in web apps or, put more simply, there will be vulnerabilities.
Patch 'em up and charge ahead.
Re: Firefox exploit found in the wild
#168I am not security pro, but I wonder if server-side installations of PDF.js are exploitable? WordPress plugins using PDF.js, can these become a new vector to attack webservers? Case, site uses PDF.js plugin to render pDFs for users. Is it possible to access server filesystem through PDF.js?
Re: Firefox exploit found in the wild
#169How many PDF.js security vulnerabilities have been found so far? A quick Google search found only four: https://www.mozilla.org/en-US/security/advisories/mfsa2013-9... (another local file disclosure) https://www.mozilla.org/en-US/security/advisories/mfsa2015-3... (needs to be "combined with a separate vulnerability" to be exploitable) https://www.mozilla.org/en-US/security/advisories/mfsa2015-6... (needs to be "combi…
>It still is looking better than the plugin it replaced. Exploiting a bug in a memory unsafe language is much harder than writing some JavaScript. It is also much less reliable and platform specific. The real question is why the hell is Firefox not sandboxed?
Re: Firefox exploit found in the wild
#170Earlier quoted context omitted.
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 s…