When running elevated, Burn uses the Windows Temp folder as its working folder
to prevent normal processes from tampering with the files. Windows Temp does
allow non-elevated processes to write to the folder but they cannot see the
files there. Unfortunately, contrary to our belief, non-elevated processes
can read the files in Windows Temp by watching for directory changes. This
allows a malicious process to lie in wait, watching the Windows Temp folder
until a Burn process is launched elevated, then attack the working folder.
Mitigate that attack by protecting the working folder to only elevated users.
Managed custom actions also fall back to using the Windows Temp folder in
some cases and thus can be exposed in a similar fashion as an elevated Burn
process. Remove that possibility.
When deleting directories recursively, an elevated custom action
following junctions in a user-writable location could recurse into
any directory, including some that you might not want to be deleted.
Therefore, avoid recursing into directories that are actually
junctions (aka "reparse points").
This applies to:
- The RemoveFoldersEx custom action (which doesn't actually do deletions
but would instruct elevated MSI to delete on your behalf).
- DTF's custom action runner.
When introducing ARM64 support into the Windows Installer, Microsoft broke
the ICE CUBe files in various ways. To minimize the impact of the breakage
move the mergemod.cub file back to pre-ARM64 support. Validating ARM64 Merge
Modules is not likely to work but that option is better than the regression.
Fixeswixtoolset/issues#8065
This will prevent elevated processes from accidentally following a junction
from a user-writable directory to a per-machine directory and erroneously
deleting the per-machine contents.
Since the deferred custom action is scheduled only in `InstallExecuteSequence`, the `SetProperty/@Sequence` attribute must be set to "execute" since the default is "both". This leads to a LGHT0001 error about a missing `ActionRow` that can be difficult to diagnose.
In order to fix error:
The localization variable !(loc.msierrSecureObjectsUnknownType) is unknown. Please ensure the variable is defined.
in UtilExtension.wxs when using ru-Ru localization.