Security Measures

Inno Setup incorporates many security measures, not just in Setup and Uninstall but also in the compiler toolchain.

Many of these security measures add defense-in-depth; they do not address specific vulnerabilities.

This topic lists the security measures, focusing on Setup. In general, anything applying to Setup also applies to Uninstall, and the setup loader program (SetupLdr).

DLL hijacking protection

Setup employs protections against DLL hijacking (also known as DLL sideloading):

• Setup immediately removes all directories except the System directory from the DLL search path at startup.
• Setup never loads DLLs from a relative path and instead always uses absolute paths.
• Windows is known to sideload certain DLLs without specifying a path, even when not asked to do so. To force it to load these from the System directory, special loadFrom instructions are included in the manifest file of Setup. A daily automatic test is used to detect Windows sideloading any new DLLs not yet included in these special loadFrom instructions.
• Another special loadFrom instruction specifically for comctl32.dll is added to the manifest file of the setup loader program at compile time, replacing the regular dependency section.

Temporary directory security

SetupLdr, Setup, and Uninstall create subdirectories under the user's top-level temporary directory (typically %LOCALAPPDATA%\Temp for users other than SYSTEM).

The actual Setup program is extracted to and runs from the subdirectory created by SetupLdr. Storing the file in a subdirectory ensures that Setup cannot unintentionally make use of DLLs or other files that exist in the top-level directory.

The creation of the subdirectories is secured in several ways:

• The top-level temporary directory path is retrieved using the GetTempPath2 API when available. This means that when running under the SYSTEM user account, subdirectories will be created under the private %SystemRoot%\SystemTemp directory instead of the shared %SystemRoot%\Temp directory. GetTempPath2 was first introduced in Windows 11 and later backported to Windows 10 and Windows Server 2016. On older systems, GetTempPath is used instead.
• The names of the subdirectories include ten base-36 digits (0–9, A–Z), randomly generated using a cryptographically secure random number generator (CSPRNG).

• When the top-level temporary directory path is %SystemRoot%\Temp, subdirectories are created with a special access control list (ACL) that contains "allow" entries for only the current user, the built-in Administrators group, and the SYSTEM user. This is necessary because the default ACL on %SystemRoot%\Temp allows all unprivileged users to create files inside subdirectories.

  The same ACL is used when the process is running elevated and the top-level temporary directory is on a local drive (any path), except the current user's access is set to "Read & Execute" rather than "Full Control". Although Microsoft does not intend for elevation to define a security boundary, this is done as a defense-in-depth measure to prevent non-elevated processes running under the same user account from writing to the subdirectory.

No sensitive material is written to the temporary directories.

Memory protection

Setup enables Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) by default. 64-bit installers support high-entropy ASLR.

See DEPCompatible and ASLRCompatible for more information.

Path security

Setup uses a custom path validation function library which is extremely robust and knows about all the various path mechanisms available in Windows, including some very obscure ones. The library is tested against a very large list of possible valid and invalid inputs.

When extracting files from an external archive like a .7z or .zip archive, the library is used to protect against malicious archives.

Redirection mitigation

The RedirectionGuard mitigation, available on Windows 11 and Windows 10 22H2, blocks traversal of NTFS junctions and symbolic links created by unprivileged users (or any non-elevated processes).

By default, Setup attempts to enable Windows' RedirectionGuard mitigation on its own process. Uninstall also enables RedirectionGuard for its process if it was successfully enabled during the most recent installation of the application.

See RedirectionGuard for more information.

Program launch security

The setup loader program always uses an asInvoker manifest regardless of the PrivilegesRequired setting, and Setup requests elevation only when needed.

When launching other programs for the user, like post-install from the [Run] section, or when the user clicks on a link, Setup ensures these programs are launched unelevated by default, even if Setup itself is running elevated. It achieves this by requesting the setup loader to perform the launch, instead of directly launching the other program itself.

Also, when launching other programs and creating shortcuts, Setup ensures the working directory is never left unspecified.

Corruption or tampering detection

Setup (and Uninstall) can be digitally signed automatically by the compiler. The compiler can also sign your own original source files for you, or just verify that you did not forget to do this yourself.

After signing, the compiler double-checks that the signature was added without otherwise changing the original file.

See SignTool for more information.

Additionally, an integrated signature-verification capability is included that can be used to detect corruption or tampering in your files at compile time, before files are included in an installer being built, or during installation, before Setup copies external files onto a user's system. This capability is protected against the Time-Of-Check to Time-Of-Use (TOCTOU) problem throughout, and uses strong cryptography.

See .issig Signatures: Introduction for more information.

Setup also uses SHA-256 hashes to verify various components, and you can use these yourself as well. Older hashing algorithms are available, but not used for security purposes by Setup.

Encryption

Password-protected encryption is available, using strong XChaCha20 encryption and PBKDF2-HMAC-SHA256 key derivation. All salts and nonces are generated using a cryptographically secure random number generator (CSPRNG).

See Encryption for more information.

Download security

Setup can securely download files from remote servers, and verify their integrity, without using any [Code]. It uses these protections:

• Expired and self-signed certificates are never accepted.
• TLS 1.0 and TLS 1.1 are never accepted. Both TLS 1.2 and TLS 1.3 are supported.
• Downloaded files can be verified using a SHA-256 hash or an .issig signature. Using the latter has the benefit that your script does not need to be changed when the downloaded file or archive changes, so any installers built will also keep working (they are "evergreen").
• Passwords in URLs are automatically excluded from Setup's log.

Other security measures

Setup:

• The [Run] and [UninstallRun] sections support a dontlogparameters flag to prevent parameters from being included in Setup's log.

Compiler:

• The compiler itself uses .issig signature files to detect corruption or tampering with components such as Setup, before using them to build your installer.
• The compiler doesn't allow .isl message files specified in the [Languages] section to contain compiler directives such as #include. This stops any translations from injecting unexpected content.
• The [Files] section supports a notimestamp flag to prevent files from being stored with a timestamp. Use this flag to help make builds reproducible, even if you cannot preserve timestamps on source files.

IDE:

• The IDE is designed to never execute any commands from scripts when you merely open them.

Supply-chain security

Besides securing Inno Setup itself, we have also taken many steps to ensure the integrity of Inno Setup releases:

• Releases are built on a dedicated machine only used for this purpose. Signing keys are not stored on other machines.
• The Inno Setup source code is self-contained and no external dependencies are pulled in when a release is built.
• Precompiled files included in Inno Setup's source code are code signed and are accompanied with .issig signature files to detect corruption or tampering before using them to build a release.
• Vendor updates of third-party source code (7-Zip, LZMA SDK, zlib, bzip2, Scintilla) are reviewed before being applied. An SPDX Software Bill of Materials (SBOM) is available. Of the named sources, only LZMA SDK is an integral part of the Setup program, and only in a reduced form.
• Release binaries are made available through immutable GitHub releases and accompanied with .issig signature files you can use to detect corruption or tampering before running them. For more details, see Verifying Inno Setup Downloads.
• Our GitHub repositories require signed commits on all branches, have GitHub Actions disabled, and do not allow any workflows to run.

Vulnerability management

We welcome good-faith security reports:

• If you discover a security vulnerability in Inno Setup, please contact us privately before making it public.
• Before reporting, make sure you fully understand the issue yourself and can explain it in your own words.
• We have extensive knowledge of what constitutes a security vulnerability in Windows, and what does not. When you are unsure, please reframe your report as a request for defense-in-depth.
• For example, as Microsoft points out, User Account Control (UAC) elevation is a convenience feature, not a security boundary.
• User self-sabotage is generally not a vulnerability.