Uncontrolled Search Path Element vulnerability On AHK installer v2.0.2

[marucrypt]

Hello, @Lexikos. I'm opening this issue as advised by the AHK Discord mods.

AutoHotKey installer was found to have an untrusted search path vulnerability, since the installer is relying on the Windows default search order to load libraries. This could potentially allow an attacker to execute arbitrary code on a user's machine.

How to Reproduce (Proof of Concept)
Proof of concept worked on a Microsoft Windows 10 Home VM running version 10.0.19045 Build 19045 (with latest patches)

1. Download AutoHotKey v2.0 installer from AutoHotKey's website.
2. Create a custom DLL and name it TextShaping.dll
3. On the same folder where the installer was downloaded (i.e. C:\Users\<username>\Downloads), drop the custom DLL
4. Run the installer executable. The installer will fail due to calling the fake dll (since the required functions do not exist), but the custom DLL code will execute. Please note that you don't have to be an admin to have the installer execute the DLL, since the TextShaping.dll DLL is loaded before you would get the UAC (User Account Control) prompt.

Remediation Steps
To fix this, Microsoft has multiple guidelines to perform safe DLL search order, such removing the current directory from the standard search path by calling SetDllDirectory
Please see below Microsoft's guidelines:

• https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security

[Lexikos]

All compiled scripts, and indeed most Win32 applications, can be affected by this.

I tested 23 non-AutoHotkey programs that were sitting in my Downloads directory, and found the following:

• 13 programs appeared to be unaffected. Of these,
  • 8 were not running in the Downloads directory; they had self-extracted to a temporary directory. Being a new directory, it did not contain TextShaping.dll.
  • 5 were running in the Downloads directory but had loaded TextShaping.dll from System32 or Syswow64.
• 10 programs were "vulnerable". Of these,
  • 4 crashed outright because the dll failed to load (it was a zero-byte file).
  • 6 showed dialogs or menus that lacked text, because the dll failed to load.

I switched from 7z-sfx to a normal compiled script for v2 setup partly to avoid the use of the Temp directory, since writing there does not require elevation. Related details. (Writing to Downloads does not require elevation anyway, but the setup files could be distributed by more secure means.)

The vulnerability described in this issue is ultimately caused by a Microsoft component loading a dll without specifying a full path or secure search order flags. I believe the onus is on Microsoft to fix this, and not for a hack-fix-workaround to be baked into every single portable application or setup program on Windows.

Some details of the vulnerability are explained by twitter user Kurosh Dabbagh here.

FileZilla developer Tim Kosse responded to an equivalent vulnerability report by closing it as "invalid".

In an old blog post about a very similar situation, Raymond Chen argued that it was not a DLL planting vulernability, but rather an application directory attack. Of course, in this case the application directory is typically the downloads folder. Raymond says "Yup, the downloads folder is another hot tub filled with yucky water. This is related to the "carpet bombing" attack."

Please see below Microsoft's guidelines:

The linked article explains the search order in detail, but offers no guidelines.

SetDllDirectory does not provide a solution, because it cannot be used to disable searching of the application directory.

The application directory can be excluded from the search order with SetDefaultDllDirectories, but this must be called before the program creates any windows, since that is the point at which TextShaping.dll is loaded. The program creates the script's main window before the script executes. In other words, calling it within the script is ineffective.

The default search order can't be changed within AutoHotkey.exe for backward-compatibility reasons. The remaining options are to compile the install script with a custom binary (which won't solve the issue for any other compiled scripts), or to add something like a directive to control the DLL search order/flags at load time (which means v2.1 at the earliest).

SetDefaultDllDirectories must be dynamically linked for the program to run on Windows 7 systems, and it will be unavailable if KB2533623 is not installed.

SetDefaultDllDirectories alone isn't sufficient, because even statically-linked DLLs can be loaded from the application directory, before the program's entry point executes. For instance, dwmapi.dll, because it is not in the KnownDLLs list. The hack-fix-workaround for this is purportedly to delay load all DLLs, and use a delay load hook to force them to load from system32. One implementation of this can be seen in the Rufus source code, but my attempt at applying this to AutoHotkey was unsuccessful.

[marucrypt]

Thank you for taking your time and looking into this issue @Lexikos. Appreciate your detailed response. Hope you have a great day.