It's awesome that Mozilla detailed exactly what the exploit did, even which file paths it searched for.
The exploit basically uploaded the contents of a bunch of sensitive files to some server. Besides uploading the full list of files in the User directory (not the contents of the files) it uploaded the contents of the following files: Linux: /etc/passwd, /etc/hosts, /etc/hostname, /etc/issue, .bash_history, .mysql_history, .pgsql_history, .ssh/known_hosts, .ssh/authorized_keys , .ssh/id_ sa , .remmina/ .remmina, .remm…
Firefox exploit found in the wild
191–200 of 277 posts
Re: Firefox exploit found in the wild
#192Earlier quoted context omitted.
> If you don't want a browser that has some notion of "local file context" you should just sell your laptop and go live in a cave. Thank you for your constructive advice. And I note that so far my stuff written in 'memory unsafe languages' has been in production since '99 or so without a compromise to date over 100's of billions of requests. Maybe it's not just the language. And what business does a browser have with…
> And what business does a browser have with a .pdf file anyway, where does that end? excel sheets? word documents? proprietary format 'x'? Web browsers should stick to web browsing or at least have a mode where they will stick to just web browsing. Displaying arbitrary media content is web browsing; the web is an interconnected network of servers providing hypermedia content that is self-describing as to content typ…
Anyway, I've already been called grumpy and being told to sell my laptop and go live in a cave so I'll give HN a miss for the next couple of days or so.
Re: Firefox exploit found in the wild
#193It's awesome that Mozilla detailed exactly what the exploit did, even which file paths it searched for.
The exploit basically uploaded the contents of a bunch of sensitive files to some server. Besides uploading the full list of files in the User directory (not the contents of the files) it uploaded the contents of the following files: Linux: /etc/passwd, /etc/hosts, /etc/hostname, /etc/issue, .bash_history, .mysql_history, .pgsql_history, .ssh/known_hosts, .ssh/authorized_keys , .ssh/id_ sa , .remmina/ .remmina, .remm…
With that, I can search the history of what we've been sent to get a list of all webpages that this exploit has been seen on.
Email is scriptobservatory -at- gmail -dot- com or you can input it in the "Do you have a list of websites you want to be scanned regularly?" text box.
Re: Firefox exploit found in the wild
#194Earlier quoted context omitted.
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...
The isolation provided by Docker is not as robust as the segregation established by hypervisors for virtual machines.
As seen with CVE-2015-3629[0] for instance.
The other points: patch level and docker management isn't understood, seem to be people problems which can easily be corrected.
[0]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3629
Re: Firefox exploit found in the wild
#195Earlier 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…
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
#196I 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.
and for those who think lynx is a more secure alternative, read this thread: http://marc.info/?l=openbsd-tech&m=140516601718662&w=2
Re: Firefox exploit found in the wild
#197Browsers 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…
Try telling that to people who want them to do more. No one wants to download and install your desktop app - it's too much work and people are too concerned about security. Mobile app stores are much better at minimizing that friction which is why native applications are so popular on that platform... but there's still friction.
The web is awesome because it's so easily accessible. And people want to do sophisticated things easily - they don't want to mess with downloading and installing stuff.
The fact that the web started off a certain way and browsers are called "browsers" has literally zero impact on what people demand from their technology. What they want now is for their browsers to solve problems. So that's what people make.
Re: Firefox exploit found in the wild
#198Earlier 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!"). 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 wit…
Maybe, for now. But WebRTC/WebSockets have a value proposal for real-time interaction in collaborative office suites. Canvas/WebGL have one for performance in authoring tools and for articles illustrations. Documents are readable in your default serif/sans-serif set, but WebFonts are a good designer/author tool just like fonts are in print. Etc... Renouncing this added value because each new feature increases the attack surface sounds like throwing the baby with the bathwater.
> 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.
Two thoughts:
1. Such a "Safe mode" disabling features presents high risks of breaking tons of sites, leaving non-expert users in the dark, and these users are the most likely to be clueless about what's wrong and may just switch to another browser. In the case of JavaScript, Firefox is actually going the opposite way of what you want, by making it harder to disable it [1]. The closest to your wish with Firefox is probably to use their LTS version, ESR, where the dust settled for a little while more (but which ironically, was affected by today's exploit ^^).
2. Can what you are proposing be a "mode"? Take the "Reader View" mode of recent Firefox builds, proposing a Readability-like mode streamlining long reads: this one is clearly a _mode_, you click on it, the text turns big, page gets sepia, side content disappears, you know you're in it and you're not going to constantly browse with it. But would you alternate between "default" mode and "Safe" mode? What a terrible choice to make, you would certainly stay on "Safe" mode, and at this point it becomes transparent that the browser constantly altering content, deepening cluelessness for non-expert users in case of breakage.
2.1. EDIT this reminds me a lot of Polaris tracking protection [2], a project/feature of recent Firefox builds to block http requests of trackers, for privacy. I use the feature, and even I, a moderately "expert" user, was left puzzled when it blocked all the images an article (can't recover it, it was a Russian article/domain of a photographer exploring the remnants of a space shuttle launch military site). Anyway, Polaris had the images domain in its blacklist and blocked them. Glancing at the console, I saw Polaris blocking and disabled the time of a page refresh. But how to handle this simply for non-expert users? This is tough to implement, and directly opposes the "don't break userland" equivalent of the web.
[1] http://limi.net/checkboxes-that-kill/ , https://bugzilla.mozilla.org/show_bug.cgi?id=873709 , https://news.ycombinator.com/item?id=5968237
Re: Firefox exploit found in the wild
#199Browsers 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…
Re: Firefox exploit found in the wild
#200Earlier quoted context omitted.
> The exploit was simply injected on every news article page through an iframe Was the "src" of the iframe 3rd-party to the web site? I want to know whether merely blocking 3rd-party iframes would also have prevented the exploit from working even if javascript is not blocked.
Yes it was so it would have prevented the exploit from loading.
A vulnerability test would be really nice but I understand why it doesn't exist yet.