Hacker News new | past | comments | ask | show | jobs | submit login

They're installing a service that runs with elevated privileges to bypass UAC.

I don't think it's a good thing to install that kind of loophole on your PC.




That's actually the right way to do it. How do you think Chromes does? Right, they're installing in the user area, not in the application area, to bypass UAC. That's wrong.

Using a service that uses authenticated connections and signed installs is similar to what Windows Update does, for the right reasons.

Best would be that Windows Update would be open to let any app hook into it for updates of course, but til then, that's as close as it gets.


> That's actually the right way to do it.

No, it's not. If Firefox is installed by a non-admin user, it should go into the user's directory. If it is installed by an admin, then it should ask if this is an OS-wide installation and only then drop it into %ProgramFiles%. Chrome got it absolutely right.


Incorrect. Firefox is always installed by admin user at the first install (UAC prompt there is inevitable).

If you run an unzipped firefox from your desktop, it will not install the updater, because it CANNOT. There must be at least ONE UAC prompt ONCE. And that's where it's installed as admin, that's what UAC is there for.

You don't seem to understand how permissions work.


You don't seem to understand what I said.

Firefox (or any other program for that matter) should be able to install itself when run by an under-privileged user. SHOULD. If it CANT, then its installer is designed incorrectly and its installation mechanics are wrong.

Consider a simple case when I am on a shared computer as a restricted user. In an Internet cafe or similar. I should be able to install, run and use Firefox. There's basically no technical reason why it will not be able to run under a restricted set of privileges. It has no drivers to install, it doesn't bind to privileges range of ports, it doesn't need to install a service. It should quietly go into C:\Users\dude\Program Files and make itself comfortable there.

Microsoft has a set of guidelines, in part covering where what should go. Some of these guidelines are simply retarded, they have always been. Their existence is not an excuse for not questioning them. If a developer insists on following them, it just doesn't speak much of a developer.


Well, there's Portable Firefox for that use case...

There are some benefits to installing critical apps like web browsers outside of the user's home directory. If a virus compromises the user account, it still can't touch the web browser's executable.


I've been able to install both Firefox Aurora and Nightly on my windows restricted account. Haven't tried the regular Firefox, but I'm assuming it's the same, because I installed Aurora and Nightly around version 9.


Did Aurora and Nightly install themselves into your %USERPROFILE% directory instead of %PROGRAMFILES%?


I don't understand how Windows does permissions so I might be wrong, but how is this behavior different from a trojan?


A service to handle updates is good. A service per application to handle updates is not very good.

Why is chrome bad? It at least can't lead to a system compromise.


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.


  > A service per application to handle updates is not very good.
Why not? The only problem I see is that it bloats out the list of services, and that list has been dying for some kind of hierarchical reorganisation for some time.

It's not like the service is continually running.


I'm more worried about the attack surface that each service adds.

Especially when you have people used to writing user applications making secure services (this part isn't very relevant to browsers).


Alas, that's more of a messy patch over Windows' lack thereof, IMNSHO (Windows Update indeed exists, and updates the Windows OS, but that's about all you can do with it).


It will allow vendor patching but it costs money and is damn complicated so noone bothers.


How is it responsible for them to bypass UAC at all? When did it become OK to circumvent the security features of the user's OS in order to install software without his knowledge?


Chrome and Flash are installing services, but they also create tasks in Task Scheduler. Will Firefox do this as well? Can one delete the services and have only the tasks running?


It's even worse to have people with ancient versions because firefox was installed by admin, but they (as they should) run as a regular user.


As long as it's done right and only installs updates signed by Mozilla, then it is secure.


I'll bet you a beer or whatever you like to drink we're going to see a flurry of exploits around this service.

I happen to have written a similar service a couple of years ago for a very different purpose and let me tell you one thing: this is nothing less than a backdoor.

You run a program from the service and make sure it runs in the user's session. The problem is, how do you decide a program is "legit"?

You're going to tell me "you check against a digital signature". Except it doesn't work. You can only check parts of the binary, not the whole binary (as some content is unpredictable once it runs).

The other big problem - assuming they have a perfect gateway - is that a vulnerability in Firefox could become catastrophic as it could go through the service to run as a privileged user and wreak havoc.


1: Firefox always used UAC for updates. Did it wreak havoc? Because believe it or not, UAC = admin rights. That's because Firefox always installed itself in program files.

2: You could exploit Google's update service as well. Do I see flurry exploits around it? Much much smaller code base. Much less complex tasks.

3: A digital signature signs the whole binary. Not parts of the binary. Do you know how this works? There's no such thing such as signing a partial binary.


> You're going to tell me "you check against a digital signature". Except it doesn't work. You can only check parts of the binary, not the whole binary (as some content is unpredictable once it runs).

I read this a few times, and I still don't get why you wouldn't check the whole binary. Care to elaborate?


  > You can only check parts of the binary, not the whole binary
Not only would they be signing the binary in its entirety, they're almost certainly signing every single byte of the update package, right down to the very last manifest file and license agreement.

  > some content is unpredictable once it runs
Yes, but "some" content isn't allowed to run.


Has anyone got a link to a clear explanation of this new Mozilla Maintenance Service, please? I'm trying to find reliable information, but it's hard to see the wood for the trees in most of the documentation/commentary I'm finding.

I did notice that something popped up on one of my computers, having triggered an alarm in one of my security tools. I automatically told it to block the installation, the same as I do for anything else that presumes to invite itself onto my system without first explaining what it does and asking my permission.

It does seem to have sneaked in on my work PC, but seems to have configured the service to run with manual startup only. So what exactly triggers this service, and what kind of security implications are there? In short, do I really want this (given that I really don't care about absurdly frequent updates unless there's a security alert that requires an immediate fix) or should I nuke it?


Isn't this basically the equivalent of suexec?


It's how Chrome does it too, I believe.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: