Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox exploit found in the wild

blog.mozilla.org

Post reply on HN
Print view View original

141–150 of 277 posts

Re: Firefox exploit found in the wild

#141

Post by [deleted] »

_wmd wrote: post #63
jacquesm wrote: post #19

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

[deleted]

Re: Firefox exploit found in the wild

#142

Post by anonbanker »

baghira wrote: post #70
stingraycharles wrote: post #50

Earlier quoted context omitted.

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…

I disagree that this is innovation. What innovation and what benefits do I reap by using pdf.js? It's slower and has less features than okular. It's stuck inside a firefox window, so I cannot add a window rule for it (barring adding one for firefox in general). The same holds on windows: why would I use pdf.js when there are faster, lighter pdf readers (e.g. sumatra) or the actual adobe acrobat reader and its eight b…

printing from pdf.js in linux is a bit of a headache as well, compared to okular or evince. Usually takes about 10 times as long (no joke) to print a pdf from inside firefox.

Re: Firefox exploit found in the wild

#143

Post by anonbanker »

claudius wrote: post #84
rogeryu wrote: post #38

Earlier quoted context omitted.

You can disable the PDF reader quite easily: https://support.mozilla.org/en-US/kb/disable-built-pdf-viewe...

Would this stop the exploit from working? Or is the file still kept around and a malicious website could request it’s use for a different purpose?

exploit requires pdf.js, so yes, disabling pdf.js would stop the exploit from working.

Re: Firefox exploit found in the wild

#144

Post by anc84 »

fluidcruft wrote: post #140
anc84 wrote: post #134

Earlier quoted context omitted.

I organise my files, I don't put everything into the same directory. I save them all over my file system. Same for uploads, I do not put them into one directory prior to uploading.

If you have a directory that you want to expose, you can set that up. It doesn't have to be just ~/Downloads/Firefox. If you want to expose something like ~/Documents but deny access to ~/Documents/Private you can do that. With a little effort, you can probably even configure a helper utility that toggles access on and off dynamically with a status charm in the notifications area.

That sounds incredibly cumbersome, akin to things like umatrix or noscript (which I use but 99% of users would never touch or be able to correctly control).

Re: Firefox exploit found in the wild

#145

Post by ommunist »

I 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

#146

Post by mrob »

Silhouette wrote: post #6

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…

4. How are "text files" in "text files with “pass” and “access” in the names" identified? "file" command? Extension?

5. Can we get a full list of all the "usual global configuration files" to aid in looking for a pattern in atimes?

Re: Firefox exploit found in the wild

#147

Post by fukusa »

callum85 wrote: post #131

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, .remmina/.pref, .config/filezilla/.xml, .filezilla/.xml, pass.txt, access.txt, .sh, .config/psi+/profiles/default/accounts.xml

Windows (in the User directories AppData/Roaming and Application Data): Subversion: config, servers, auth/svn.simple/* , auth/svn.simple/* .* SmartFTP: Client 2.0/Favorites/Quick Connect/* .xml Psi+: profiles/default/accounts.xml Notepad++: plugins/config/NppFTP/NppFTP.xml .purple: accounts.xml s3browser: * .xml, * .settings FileZilla: filezilla.xml, sitemanager.xml, recentservers.xml FTP Explorer: profiles.xml FTPRush: RushSite.xml FTPGetter: servers.xml FTP Now: sites.xml FTPInfo: ServerList.cfg, ServerList.xml GHISLER: wcx_ftp.ini Ipswitch: WS_FTP/Sites/ws_ftp.ini VanDyke: Config/Sessions/* .ini

Re: Firefox exploit found in the wild

#148

Post by lloydde »

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

Re: Firefox exploit found in the wild

#149

Post by fluidcruft »

anc84 wrote: post #144
fluidcruft wrote: post #140

Earlier quoted context omitted.

If you have a directory that you want to expose, you can set that up. It doesn't have to be just ~/Downloads/Firefox. If you want to expose something like ~/Documents but deny access to ~/Documents/Private you can do that. With a little effort, you can probably even configure a helper utility that toggles access on and off dynamically with a status charm in the notifications area.

That sounds incredibly cumbersome, akin to things like umatrix or noscript (which I use but 99% of users would never touch or be able to correctly control).

It's only as cumbersome as you choose to make it.

Re: Firefox exploit found in the wild

#150

Post by claudius »

anonbanker wrote: post #143
claudius wrote: post #84

Earlier quoted context omitted.

Would this stop the exploit from working? Or is the file still kept around and a malicious website could request it’s use for a different purpose?

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?
Post reply on HN