[wix-users] Security Best Practices

[Sean Hall]

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/