Rationale for using CPL as an installer format (from https://bitbucket.org/jtuc/winmerge2011/downloads/)

Rationale_for_using_CPL_as_an_installer_format.txt

** Rationale for using CPL as an installer format **

An issue with EXE installers is that they are likely to pick up bogus DLLs
from the directory they execute from, which, from security perspective, must
be assumed to be polluted with malicious stuff of all kinds. This holds even
for installers which carefully avoid DLL dependencies to the possible extent,
because the various DLL injection mechanisms built into Windows may introduce
additional dependencies which practically go beyond anyone's control.

https://blogs.msdn.microsoft.com/oldnewthing/20130802-00/?p=3633 provides some
reasoning on how and why giving DLLs in the application directory precedence
over system DLLs is essentially inevitable for proper system operation.

My understanding is that the OS should bypass the application directory when
resolving dependencies of injected DLLs. It doesn't, at least on Windows 7.
For example, Trend Micro's tmmon.dll depends on sfc.dll. To work around some
interference with Visual Leak Detector which was crashing my debug sessions,
I ended up substituting sfc.dll with one returning FALSE from DllMain(),
which I placed in the application directory, where it prevented tmmon.dll
from loading. This should not have been possible.

The point in favor of CPL as an installer format is that it executes in the
context of %SystemRoot%\System32\control.exe, which is less attackable since
it lives in a high integrity directory.

MSI obviously shares the same benefit, but isn't always terribly convenient.

The CPL installers for WinMerge 2011 use the 7-Zip HTSFX self extractor stub
from https://github.com/datadiode/7zsfxmm, and, like previous installers, can
be inspected and extracted with 7-Zip.

An unfortunate fact about CPL is its usefulness for creating malware. To many
folks, a CPL file from an untrusted source may appear less dangerous to open
than an EXE file, as it doesn't look as much like an executable file format.
What adds to the issue is that an unsigned CPL can elevate itself without
triggering an unknown issuer warning. The UAC prompt correctly identifies
Microsoft as the issuer of rundll32.exe, which then runs the unsigned CPL
without further notice.

Due to the questionable role CPL plays in malware business, I consider the
move to a CPL installer an experiment. The CPL installer also provides an
entry point for executing as an MSI custom action, which is among possible
options to take if CPL turns out to cause headaches.