Wix bundle security issues - Special permissions

[benp87]

• Which version of WiX are you building with?

3.11.2

• Which version of Visual Studio are you building with (if any)?

Visual Studio 2019 16.5.0

• Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

Wix Toolset extension 2019 1.0.0.4

• Which version of .NET are you building with?

4.6.2

• If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Windows 10, version 1903

• Describe the problem and the steps to reproduce it.

When running an installer bundle, the content of the bundle is being extracted to a temporary folder in TEMP directory, if running normally without admin permissions, the folder is in a user's temp directory, otherwise the folder is in "C:\Windows\Temp".

I can see a security issue here:
In case of a user's temp directory, a hacker can just changed the DLLs of that folder and make the user run a malicious DLLs when he runs the bundle.
But when the folder is "C:\Windows\Temp", even though only admin suppose to have permissions there, a normal user still have "special permissions" which allows him to change the files there:

This also allow hacker to replace DLLs..

• Describe the behavior you expected and how it differed from the actual behavior.

When the bundle content is extracted to "C:\Windows\Temp":

1. Create a new folder in "C:\Windows\Temp".
2. Change folder's ACL (Access Control List) to admin.
3. "User" should not have "special access" - FILE_WRITE_DATA.

[robmen]

This is mitigated because Burn uses a random name for the folder in TEMP that is mathematically impossible to guess by an attacker.

[benp87]

This is mitigated because Burn uses a random name for the folder in TEMP that is mathematically impossible to guess by an attacker.

I can write a program that monitors the TEMP folder (Let's say using FileSystemWatcher .NET Class), immediately after a folder is created, I can replace the bootstrapper application DLL with my own DLL, before the burn loads it.

[robmen]

That will only work if the program monitoring the folder is elevated. Normal users can't scan the contents of the system TEMP folder.

[robmen]

When the burn engine elevates, it will then be affected by the injected DLLs.

This is incorrect. The elevated engine protects against this. If you have a DLL that can be injected into the elevated engine without elevating, please do open a security issue.

The solution would be to ensure the .be folder is created with, or is modified with, more restrictive permissions.

This is illogical. If such a folder is created with permissions preventing the user from writing to it, how would the elevated engine be placed there?

[robmen]

The correct way to report security vulnerabilities is to open an advisory issue. That allows us to respond securely while investigating.