854088 - (CVE-2013-1673) old MozillaMaintenance Service registry entry not updated, leads to Trusted Path Privilege Escalation

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Robert Kugler]

Attachment: payload.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

Steps to reproduce:
1. Copy calc.exe to C:\program.exe or C:\Program Files (x86)\mozilla.exe. You can also use my payload (attached).
2. Start MozillaMaintenance using the service manager or the command-line.
3. calc.exe (program.exe - mozilla.exe) will be run with SYSTEM privileges



Actual results:

The malicious executable was executed with SYSTEM privileges!


Expected results:

The service executable shouldn't run program.exe (C:\program.exe) or mozilla.exe (C:\Program Files (x86)\mozilla.exe). Although you need to be running as a high integrity process to create files in the root directory and its subfolders you could use this vulnerability to escalate your privileges or to automatically re-compromise the target in the future (with SYSTEM privileges)!

Comment 1

[Daniel Veditz [:dveditz]]

launching using non-absolute/non-quoted strings again?

Comment 2

[Robert Kugler]

Today I tested this bug with another machine. 
I installed Firefox with the latest installer.
Windows 7 64bit SP1 / Firefox 19.0.2 / Mozilla Maintenance Service 19.0.2 (x86 en-US)

[SC] QueryServiceConfig ERFOLG

SERVICE_NAME: MozillaMaintenance
        TYPE               : 10  WIN32_OWN_PROCESS 
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : "C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe"
        LOAD_ORDER_GROUP   : 
        TAG                : 0
        DISPLAY_NAME       : Mozilla Maintenance Service
        DEPENDENCIES       : 
        SERVICE_START_NAME : LocalSystem

This machine isn't exploitable...
It seems like the latest version isn't vulnerable, but then there's some mysterious behaviour on my first test machine!!

Windows 7 64bit SP1 / Firefox 19.0.2 / Mozilla Maintenance Service 19.0.2 (x86 en-US)

[SC] QueryServiceConfig ERFOLG

SERVICE_NAME: MozillaMaintenance
        TYPE               : 10  WIN32_OWN_PROCESS 
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe
        LOAD_ORDER_GROUP   : 
        TAG                : 0
        DISPLAY_NAME       : Mozilla Maintenance Service
        DEPENDENCIES       : 
        SERVICE_START_NAME : LocalSystem

You see the "" are missing, this machine is exploitable!! Everything is up-to-date and patched the only differency is that I didn't do a fresh install with the latest installer.

Did you fix this vulnerability in the last months?! It's strange that my machine missed this patch isn't it??

Sorry that I opened a bug report for this curiosity!

Comment 3

[Daniel Veditz [:dveditz]]

hm... this sounds like bug 748764, fixed in Firefox 13. Could your first installation have been installed between Firefox 10 and 12?. I guess that's why it sounded like an old problem coming back to haunt us.

Comment 4

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

assigned to freddy for verification

Comment 5

[Robert Kugler]

Comment 3:
This could be! But both installations are patched and up-to-date...
How can a user know if his installation is really secure or vulnerable? 
Only new installations are not exploitabe but "old" ones are! So a long installed and updated Firefox is less secure than a fresh installation?

Comment 6

[Frederik Braun [:freddy]]

Could not reproduce. So the real issue is that we do not update the Mozilla Maintenance Service?

Comment 7

[Robert Kugler]

Comment 6:
Yep, updating the Maintenance Service would solve this problem! 
I don't know but I think the majority of the users is rather using the auto-update than reinstalling Firefox every time. They'll remain vulnerable to a fixed security issue!

Comment 8

[Daniel Veditz [:dveditz]]

Robert (Kugler): do you still have the vulnerable installation? If so you can check it's version using window explorer (right-click, pick Properties). I bet the service itself may be up to date (the updater can replace files) but possibly only the initial installer knows how to update the registry entry that needs the quotes.

Freddy: the way to reproduce (if my theory is correct) is to install a Firefox 12 version (which has bug 748764) and then let it update to the latest. You may need to fully uninstall Firefox first to make sure you get rid of any currently-installed service (and I do mean uninstall so that registry clean-up is done, don't just nuke the files).

Robert (Strong): is this a known problem? If my theory is correct could we patch the maintenance service so that new versions know to check/fix their registry entries?

Comment 9

[Robert Kugler]

Daniel Veditz: I checked its version: 19.0.2.4814. The service is up-to-date! I was able to reproduce this issue on Vista 32bit SP2. Your theory is correct, only the initial installer knows how to update the registry entry that needs the quotes.

Comment 10

[Robert Strong (they/them - no direct email)]

(In reply to Daniel Veditz [:dveditz] from comment #8)
>...
> Robert (Strong): is this a known problem? If my theory is correct could we
> patch the maintenance service so that new versions know to check/fix their
> registry entries?
Not known. The post update helper should fix the registry entries after an update and this appears to not be the case. I'll take a look.

Comment 11

[Frederik Braun [:freddy]]

(In reply to Daniel Veditz [:dveditz] from comment #8)
> Freddy: the way to reproduce (if my theory is correct) is to install a
> Firefox 12 version (which has bug 748764) and then let it update to the
> latest. You may need to fully uninstall Firefox first to make sure you get
> rid of any currently-installed service (and I do mean uninstall so that
> registry clean-up is done, don't just nuke the files).

I uninstalled, installed Firefox 12 and performed an auto-update but couldn't reproduce.
This happened on a test vm, since I'm not really a windows user. Just to make sure, I performed a reboot between every step ;)

Comment 12

[Robert Kugler]

mmh...that's odd! Same installer behaviour on Windows 7 SP1 64bit!
It's reproducible for me on Vista and Windows 7.

My steps to reproduce:
1. Downloading and installing Firefox 12 (http://www.mozilla.org/de/download/?product=firefox-12.0&os=win&lang=de)
2.Starting the browser to let it download the update. 
3.Then exit and restart the browser to let it install the latest version.
4.Now check the version of the service. It should be up-to-date. 
  You'll see the quotes are missing!
5.Copy exploit.exe (payload.zip) to C:\program.exe and start the service: 
  sc start MozillaMaintenance
6.A new user is added to the Administrator group!

Comment 13

[Daniel Veditz [:dveditz]]

Just checked my own development machine and the maintenance service path is unquoted still after 6 releases worth of Nightly, Aurora, ESR, etc. updates. Pretty sure I must have run the installer since Fx13 (for ESR-17 if nothing else) so it looks like the installer doesn't fix up an old maint-svc reg entry either.

This attack requires local access so if the user is privileged then it's not adding any risk. The interesting case is when the user is _not_ privileged, but can still write to c:\ for some reason -- this then allows that user to elevate their privilege on the local machine. As argued in bug 748764 this does happen in some cases, although arguably any admin that allows that has already weakened the system's security.

I'm torn between sec-moderate and sec-high. We rated bug 830134 as sec-high, though an attacker has more opportunity to inject using that bug (directory of their choosing).

Comment 14

[Robert Strong (they/them - no direct email)]

Dan, is your dev system a VM as well? Is your user account a member of the admin group?

Comment 15

[Robert Kugler]

Enabling write access to C:\ is not the best idea to secure your
system, but unfortunately not every user knows what he is doing by
enabling write access! 
As described here: http://www.wipethedrive.com/WTD-detail.pdf an attacker could gain
persistent access on a infected machine. The Maintenance Service 
starts on demand so the attacker needs to wait 6 weeks until there is a new Firefox version to get his reverse shell or reinfection.

Robert Strong:
I could reproduce it without a VM. My user accounts are both members of the admin group.

Comment 16

[Brian R. Bondy [:bbondy]]

I thought we were already handling the case to fixup old installs during that period but it seems like we are not. I think I was thinking of this function:
http://dxr.mozilla.org/mozilla-central/toolkit/components/maintenanceservice/serviceinstall.cpp#l183

To fix we can just tweak doesServiceHaveCorrectPath to be false when there are no quotes found in the string.

I would probably set this is sec-moderate because you need admin access to write to c:\ and so this can't be exploited widely.  Also if you have a program named program.exe on your computer it will surely be run eventually by something on your machine as high integrity and which therefore implies as SYSTEM (since a high integrity account can create a service as system and run it).  I agree someone can set c: as writable but this is probably very rare overall.

Comment 17

[Brian R. Bondy [:bbondy]]

Have to do some other updater work so I might as well take this.

Comment 18

[Robert Kugler]

Brian R.Bondy:
This bug isn't widely exploitable, but there are some
scenarios where this vulnerability could be used by an attacker.
1. When you compromise an Administrative user with a client-side attack you'll have write 
access to C:\. Create a mozilla.exe in Program Files and start the service.
   Privilege escalation and a "stealth" persistence (every 6 weeks backdoor) are possible.
2. The user isn't a member of the Adminstrator group but has granted write
   access to C:\. 
   Privilege escalation and persistence are possible.

Comment 19

[Brian R. Bondy [:bbondy]]

For #1 do you mean physically on the machine? 
If you are physically on the machine logged in as administrator yes you can copy a file to C: by hitting the UAC confirmation dialog.  But you can also right click on anything you want and select run as administrator and you have complete access.

If you are malware running as an administrative user you will not be able to though because it requires the malware to elevate itself first.  And if they are elevated malware they can simply run whatever code they want without the service at the same level. admin->system account is trivial in code.

I think #2 is valid but not #1, let me know if I missed something though.

Comment 20

[Robert Kugler]

Brian R. Bondy: 
When someone has physically access to your computer he doesn't need a Firefox privilege escalation vulnerability. He can simply boot a Linux live CD to copy sensitive data or he can manipulate the sticky key function and reboot.
Physical access is a security nightmare!

Scenario 1:
If the attacker compromised the local administrator account (disabled by default in Windows 7 and Vista) his malware is able to copy files to C:\ or C:\Program Files without any UAC prompt.
You're right it's too much effort when your malware is already elevated you can just create a service running with SYSTEM privileges and start it, although creating services isn't smart when you want to stay undetected. 
Okay privilege escalation isn't absolutely necessary in this case but what about the "relative stealth" persistence or automacilly re-compromise? A mozilla.exe in C:\Program Files isn't as suspicious as a startup registry key with a random name! The attacker won't have the opportunity to gain access to the machine every day, but he can be sure that his mozilla.exe will connect back to his C&C server at least every 6 weeks.

Comment 21

[Brian R. Bondy [:bbondy]]

(In reply to Robert Kugler from comment #20)
> Brian R. Bondy: 
> When someone has physically access to your computer he doesn't need a
> Firefox privilege escalation vulnerability. 

Yup I was also arguing the same conclusion.

> 
> Scenario 1:
> If the attacker compromised the local administrator account (disabled by
> default in Windows 7 and Vista) his malware is able to copy files to C:\ or
> C:\Program Files without any UAC prompt.

Does the local administrator account which is disabled have UAC disabled by default?  

> You're right it's too much effort when your malware is already elevated you
> can just create a service running with SYSTEM privileges and start it,
> although creating services isn't smart when you want to stay undetected. 

That's just an example, you can modify an existing service's bin path or keep the bin path and replace an already existing service with your executable.  You can have a driver that doesn't even show up in your services list etc.

> Okay privilege escalation isn't absolutely necessary in this case but what
> about the "relative stealth" persistence or automacilly re-compromise? A
> mozilla.exe in C:\Program Files isn't as suspicious as a startup registry
> key with a random name! The attacker won't have the opportunity to gain
> access to the machine every day, but he can be sure that his mozilla.exe
> will connect back to his C&C server at least every 6 weeks.

I'm confident that one time high elevation means you can have forever high elevation in a variety of ways.  For example using an existing service with a modified binary or driver undetected.

---

I think this boils down to an attack for the people that make their c: writable without elevation.  Still a great report though and thank you for posting it!

Comment 22

[Robert Kugler]

Brian R. Bondy:
"Does the local administrator account which is disabled have UAC disabled by default?"
Exactly, the built-in Administrator account runs all applications with full administrative privilege (default).

I think it would be sec-moderate when there wouldn't be so much
users who are so careless to enable write access to C:\.
When you google "enable write access to C:\" you'll find 
quite a lot forum posts!
"...on a vanilla Windows box it should not be possible to write a file to either C:\ or C:\program files, few people have vanilla configurations. I have seen users, admins and OEMs break these security principles before now. You can only really be reasonably confident in the directories you yourself created, not anything else on the file system."
James Forshaw (bug 748764)

Although it isn't widely exploitable it's a dangerous security risk under special
circumstances!

Comment 23

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1.

Comment 24

[Brian R. Bondy [:bbondy]]

Comment on attachment 731874 [details] [diff] [review]
Patch v1.

Requesting approval for mozilla-central landing and pushing to try server.

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
- Flaw only affects people with writable C:\
- Flag only affects people who first installed with (I think these versions) Mozilla12 and Mozilla13.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Yes.

Which older supported branches are affected by this flaw?
Only applicable if user first installed on (I think these versions) Mozilla12 or Mozilla13 

If not all supported branches, which bug introduced the flaw?
The flaw is not fixing an old problem, but newer installs do not have the problem at all.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
Same code for older/other branches can be applied.

How likely is this patch to cause regressions; how much testing does it need?
Low chance of regressions.

Comment 25

[Robert Strong (they/them - no direct email)]

Comment on attachment 731874 [details] [diff] [review]
Patch v1.

This should do it.

Comment 26

[Brian R. Bondy [:bbondy]]

Tested already by the way with a v12 installed with the unquoted path and doing a new local install fixes it. Upgrade process follows same logic.  I'll test an upgrade though on oak before landing on m-c along with the other bug.

Comment 28

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9e6fe353c9b4

Comment 29

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9e6fe353c9b4

Comment 30

[Brian R. Bondy [:bbondy]]

Comment on attachment 731874 [details] [diff] [review]
Patch v1.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: It is sec-hig

User impact if declined: 
If an admin of a computer has went out of his way to make his c: writable, and then a low integrity process is running, it can obtain high integrity access.  That is if Firefox 12 (and 13?) was installed originally. Later versions of Firefox do not have this bug.

Fix Landed on Version:
v23

Risk to taking this patch (and alternatives if risky): 
Low if we wait a couple days for Nightly builds.

String or UUID changes made by this patch: 
None.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 31

[Alex Keybl [:akeybl]]

Comment on attachment 731874 [details] [diff] [review]
Patch v1.

ESR 10->17 skipped over 12/13, so this only needs to go to Aurora/Beta. Since this impacts updates, we'll take our time uplifting.

Comment 32

[Brian R. Bondy [:bbondy]]

By the way I got an email that this is tracked for ESR17, should tracking-firefox-esr17: 	21+  be cleared?

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/08a001d51ccc

Comment 34

[bhavana bajaj [:bajaj]]

Comment on attachment 731874 [details] [diff] [review]
Patch v1.

Please land by Monday EOD PST to get this into Fx 21 Beta 4 .

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/216376e201d5

Comment 36

[Al Billings [:abillings - ex-MoCo]]

(In reply to Brian R. Bondy [:bbondy] from comment #32)
> By the way I got an email that this is tracked for ESR17, should
> tracking-firefox-esr17: 	21+  be cleared?

Is ESR unaffected?

Comment 37

[Brian R. Bondy [:bbondy]]

I think as per Comment 31.  I was asking because I got emailed after it was esr17-

Comment 38

[Al Billings [:abillings - ex-MoCo]]

Sure, I was just looking for explicit confirmation that ESR is unaffected.

Comment 39

[Brian R. Bondy [:bbondy]]

(In reply to Al Billings [:abillings] from comment #38)
> Sure, I was just looking for explicit confirmation that ESR is unaffected.

I haven't tried it explicitly, but from the best of my knowledge I agree with akeybl. The issue was only present in a couple versions, and those versions never landed inside ESR10/17.