[wix-users] Security Best Practices

[Markus Kramer]

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-vulnerability/
> > ). 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-bootstrapper-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/