I wonder if Firefox is going to disable itself.
Firefox exploit found in the wild
151–160 of 277 posts
Re: Firefox exploit found in the wild
#152Earlier quoted context omitted.
It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). Also, the links/lynx jokes have really gotten tired, plenty of people browse the web with ublock, no(t)script, webgl and webrtc disabled and so on. The pretense that anybody who tries to retain a modicum…
> It doesn't help your position the fact that you are unable to express it without belittling anybody who disagrees with you using stuff like "stay stuck in 1992" ("If you don't like America you should go to Russia!"). True, that was useless, could have just said "I and many users do want these features" . Thanks, and sorry anon. > the links/lynx jokes have really gotten tired, plenty of people browse the web with ub…
Ok, I guess that I misread the tone of your post (i.e. we largely agree).
I don't however think that the web it that broken without those features (javascript being the harder one to police). Judging from the browsing habits of my family members, they don't spend nearly as much time inside web applications as the HN news cycle would lead me to believe: some news sites, some webmail (and even there, when presented with a decent looking mail application they happily switched), the most basic functions of facebook, and "utilities" i.e. web banking, traveling, university websites.
None of these uses requires the ability to play quake3 inside firefox, or are really applications inside a webpage. Same probably goes for all the browsers in the workplace, for instance.
I'll agree with you that few sites will do progressive-enhancement (and decent accessibiliy), I'm just disappointed in the defeatist attitude of browser vendors and expert users: the idea of having a browser safe mode that you can lock down doesn't strike me as such an impossiblity and it would give some incentive to developers to put their act together.
Re: Firefox exploit found in the wild
#153Could this exploit also be used to write to files? I have a feeling that it probably could, and that makes it even scarier.
Re: Firefox exploit found in the wild
#154I find the first sentence fascinating, "Yesterday morning, August 5, a Firefox user informed us...". I'd love to know more about this person and their skill set. How was the exploit detected and isolated? How did this issue get reported and resolved in s day? Assuming the Mozilla way, I wonder what the bugzilla report will read when it comes out of embargo.
It's HN user fukusa, who also comments in this thread
Re: Firefox exploit found in the wild
#155Earlier quoted context omitted.
Why, docker-initiated chroot would prevent FF from acessing any not-FF+libs files, including which this malware steals; on Qubes it would have access to everything user-readable in the AppVM, which may include some secrets as Qubes workflow involves user-supervised copying files across VMs. Obviously docker, as opposed to Qubes, won't stop more complex malware that exploits the kernel.
From all I have heard, docker is not even secure enough to let user A do things in dockerthingyA and user B in dockerthingyB. From what I was told, user A could easily break out into dockerthingyB and maybe even the host. Are you sure it really is not possible short of exploiting the kernel (or docker I guess)?
I don't know the details, but this is rather due to fact how docker operates -- there is a daemon that runs with root privs (which are esential to create a container) controlled by a client with a protocol that has no concept of fine-graind access lists. Consequently, user A can do anything with user B's containers because docker doesn't even have such thing as container ownership. Also docker protocol involves something which is basically opening shell as root, thus users with docker access have also a passwordless sudo. All those choices are basically ok for docker because it is designed for single-user systems like developer laptops or application servers.
Currently, for multi-user systems the only safe option for containers is sadly virtualisation or emulation; nice implementation of rootless chroot is proot, http://proot.me/
Re: Firefox exploit found in the wild
#156I find the first sentence fascinating, "Yesterday morning, August 5, a Firefox user informed us...". I'd love to know more about this person and their skill set. How was the exploit detected and isolated? How did this issue get reported and resolved in s day? Assuming the Mozilla way, I wonder what the bugzilla report will read when it comes out of embargo.
It's me. I discovered the exploit in the wild when I became a victim of it. Skill-set limited. I was able to identify it and understand what it basically does, but not much more.
Re: Firefox exploit found in the wild
#157Earlier 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…
That's not true. There have been PDF.js exploits that lead straight to RCE. This has the additional downside of leading to immediate compromise on every platform.
Example (used by Mariusz Mlynski to win Pwn2Own this year): https://www.mozilla.org/en-US/security/advisories/mfsa2015-3...
Re: Firefox exploit found in the wild
#158Browsers 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 why it still baffles me that developers actually want to code in JavaScript and dozens of one off libs when they could use first class tools which are far better designed. Browsers are supposed to browse, that is all they are supposed to do.
Re: Firefox exploit found in the wild
#159I 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…
Maybe run it inside a chroot jail? Hmm... that sounds like a good idea just on principle... there goes my morning. Of course, X11 is still a problem.
[deleted]
Re: Firefox exploit found in the wild
#160Earlier quoted context omitted.
exploit requires pdf.js, so yes, disabling pdf.js would stop the exploit from working.
But choosing a different default PDF viewer does not necessarily “disable” pdf.js, or does it? Does the exploit just show a malicious PDF file and then relies on Firefox using pdf.js to display that file, or does it somehow “request” pdf.js be used?
you need to go into about:config in order to disable it.