Harden Burn's BootstrapperApplication and elevated engine extraction

[robmen]

User story

• As a setup developer, Burn protects end-users from security attacks as much as possible with defense in depth.
• As a WiX developer, security researchers are dissuaded from opening security threats that are "unsatisfyingly" mitigated with the proper use of signing and UAC.

Proposal

Contrary to this developer's understanding of the Windows file system, it is possible to lock an executable file for read-only access and still ::CreateProcess() the executable. Whether this is a change in modern Windows or an erroneous experience extrapolated to incorrect information, the ability to launch a process from a locked file means Burn can harden its use of the working folder.

In particular, Burn writes the BootstrapperApplication's files and elevated engine file to the working folder (often in TEMP) to launch them. There is a non-insignificant window between those operations where an attacker can swap out the files with malicious files for Burn to execute. This attack vector is mitigated through the use of signing and the UAC prompt, swapping the files will not produce a trusted UAC prompt. However, the window could be significantly reduced to just a few instructions by immediately locking these payloads files for read-only after they are written.

Doing so the bonus effect of preventing a BootstrapperApplication's support files from being prematurely removed from the working folder, in the off case that customers try to clean up their TEMP folder during an install (FireGiant had this 'unlikely' scenario reported).

Considerations

• Locking files that were previously read/write is a breaking change. BootstrapperApplications expecting to edit their BA payload files will have to copy the files first.
• This feature hardens Burn, it cannot completely mitigate the swap BA attack vector. There is a small window between the time the file is closed (after being written to disk) and the time the file is reopened read-only. This window is a minimal number of machine instructions in Burn, so the window is infinitesimal but could theoretically be exploited.

[brantburnett]

I'd like to add that the signing/UAC mitigation doesn't always apply. If launched from ARP for modify/repair/uninstall the main bundle executable is elevated with UAC before it is started by Windows, showing that executable's signature. The later UAC prompt with the signature for BA elevation doesn't occur. This would also be the case if the user simply launches the setup executable elevated using a right click and "Run as administrator".

[robmen]

The later UAC prompt with the signature for BA elevation doesn't occur.

BootstrapperApplications are never elevated. They may end up elevated because the bundle was initially launched as elevated, but the BA is never the subject of a UAC prompt.

[brantburnett]

The later UAC prompt with the signature for BA elevation doesn't occur.

BootstrapperApplications are never elevated. They may end up elevated because the bundle was initially launched as elevated, but the BA is never the subject of a UAC prompt.

Ahh, that's my misunderstanding. But I believe the statement still holds true, I just should have stated it was the signed engine rather than the BA, right?