The article claims this exploit leaves no trace, but what about Linux atimes (assuming you don't have noatime set)? Eg. if you found multiple shell scripts with similar access times when you know you haven't worked on them at the same time. If this is a workable method of detection then it would be a good idea to avoid accessing any potentially affected files until you have recorded full access times.
Firefox exploit found in the wild
181–190 of 277 posts
Re: Firefox exploit found in the wild
#182These browser vulnerabilities have got me thinking that I should start browsing in a VM. Has anyone moved to this level of isolation? Steve Gibson on the last Security Now podcast said he's been experimenting with Sandboxie...
Sandboxie looks like a paid closed source solution, I'm not sure they give me a compelling value proposition over something like a light linux distro under VirtualBox.
Re: Firefox exploit found in the wild
#183I 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.
Modest too, "The script triggered a file dialog showing it was trying to access a local file. I opened the Developer Tools and saw all kinds of other files being accessed, including my private and public keys. I nearly got a heart attack. I quickly revoked all SSH keys and started monitoring the requests to narrow it down before I submitted the bug ticket with all the information I had, including the exploit script that was executed."
Wow, lucky that it triggered a prompt. Thanks for the response!
Re: Firefox exploit found in the wild
#184I 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.
sudo unshare -m bash -c "mount --make-rslave /home ; mount -n --make-rprivate -o bind /tmp/empty /home ; sudo -u $(whoami) firefox -ProfileManager -no-remote"
- creates an empty directory,
- fork the mount table for the new bash process and its children (requires privileges),
- unshare /home (required if / is mounted in shared mode [1]),
- hide /home by mount-binding the empty directory,
- start firefox in unprivilegied mode, without being able to access to user's files.
[1] https://www.kernel.org/doc/Documentation/filesystems/shareds...
Re: Firefox exploit found in the wild
#185Earlier quoted context omitted.
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…
> 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 type so that clients (like browsers) can appropriately choose how to handle content based on its type.
Its true that early web browsers only handled HTML, plain text, and a few image formats internally, and relied on external software to handle all other media -- but all of that, including the parts for which they relied on external software -- is part of "web browsing".
Re: Firefox exploit found in the wild
#186Browsers 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…
Once upon a time, the Internet was supposed to just be a network of interconnected hypertext documents. But as soon as we decided that the Web should be a platform[1], and Netscape Navigator packaged JS, we started down a road where it's quite hard to return.
I know it's an unpopular opinion, but I actually miss the days where webpages were static and did not need JS to load basic functionality.
With the rise of the IoT, security is only going to be more and more difficult (e.g., all the automanufacturers' issues as of late); here's hoping we can figure out a way to make security mainstream…
Re: Firefox exploit found in the wild
#187I 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.
Or just run it in a docker container with your X11 session mounted. That works great for me.
Re: Firefox exploit found in the wild
#188Earlier quoted context omitted.
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…
Out of curiosity, which browsers/versions have you had trouble running in a VM?
It's not so much having trouble as just inconsistency of implementation across platforms. For example, I usually do this kind of work on Windows. I certainly could spin up a quick Ubuntu VM and run Firefox in that, but various aspects of the page rendering might change as a result. Given that far more Firefox-using visitors on most real sites will be running Windows than any other platform, testing with real Firefox on Windows is less error-prone. Ditto for Chrome, etc.
Re: Firefox exploit found in the wild
#189Browsers 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…
What is browsing, then? Read-only? Are forums browsing, or interactive apps? Where do you draw the line?
I'm all for less bloat, and I can't figure why would a browser double as a PDF reader, for instance, when a native app is invariably faster, more feature-rich, more customisable and more secure. However, it's difficult to draw a concrete line between plain browsing and web apps.
Re: Firefox exploit found in the wild
#190Earlier quoted context omitted.
Explicitly configure appropriate permissions for ~/Download/Firefox?
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.
I think a better method is what Apple has done in OS X. When the app needs to read from or write to a user specified file, the app calls a specific API that presents a file picker dialog. The file picker dialog is running in a separate process from the sandboxed app, and the app will temporarily be granted permissions to access this particular chosen file through this API.