JVNTA#91240916
Insecure DLL Loading and Command Execution Issues on Many Windows Application Programs

Overview

Various Windows application programs (including installers and self-extracting archives) are reported to load Dynamic Link Libraries insecurely and/or invoke executable files insecurely.

Products Affected

• Windows application programs (especially installers, self-extracting archives and portable apps)

Description

Various Windows application programs, especially installers and self-extracting archives, are reported to load Dynamic Link Libraries insecurely.
Those application programs search and load Dynamic Link Libraries from the same directory as the programs reside, before searching system directories.

Typically, Windows application programs are installed in some system directories, and no user can place, remove, modify files on system directories without administrative privilege. Thus, the risk of being tricked to place malicious files on the same directory as application programs is low.
On the other hand, installers, self-extracting archives, and portable apps tend to be placed on users' home directory or its sub directory, and the risk of exploiting insecure Dynamic Link Library loading issue is high.

Many software installers are reported to load Dynamic Link Libraries insecurely. Most of them are created using some installer-packaging tools, and the vulnerability comes from the components provided by those tools.
Application developers should use the latest and updated installer-packaging tools to mitigate the insecure Dynamic Link Library loading, but reports indicate that old vulnerable versions are still used.
 

Some of Windows standard DLLs are observed to load other standard DLLs from the same directory as the application programs. Self-extracting archives created using iexpress utility load DLLs from the same directory, too.
As explained in the following subsection, Microsoft classifies insecure Dynamic Link Library loading issue to two type "Application Directory Type" and "Current Directory Type", and treats the behavior of standard DLLs and iexpress archives above as "Application Directory Type". Microsoft rates the severity of "Application Directory Type" vulnerability as low, and planning no security updates.
You should confirm that there are no untrusted files in the same directory as the program before invoking it, or, should copy the program to some trusted directory or a newly-created temporary directory.

"Application Directory Type" and "Current Directory Type"
Microsoft classifies the insecure DLL loading issue to two type: "Application Directory Type" and "Current Directory Type".
"Application Directory Type" DLL loading means searching a DLL from the same directory as the program, before the intended directories (system directories in most cases). It may result in loading an unexpected DLL.
"Current Directory Type" DLL loading means searching a DLL from the same directory as the data file which a victim user double-clicks on to invoke the associated application program.
Microsoft rates the severity of "Application Directory Type" vulnerability as low, and planning no security updates.
Security Updates are provided for "Current Directory Type" issues, for example, Microsoft Security Advisory 2269637.

Self-Extracting Archives created with archivers
Some self-extracting archives are reported to load Dynamic Link Libraries insecurely. A self-extracting archive consists of compressed data and a stub code to decompress the data. The stub code is provided by the archiver. The vulnerability comes from this stub code. Your archiver should be the latest and updated version to circumvent the insecure Dynamic Link Library loading.
 
Insecure Command Invocation
We receive reports on insecure command invocation by application programs.
Some installers invoke Windows standard utilities or the installed executables (e.g., to edit the registry keys, to register a service, or to complete the initial configuration, etc).
Depending on how to specify the executable, an unexpected file in the same directory may be invoked.
To prevent invoking unexpected executable files, no untrusted files should be in the same directory, or, the installer should be copied to a newly-created temporary directory before invocation.

Impact

Being tricked to place crafted files to the same directory as a vulnerable program, installer, or self-extracting archive andinvoking it causes arbitrary code being executed with the privilege of the victim user.

Solution

For Application Users:
Confirm that no untrusted files exist in the same directory before invoking an installer, self-extracting archive, or portable app.
Another option is to copy the program to some trusted directory or a newly-created temporary directory.

For application Developers:
Use the latest version of the installer-packaging tool or archiver
When creating an installer, use the latest version of the installer-packaging tool.
When creating a self-extracting archive, use the latest version of the archiver.
Moreover, when customizing an installer to invoke some programs, be careful to invoke programs from the intended paths.
Moreover, when an installer needs to invoke some program, be carefull to invoke it from the intended path.

For Installer-Packaging Tool Developers and Archiver Tool Developers:
Confirm the components load Dynamic Link Libraries securely
Verify whether created installers or self-extracting archives are vulnerable. If vulnerable, implement the appropriate measures.