Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why not?

Since Chrome is in the user area, guess what, anything compromising Chrome can overwrite Chrome itself. It can then prompt you with UAC or simply have a user space trojan. (heh, and it can't compromise Firefox if it's also installed)

An updater has a several magnitudes less code to audit (thousand, millions magnitudes?).

In Firefox's case, if Firefox is compromised, it cannot modify itself (heh, it can compromise Chrome if it's also installed)



If Firefox is in UAC'd location, then a Firefox compromise would simply drop an .exe or .dll into user's directory and set it up to be launched by Firefox. As an add-on, for example, or through the same exploit it used to enter the system.

In other words, the installation location doesn't really matter. If the process is breached, the user context is f#cked regardless.


Presumably the privileged service has been coded to only execute binaries that have been cryptographically signed by Mozilla.


I've checked it and yes, it connects to SSL'd mozilla update servers (like firefox did on it's own in the past) The certificates appears to be pinned (so it doesn't trust "any" valid cert, only these very certs) Then the downloaded update appears to be a mar signed file (then again firefox did that on it's own in the past too)

If a Firefox exploit drops an exe, it will never run with admin rights. It'd have to be coming from Mozilla and signed by Mozilla. Plus, it'd have to come from their servers, because you can't just drop the exe and have it installed, the updater only trust what it downloads on it's own.


In this case, its only the updater that runs privileged (which last time I checked was a separate application). The only way you should be able to 'compromise' it would be too man in the middle, and pretend to be Mozilla servers. Even then, if it used SSL (I'm not sure it does), and had an embedded certificate, then it should be fine.


Yes, the Firefox updater uses SSL and other mechanisms to prevent man-in-the-middle attacks. The update payload itself is signed with a private key controlled directly by Mozilla, to avoid vulnerability to CA compromises [1]. The connection to the update server uses SSL and performs additional checks to ensure not only that the SSL certificate is valid, but that it matches one of a small list of known certs or issuers, so a bad CA can't issue a forged certificate [2][3].

[1]: https://wiki.mozilla.org/Security/Reviews/Firefox10/SilentUp....

[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=544442#c24

[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=583678


The scenario you just detailed is rather contrived and is possible in any software deployment scenario.

Why the downvotes? As the other comment points out this is a really stupid security bit to nitpick as all of the alternatives are equally vulnerable in an equally contrivable scenario manner. One way or another privileges have to be granted. They can be granted in one place or another and have largely similar if not identical implications at the very least in terms of the net effect that can be had.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: