Closed Bug 1137015 Opened 9 years ago Closed 9 years ago

maintenanceservice_installer.exe installs into exploitable location

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: stefan.kanthak, Unassigned)

References

Details

(Keywords: sec-low, Whiteboard: Requires admin privs to link directories first)

Attachments

(1 file)

Windows-conformant installer which doesnt compromise security
1.06 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20150105205548

Steps to reproduce:

MKLINK /J "%ProgramFiles%\mozilla maintenance service" "%USERPROFILE%\desktop\mms"
Install Thunderbird of Firefox with maintenance service


Actual results:

Binaries of maintenance service written to "%USERPROFILE%\desktop\mms"with insufficient DACL which allows them to be overwritten.


Expected results:

NO VULNERABILITIES!
Do you require admin privileges for this as I asked in the other bug?
If this can be done without admin (admin can do pretty much anything after all) then this also affects Firefox so marking security sensitive.

dveditz, I was unable to do this without an admin account. Can you confirm as well? Thanks!
Group: core-security
Flags: needinfo?(dveditz)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1)
> Do you require admin privileges for this as I asked in the other bug?

That's irrelevant.
The point is:
- you claim "we ignore a user-defined destination by design to avoid exploitation".
- I show that your installer doesnt meet your claim and your design goals and allows exploitation.

FIX YOUR INSTALLER!
See Also: → 871095
So, to clarify these steps:

* User (with admin access?) creates a malicious NTFS junction under Program Files pointing somewhere in the user profile
* User installs Fx/Tb, and the junction means the maintenance service gets installed into user-level space
* Malicious attackers replace/modify the service

Isn't this a bit like "if I smash a hole in my wall, people can then enter my home"?

There's things we could do for defense in depth, but if the attack relies on an attacker gaining admin access as a precondition then it seems to be a low-probability avenue.  (If I'm an attacker with admin privs, there's a lot more I can do to permanently compromise the entire machine, so why would I bother with something as indirect as this?)

Even if the junction creation doesn't require admin (which would seem like a failure state of Windows), this is an attack against a future install of a product, which is also pretty low-probability.

sg:low at best, for me.
(In reply to Mike Connor [:mconnor] from comment #4)
> So, to clarify these steps:
> 
> * User (with admin access?) creates a malicious NTFS junction under Program
> Files pointing somewhere in the user profile
> * User installs Fx/Tb, and the junction means the maintenance service gets
> installed into user-level space
> * Malicious attackers replace/modify the service
> 
> Isn't this a bit like "if I smash a hole in my wall, people can then enter
> my home"?
> 
> There's things we could do for defense in depth, but if the attack relies on
> an attacker gaining admin access as a precondition then it seems to be a
> low-probability avenue.  (If I'm an attacker with admin privs, there's a lot
> more I can do to permanently compromise the entire machine, so why would I
> bother with something as indirect as this?)
> 
> Even if the junction creation doesn't require admin (which would seem like a
> failure state of Windows), this is an attack against a future install of a
> product, which is also pretty low-probability.
> 
> sg:low at best, for me.

Please reread comment #3, then come back and continue here.

There are quite some people out there who create a junction from "%ProgramFiles%" to X:\Programs\ or the like
How is your maintenance service protected against exploitation there?
Compare this against the statement given in comment #2 of 1136413

See the attachment how to install a fictitious service "a la Windows" and without all your bugs.
We don't try to protect users that as an admin intentionally change permissions of the filesystem whether it is by changing the permissions themselves or by adding a junction point to a location that has lesser permissions. The fact remains that the vast majority of users do not do this and that changing the permissions and opening them up to non admin write access would be against best practices.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #7)
> We don't try to protect users that as an admin intentionally change
> permissions of the filesystem whether it is by changing the permissions
> themselves or by adding a junction point to a location that has lesser
> permissions. The fact remains that the vast majority of users do not do this
> and that changing the permissions and opening them up to non admin write
> access would be against best practices.

Your maintenance service is the only one I'm currently aware of that can be abused to get SYSTEM rights in such a configuration.
Without trying very hard I see both Apple Software Update and Dell Update Service under %ProgramFiles%.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #9)
> Without trying very hard I see both Apple Software Update and Dell Update
> Service under %ProgramFiles%.

I dont use crapware from Apple, and I dont have Dell computers.

Treat it as a chance: the first whose service cant be abused any more!
Stefan, I'm not sure if you mean well or not, but your behaviour is aggressive and arrogant.  I've warned you privately, this is your final warning.

On the subject of this bug, this is only "exploitable" if an admin creates an insecure junction pointing at an unprotected disk location before the app is installed.  Given that, I'd take a patch, but I see no reason to hide this bug.  Dan?
(In reply to Mike Connor [:mconnor] from comment #11)
> Stefan, I'm not sure if you mean well or not, but your behaviour is
> aggressive and arrogant.  I've warned you privately, this is your final
> warning.

Now I'm really scared.

> On the subject of this bug, this is only "exploitable" if an admin creates
> an insecure junction pointing at an unprotected disk location before the app
> is installed.  Given that, I'd take a patch, but I see no reason to hide
> this bug.  Dan?

I attached a proof-of-concept for the patch already.
Use Windows native SetupAPI, driven by a simple *.INF, to be called per
RunDll32.Exe SetupAPI.Dll,InstallHinfSection <section> <flags> <*.INF>
instead of a 200kb maintenanceservice_installer.exe and a 100+kb
"%ProgramFiles%\Mozilla Maintenance Service\uninstaller.exe"
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #7)
> We don't try to protect users that as an admin intentionally change
> permissions of the filesystem whether it is by changing the permissions
> themselves or by adding a junction point to a location that has lesser
> permissions.

But you try to protect users who intentionally change the installation
directory via "user-defined installation".
I see a contradiction and inconsistent behaviour there (despite the
fact that you can set individual NTFS DACLs on the installed files,
as shown in my *.INF).

> The fact remains that the vast majority of users do not do this
> and that changing the permissions and opening them up to non admin write
> access would be against best practices.

Right.
And this is clearly not what I request or the purpose of this bug report.

I just expect that the user who performs the installation is informed
that the shared component(s) are not installed into the user-defined
location. A text below the checkbox [x] Install maintenance service
explaining this helps to make your design transparent.
Group: core-security
Flags: needinfo?(dveditz)
Keywords: sec-low
Whiteboard: Requires admin privs to link directories first
The same administrative privileges are required to install the maintenance service!
Component: Untriaged → Installer
My comment was in relation to the "sec-low" security rating: there's no point trying to defend against a malicious admin since they already own the machine. It was not a comment on whether this inconsistency was a bug or not.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Moving to Toolkit, as the comments imply this affects FF as well.
Component: Installer → Application Update
Product: Thunderbird → Toolkit
Version: 31 → unspecified
The same rights it takes to create the junction point that points to an insecure location are the same rights it takes to remove the restrictions of program files to make it an insecure location. Protecting against this just seems silly unless we are also going to also take care of the case where the restrictions of the program files directory have also been removed.

dveditz, if you see a flaw in the above please reopen this bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WONTFIX
As an unprivileged user I can create a junction from "mms" to the non-existing %ProgramFiles% maintenance service dir, but I can't create a junction going the other way (because I have read-only access to ProgramFiles). When I then install the maintenance service I can access the files through the "mine" junction, but the directory contents are still protected by the ProgramFiles access restrictions -- I can't add, modify, or delete files there. All I can really do is delete the junction.

The only way I can do what's described in this bug as an unprivileged user is if the admin first makes Program Files read/write for everyone, in which case it's not a "locked-down" machine and the files can be overwritten directly.
Flags: needinfo?(dveditz)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #17)
> The same rights it takes to create the junction point that points to an
> insecure location are the same rights it takes to remove the restrictions of
> program files to make it an insecure location. Protecting against this just
> seems silly unless we are also going to also take care of the case where the
> restrictions of the program files directory have also been removed.
> 
> dveditz, if you see a flaw in the above please reopen this bug.

As usual you dont get the point:
first I reported the bug "maintenance service not installed into user-defined directory" were you reply "we ignore a user-defined destination by design to avoid exploitation", then I show you that  your claim doesn't hold.
Now you come up with "but a user needs to be able to write to %ProgramFiles%".
The installer of your maintenance service requires this too, so your argument is moot (again).

The point is: the installer ignores the user-defined installation directory and you dont have ANY VALID argument for this misbehaviour.
Fix your installer!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: