Live data from Hacker News

Firefox exploit found in the wild

blog.mozilla.org

21–30 of 277 posts

Re: Firefox exploit found in the wild

#21
post #3

I 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…

Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.

Re: Firefox exploit found in the wild

#22
post #3

I 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…

Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.

Yeah sure, just mount your X socket into a container. No problems there at all, nah.

Re: Firefox exploit found in the wild

#23
post #3

I 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…

Docker containers can sandbox GUI apps[0], but I don't know if it's secure enough. Maybe not.

[0]: https://news.ycombinator.com/item?id=8426764

Re: Firefox exploit found in the wild

#24
I'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.

Re: Firefox exploit found in the wild

#25

I'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.

Good stuff, suggest you add an entry about running the browser inside a VM of its own.

Re: Firefox exploit found in the wild

#26
post #23
post #3

I 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…

Docker containers can sandbox GUI apps[0], but I don't know if it's secure enough. Maybe not. [0]: https://news.ycombinator.com/item?id=8426764

I'm not sure if docker is the right solution here, a VM would seem to be much better at this kind of isolation.

https://zeltser.com/security-risks-and-benefits-of-docker-ap...

Re: Firefox exploit found in the wild

#27
post #3

I 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…

Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.

Docker would seem to me to be the wrong solution in this case.

Re: Firefox exploit found in the wild

#28
post #8

Some 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.

Rather than ghostery:

https://www.eff.org/privacybadger

Re: Firefox exploit found in the wild

#29
post #3

I 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…

Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.

Docker is not secure enough (it can help but it's not designed to be bulletproof). MAC (GRsecurity...) can be considered the "right" solution.

Or just give up and go QuubeOS ;)

Re: Firefox exploit found in the wild

#30
post #17

Earlier quoted context omitted.

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?

Well, if I recall correctly, pdf.js is an add-on, so it has special permissions, just like any add-on.
Post reply on HN