[wix-users] Security Best Practices

Tue Jul 21 06:45:48 PDT 2020

I'm unsure as to what makes this 'special'.
A file is replaced immediately before a user executes it with elevated privileges.
Why is this specific to WiX?

It's not WiX granting the elevated privileges, it is an End User.
If the End User is going to just click UAC prompts without confirming that this is indeed what they anticipated to occur, then isn't the onus on them?

If you feel there's not enough 'security' around this, then you could enforce an OS level allow-list process (formerly known as white-listing), such that only applications meeting a certain criteria are allowed to be executed.  Problem solved.

Bevan

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Markus Kramer via wix-users
Sent: 21 July 2020 23:11
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Markus Kramer <markuskramerigitt at gmail.com>
Subject: Re: [wix-users] Security Best Practices

I find that replacing the .exe right before the WiX bootstrapper tries to run it elevated is a security vulnerability.
An attacker could wait for the next install and misuse its elevation.

Does an msi have the same weakness?

On Tue, Jul 21, 2020, 06:20 Sean Hall via wix-users < wix-users at lists.wixtoolset.org> wrote:

> The case of replacing the .exe right before the WiX bootstrapper tries 
> to run it elevated is not a security vulnerability. It would be a 
> security vulnerability if it was run elevated without a UAC prompt. 
> This is because the attacker is already executing code on the machine, 
> which means they can also try to execute an .exe requiring elevation 
> and hope the user accepts the UAC prompt. The UAC prompt is the only 
> way to protect against the threat of an attacker running code on the machine.
>
> For a per-machine bundle, there is one process that is intended to run 
> unelevated (the initial process that runs the BootstrapperApplication 
> and acquires the files). That process will start another instance of 
> itself elevated in order to do the things requiring administrator 
> privileges. If the BA process is elevated then we are using the system 
> TEMP directory instead of the user's TEMP directory. As we pointed 
> out, there is no security vulnerability doing that because 
> non-elevated code can't monitor the system TEMP directory. (And if the 
> monitoring code is already elevated then it's already game over)
>
> 5830 is only about the Layout operation, not installation. In that 
> case, the files have too restrictive permissions. Which is a bug and 
> not a security vulnerability. Don't run the initial process elevated 
> and you avoid this bug. It is normal for the elevated process to be 
> elevated, it is not normal execution for the bundle to be launched elevated.
>
>
> On Tue, Jul 21, 2020, 06:13 fishstick.flotilla via wix-users < 
> wix-users at lists.wixtoolset.org> wrote:
>
> > I would like to know more about WiX installer best security 
> > practices. I know this is long, but please bear with me.
> >
> > During a crowd-sourced pen test of one of our products, this 
> > security
> flaw
> > in the WiX bootstrapper was reported:
> >
> > -
> >
> > Monitor the %TEMP% directory for new directories that start with the 
> > character {, end with the character }, and contain a sub-directory 
> > named .ba. This will allow us to detect the installation directory 
> > to infect
> with
> > our malicious binary.
> >
> > -
> >
> > After finding the installation directory, quickly place our 
> > malicious binary in a new .be sub-directory.
> >
> > -
> >
> > Monitor the Bootstrapper.exe binary we just copied for changes. If a 
> > change is detected, quickly replace the binary with our malicious one.
> >
> > -
> >
> > After the first change, the installer starts the binary and we gain 
> > Administrator privileges.
> >
> > Two potential outcomes were described:
> >
> > -
> >
> > Our binary is replaced with an unsigned binary from the bad actor.
> >
> > -
> >
> > Our binary could be replaced a signed binary (either an old one of 
> > our
> own
> > or another vendor’s) that is vulnerable to either "application 
> > folder" or "current directory" DLL hijacking (
> >
> https://msrc-blog.microsoft.com/2018/04/04/triaging-a-dll-planting-vul
> nerability/
> > ). This is more serious, since it would appear to be coming from the 
> > correct vendor in the UAC prompt.
> >
> > This bug (https://github.com/wixtoolset/issues/issues/6149) 
> > describes this as a non-issue because it “will only work if the 
> > program monitoring the folder is elevated. Normal users can't scan 
> > the contents of the
> system
> > TEMP folder.”
> >
> > However, this article (
> > https://wixtoolset.org/development/wips/5184-burn-clean-room/) says 
> > that running elevated “is not normal execution for Burn.” This Stack 
> > Overflow question (
> >
> https://stackoverflow.com/questions/50720476/wix-3-11-1-burn-bootstrap
> per-fails-to-elevate
> )
> > and this bug report 
> > (https://github.com/wixtoolset/issues/issues/5830)
> do
> > not leave me with good impressions of elevated execution support.
> >
> > When WiX runs unelevated the files are created in the user’s own 
> > temp folder where a malicious process running as the user could 
> > access
> without a
> > UAC prompt which brings us back to the original issue.
> >
> > What is the recommended solution to protect our users from this? Is 
> > running the bootstrapper EXE elevated currently a supported scenario 
> > in
> WiX?
> >
> > We want to make sure we are delivering the most secure solution possible.
> >
> > Sent with [ProtonMail](https://protonmail.com) Secure Email.
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant 
> > http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/