Installer tampering while preserving authenticode signature

Windows binaries generated with InstallBuilder versions earlier than 19.7.0 are vulnerable to tampering even if they contain a valid Authenticode signature.  

This issue was reported by Youfu Zhang of Chaitin Security Research Lab (@ChaitinTech). After verifying Mr. Zhang’s report, we released an updated version of InstallBuilder and notified our existing customers so they could re-build and re-release their installers.  

Background  

Authenticode is a Windows technology designed to ensure executable files cannot be tampered with. It allows for adding unauthenticated attributes post-signing without invalidating the signature, as described in the following article:  https://blogs.msdn.microsoft.com/ieinternals/2014/09/04/caveats-for-authenticode-code-signing/ InstallBuilder installers created with versions earlier than 19.7.0 are vulnerable to tampering even if they contain a valid Authenticode signature. A specially crafted payload can be appended to an existing installer and trick the installer initialization code to execute code included in it, while the existing signature remains valid.  

Remediation  

InstallBuilder customers should re-build and re-release their installers using version 19.7.0 or later. Because this issue can be exploited with existing binaries already released, they should also remind their users to only download installers from official sources. Additionally, providing a hash (such as SHA-256) for the binaries enables customers a secondary way of ensuring the integrity of the installers: while the Authenticode signature may still be valid, modified installers will have a different hash.   

A ‘hard revocation’ of the customer Authenticode signing certificate is an optional, alternative step. Unfortunately it has many practical limitations. In addition to invalidating potentially modified installers, it will invalidate legitimate installers, including existing deployments of customer’s application binaries that may have been signed with the same certificate. Even with a revoked certificate, various versions of Windows will still allow binaries to be executed.   

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2019-5530 to this issue. Bitrock engineers have evaluated this issue to have a CVSSv3 score of 6.7 

Bitrock would like to thank Youfu Zhang’s for responsibly reporting this issue to us. 

You can download the latest version of InstallBuilder from our download page. If you have any questions regarding this security issue, or if you need any help with upgrading your installer, please do not hesitate to contact BitRock Support through email at support@bitrock.com or through our Help Desk.

Conclusion  

Given the potential impact of this security issue, we urge our users to upgrade and re-build their installers as soon as possible. 

Added notarization support

As you might know for the upcoming macOS Catalina (10.15) Apple will require applications signed with a Developer ID to be submitted for notarization. An important requirement for notarization is that the application has a hardened runtime enabled. For that reason InstallBuilder now supports creating macOS signatures with the hardened runtime capability enabled, allowing the installers to be notarized by Apple. Here is an overview of the changes for InstallBuilder 19.6.0

• Support creating macOS signatures with hardened runtime enabled to allow notarization
• POTENTIAL INCOMPATIBILITY: Changed <osxPlatforms> default value to osx-x86_64
• New installer_http_proxy variable to programmatically access the provided proxy information
• Updated documentation
• Fixed some Windows configuration attributes not being properly applied to windows-x64 Java launchers
• Fixed proxy page not honoring the provided configuration when running in text mode
• Fixed Linux builder failing on some environments with misconfigured time zone
• Fixed missing localized string

Added support for Windows native 64-bit installer binaries

InstallBuilder 19.5.0 is now available and comes with an important update.

As you may know, InstallBuilder already comes with support for building native 64-bit installers for Linux and macOS. We are happy to announce that we've added support for building native 64bit installers for Windows as well.

This provides multiple benefits compared to existing approach.  While previously it was possible to make InstallBuilder installers behave like a 64-bit application, the binary runtime was actually 32-bit binary and required 32-bit support in the operating system.

With the new approach, it is possible to use the installers inside Windows flavors that only allow running 64-bit binaries, such as Windows Nano Server. Creating 64-bit binaries also allows configuring larger block sizes for the installer, by setting larger values for the <lzmaUltraBlockSize> project property. This allows the creation of smaller installers. However, with the 32-bit binaries, setting the block size increases memory usage and memory fragmentation, which can lead to the installer failing. This is now possible and fully supported with 64-bit Windows binaries.

To build native 64bit installers, all that is needed is to specify `windows-x64` as the build platform - such as the by running the following in the command line:

    ./builder.exe build sample.xml windows-x64

Here is the complete list of changes for version 19.5.0:

• Added new windows-x64 build platform
• Added 64-bit version of osxsigner tool
• Fixed malformed logic in <iniFileTest> rule
• Fixed welcome page displaying truncated trailing letters on some macOS environments
• Updated documentation

InstallBuilder 19.4.0 and 19.4.1 released

We recently released version 19.4.0 and 19.4.1. Among other improvements and bug fixes, we have extended the <componentTest> rule which now allows you to check if a parent component is selected. You can do so by setting the new <checkParentComponents> property.  

<componentTest>

  <logic>selected</logic>

  <name>childcomponent</name>

  <checkParentComponents>1</checkParentComponents>

</componentTest>

Here is the full list of improvements for both releases. 

Version 19.4.1:

• 
  

  Fixed incorrect final page layout on macOS when enabling the osx-x86_64 runtime
• 
  

  Improved <setInstallerVariableFromRegEx> error reporting

Version 19.4.0

• 
  

  Improved <getPermissions> error reporting when operating over non-existent files
• 
  

  Fixed Windows AutoUpdate generation failing because of malformed default icon
• 
  

  Allow <componentTest> rule to take into account parent components in its checks

InstallBuilder 19.3.0 Available!

Version 19.3.0 comes with many improvements, an important one being the new <validatedActionGroup> action which allows you to validate a group of actions and display a configurable abort-retry dialog if an error occurs. This can be useful for example when running your application as a postInstallation action:

     <postInstallationActionList>
        ...
        <validatedActionGroup>
            <severity>warning</severity> 
            <text>The application failed to launch. Do you want to retry?</text>
            <type>abortRetry</type>
            <actionList>
                <runProgram>
                    <workingDirectory>${installdir}/scripts</workingDirectory> 
                   <program>./launch.sh</program>
                </runProgram>
            </actionList>
        </validatedActionGroup>
        ...
     </postInstallationActionList>

Additionally we have added support for Java launchers changing the working directory to the launcher’s directory before proceeding with launching the application by enabling the new <useLauncherDirectoryAsWorkingDirectory> property, as well as support for Windows Server 2019.

Here is the full list of changes:

• New <validatedActionGroup> action
• Added <useLauncherDirectoryAsWorkingDirectory> to Java launchers to allow preserving the current working directory on execution
• Added Windows Server 2019 support
• Improved documentation
• Updated zlib dependency on Linux and Windows
• Fixed macOS installers always exiting with zero code when enabling <requireInstallationByRootUser>
• Fixed some Builder popups not kept on top when running on macOS
• Fixed installers aborting at startup on some solaris and linux-ia64 environments
• Fixed macOS installers incorrectly wrapping text on some languages
• Fixed custom <uninstallerDirectory> not being removed on macOS
• Fixed outdated welcome screen
• Fixed <findFile> returning malformed results when invoked in the installer_directory 

InstallBuilder 19.2.0 Released

The recently released 19.2.0 version of InstallBuilder includes an important fix for installers relying on payload encryption. This is an optional feature that enables the password-protection of installers, prompting the end-user for a password at launch time, before allowing the installation to continue. Devcore - a security consulting company - discovered that by using system debugging tools, it was possible to have access to this password, in turn making it possible to bypass this check. Most InstallBuilder customers don’t use this functionality, and it is disabled by default as most application developers implement password control in their own apps. However, if you do use this functionality, it is important that you please update to this latest version that fixes the issue.

• Fix handling of password in <enableEncryption> setting

InstallBuilder 19.1.0 Available Now

For January our engineers have been working on the following improvements:

• Added support for FreeBSD 10 and higher
• New <iniFileTest> rule
• Improved GUI responsiveness during <autoDetectJava> action

OpenJDK 11 available for download now

BitRock InstallBuilder provides an easy way to embed Java runtime along with your application so that installation of JRE is not required. In order to make the process simple, BitRock is providing a ready to use Java binaries - JRE or JDK - that can be included along with your application.

As you might know, starting with Java 11, Oracle has shifted from a feature-driven release model to a time-driven “train” model and will from now on provide two binary distributions of the JDK. The first, commercial Oracle JDK will be delivered under the Oracle Binary Code License Agreement for Java SE, and will have Long Term support (3 years) while the second distribution is built directly from the OpenJDK source code, will be released under the less restrictive GPLv2 license with classpath exception (CPE) and will only receive updates for six months, until the release of the next JDK version.

Due to those changes in the licensing and the feature parity between both distributions, from now on our InstallBuilder Java components will be based on OpenJDK, starting with OpenJDK 11 which is available for download now.

The list of supported platforms will also change. Starting with Java 11, only 64-bit versions of Java are available and will only be supported on Windows, macOS and Linux.

We will continue to update our Java components with each new OpenJDK release every six months and will make OpenJDK 8 available for download as well when a newer version of Java 8 is released. Java 8 will be supported only as 64-bit binaries, for Windows and Linux operating systems.

BitRock has been providing Java bundles for InstallBuilder since 2011. We will continue providing the same ready to use bundles in 2019 and beyond. The only change is that the Java bundles will now be using OpenJDK builds - which implies licensing changes and may cause slight incompatibilities for applications depending on Java’s internals.

Starting with Java 11 The JavaFX library will no longer be included but needs to be added as a separate module. We have prepared a tutorial to show how this can be done.

InstallBuilder 18.12.0 Released

We recently released version 18.12.0 of BitRock InstallBuilder. The new release features the following improvements:

• Reduced memory usage building and running big project installers
• Fixed license page text not properly wrapping in some macOS scenarios when running in Qt mode
• Updated documentation to include new Java 11 bundles
• Fixed "InstallLocation" Windows registry value being improperly quoted