Valid HTML 4.01 Transitional Valid CSS Valid SVG 1.0

Me, myself & IT

Executable installers considered harmful

Executable installers as well as self-extracting executable archives (SFXs, typically seen on Microsoft® Windows® only) are braindead insanely stupid in concept and dangerous in practice!
They should be considered harmful and treated as unwanted programs malware!

Problems and Deficiencies

Executable installers exhibit the following problems and deficiencies, which result in trivial to exploit weaknesses and vulnerabilities.


Mitigations for (end) users and (their) administrators

Mitigations for developers

Detection of vulnerable executables

Perform the following 9 steps to detect executables vulnerable to DLL hijacking.
  1. Create an UAC-enabled protected administrator test account;

  2. Create an empty file %SystemRoot%\Debug\SAFER.log, grant your test account at least append data permission to it, then remove the permissions for all other accounts;

  3. Create the following Registry entries to enable Software Restriction Policies, without restrictions, with advanced logging, for all users, for all executable files and DLLs:

    ; Copyright © 2005-2018, Stefan Kanthak <‍skanthak‍@‍nexgo‍.‍de‍>
    "DefaultLevel"=dword:00040000                 ; 'Unrestricted'
    "Levels"=dword:00071000                       ; Enable all security levels
    "PolicyScope"=dword:00000000                  ; Apply to 'Users' and 'Administrators'
    "TransparentEnabled"=dword:00000002           ; Apply to executable files and DLLs
    Note: Win32 applications and DLLs are subject to Software Restriction Policies independent of their file extension!
  4. Logon with your test account;

  5. Create an empty directory (or use the existing directory %USERPROFILE%\Downloads\);

  6. Open a Command Prompt in the choosen (empty) directory and run the following command line to create hardlinks to all system DLLs found in the search path in it:

    For %! In ("%PATH:;=" "%") Do For %? In ("%~!\*.DLL"
                                             "%~!\*.TSP") Do If Not Exist "%~nx?" MkLink /H "%~nx?" "%?"
    Note: the command processor and its builtin MkLink command have to be run under the NT AUTHORITY\SYSTEM account!
  7. Copy your executables into this directory and execute them per double-click;

  8. Determine the DLLs your executables loaded from the application directory by running the following command line in the still open command prompt:

    "%SystemRoot%\System32\Find.exe" /I "%CD%\" "%SystemRoot%\Debug\SAFER.log"
  9. Fix the vulnerable executables and retest them!


Download the executable installers 7z1602.exe and 7z1602-x64.exe, save them in the prepared directory %USERPROFILE%\Downloads\ and execute them just until they display their first dialog box which prompts for the target directory: Note: on all supported versions of Windows NT, UXTheme.dll is loaded from the program’s application directory %USERPROFILE%\Downloads\ instead Windows’ system directory %SystemRoot%\System32\ alias %SystemRoot%\SysWoW64\ respectively, resulting in an LCE vulnerability.
Note: on Windows Vista and newer versions of Windows NT, 7z1602.exe and 7z1602-x64.exe request administrative privileges via their embedded application manifest, resulting in an additional EoP vulnerability!

Advantages of native installation packages

In contrast to executable installers, native installation packages for the operating system’s package manager exhibit the following advantages. The point is: well-known package formats allow you to inspect things, binary executables generally don’t.
In more detail:
  1. It’s not a vulnerability, but a weakness and (design) bug in the first place: there is no need to execute (potentially malicious) programs from (potentially) untrusted sources or with questionable (unknown or even malicious) contents to install software.
    This weakness turns into a vulnerability, if

  2. Binary executables are generally opaque: you can’t tell what they actually do unless you have their source (and built them yourself in a trusted environment), or until you reverse engineer them completely.
    In case of installers, you need the sources of the installer (plus its unpacker), the sources of the creator and the sources of the script used to build the final binary executable.

  3. The format of these packages is well-known and documented, they can be unpacked and their contents as well as their instructions/scripts read and inspected.
    The tools to create/build, edit/modify, unpack and even rebuild them are typically part of the OS’s package manager or provided as part of the OS’s SDK.

Always use the target platforms native package or archive formats to distribute your software or files!
The problem are the morons who build binary executables to install software (or just unpack some files) and hand these binary executables to unsuspecting and unskilled users, expecting them to actually execute them.
This really nasty behaviour of almost all developers/companies out there trained users to execute almost anything they get their hands on.
The solution for this is simple: � � � � � � �


If you miss anything here, have additions, comments, corrections, criticism or questions, want to give feedback, hints or tipps, report broken links, bugs, errors, inaccuracies, omissions, vulnerabilities or weaknesses, …:
don’t hesitate to contact me and feel free to ask, comment, criticise, flame, notify or report!

Use the X.509 certificate to send S/MIME encrypted mail.

Notes: I dislike HTML (and even weirder formats too) in email, I prefer to receive plain text.
I also expect to see a full (real) name as sender, not a nickname!
Emails in weird formats and without a proper sender name are likely to be discarded.
I abhor top posts and expect inline quotes in replies.

Terms and Conditions

By using this site, you signify your agreement to these terms and conditions. If you do not agree to these terms and conditions, do not use this site!
Copyright © 1995–2018 • Stefan Kanthak • <‍skanthak‍@‍nexgo‍.‍de‍>