Possibility of tricking the maintenance service into updating a non-secure location
Categories
(Toolkit :: Application Update, defect, P2)
Tracking
()
People
(Reporter: robert.strong.bugs, Unassigned)
Details
(Keywords: csectype-priv-escalation, sec-high, testcase-wanted, Whiteboard: [iu_tracking])
I'm not positive this is possible but I suspect that it is.
Basically, changing the update.status file so it has pending-service for a non-secure location and then launching the maintenance service directly with the same command line arguments as would be used when the updater launches the maintenance service. Even with the recent work to only write to a secure update log and status file I think it would still be possible to replace some of the files in the non-secure installation directory with Windows symlinks / junction points to overwrite files in a secure location.
If I am incorrect and there aren't instances where this is possible then all the better!
Categorizing as a task at this time since it hasn't been shown to be exploitable as of yet.
|
Reporter | |
Comment 1•5 years ago
|
||
Hi Adam, I discussed this with Jim and he asked me to file this bug and needinfo you to look into it. If you'd like to discuss this please let me know. Thanks!
|
||
Comment 3•5 years ago
|
||
If we allow that the administrator has installed Firefox in a non-secure location, then yes, there are ways to abuse this. Here's an approach that allows dropping files from our install into C:\Windows\System32:
- Get a Nightly installer that's old enough to require a complete update MAR (I think partials are only available for the last two days, I used 2019-10-09-09-58-06)
- Install this, with UAC approval and the Maintenance Service, to a directory on the Desktop (this dir is
Xbelow, in my case C:\Users\Adam\Desktop\Nightly). Uncheck the option to "Launch Firefox Nightly now" (this isn't essential, it just preserves an update for immediate testing).
From this point the administrator has exposed the issue, which can be exploited with regular access to the desktop.
-
Get an update ready to be applied via service (It isn't necessary to do this through Nightly, but this makes it easier):
3a. Start Nightly in offline mode withfirefox.exe -offline(to prevent a staged update before the pref can be flipped)
3b. Set app.update.staging.enabled to false
3c. Uncheck File->Work Offline
3d. Cause an update download (Help->About)
3e. When the update is ready, exit Nightly (don't restart) -
Delete the "browser" subdir from the install directory
-
Create a junction:
mklink /J browser C:\Windows\System32 -
Run the service:
sc start MozillaMaintenance MozillaMaintenance software-update X\updater.exe C:\ProgramData\Mozilla\updates\SOME HASH\updates\0 X X 0 X X\firefox.exe(this has to be run manually as the updater won't normally use the service if it doesn't have to, even with pending-service?)
What should have gone into "browser" gets dumped into System32. I imagine there are possibilities once we can write something there, but I don't have much experience with exploit chains like that.
Another approach, that doesn't rely on junctions, is to just drop in an old updater.exe with known exploitable bugs. This will still pass the signing check, and will then be run by the service.
The essential issue is that once the installer writes the HKLM registry key to allow the install path to be used with the service, it will be possible to use the service there no matter what an unprivileged user might have done with a non-secure install path.
I'm not convinced yet this is a major issue; it seems unlikely that an admin would approve UAC and then decide to install somewhere that a non-admin attacker could access. But it is possible. I think the possibility of messing with the updater in similar circumstances was serious enough that we now copy it to a secure location before checking the signature, so maybe I should be more worried.
I could imagine attempting to restrict this by not allowing the service to run if it thinks it isn't needed, but I don't know how that would work in a way that couldn't be spoofed. The installer might refuse to register the service if it can access the install dir with dropped permissions, but that doesn't fix any existing misconfigurations, and might still be spoofable at install time.
|
|
Reporter | |
Comment 4•5 years ago
•
|
||
A couple of possible mitigations:
Only use the maintenance service for installs that are located under %ProgramW6432% and %ProgramFiles(x86)%. I don't have data for this but I don't think it is controversial that the vast majority of clients that use the maintenance service to update do so for installs that are under program files and for the other cases the client can just use the UAC path, etc.
It might be possible to first verify a file is not a symlink, etc. and then lock the file before performing any operations on the file but this would be much more difficult to get right than the first option.
The first option can mitigate the dropping in of an old updater since the maintenance service could also have a restriction of only updating installs under program files
|
|
Reporter | |
Comment 5•5 years ago
|
||
For option 1, the service tests would have to be modified to support this and we could likely use the maintenance service directory which the tests already have write access to.
|
|
||
Updated•4 years ago
|
|
||
Comment 8•4 years ago
|
||
I believe so, and in fact I think we can treat this as a duplicate, because the second part of comment 3 actually mentions the same exploit method with the old updater.exe that bug 1643199 uses. Thanks for pointing that out.
|
|
Reporter | |
Comment 9•4 years ago
|
||
No worries. I thought this was an exploit path when I asked agashlin to look into this and it looks like the fix I suggested in comment #4 was implemented. Good to know it works.
|
|
||
Comment 10•4 years ago
|
||
I thought so, too, and I pointed this out in bug 1643199 comment 2. I didn't want to dupe that as there was a pending bounty request. Maybe should have duped this one earlier, but I felt there was more info here.
|
||
Updated•3 years ago
|
Description
•