I subscribe to the weekly U.S. National Cyber Awareness System Bulletins for Cybersecurity and Infrastructure Security Agency. The Vulnerability Summary for the week of 26-July has this entry for AutoHotkey:
Description: A process injection vulnerability in setup.exe of AutoHotkey 1.1.32.00 allows attackers to escalate privileges.
Published Date: 2021-07-26
CVSS Score: not yet calculated
Source & Patch Info: CVE-2020-18174 MISC
Maybe this has been fixed between 1.1.32.00 and the current 1.1.33.09, but I thought it was worthwhile to post here. Regards, Joe
Re: Process injection vulnerability
Posted: 04 Aug 2021, 03:34
by fivef
Can anyone confirm that this vulnerability was fixed with 1.1.33.09? I would really like to use AutoHotkey at my company but IT sais we can't until this vulnerability is fixed. Looking at the vulnerability info here: https://github.com/GitHubAssessments/CVE_Assessments_02_2020 it looks like a false positive to me. Does anyone understand the statement: "The problem is likely to be found in the overlay."?
This appears to indicate that the "vulnerability" was discovered merely by observing AutoHotkey_1.1.32.00_setup.exe launching setup.exe, where the latter (but not the former) was flagged as a virus. The former is a 7-zip self extracting exe, while the latter is a compiled script which is extracted and then launched to run the actual setup. Compiled scripts of some versions are commonly known to cause false positive detections.
I have confirmed this is the original setup.exe contained by the original v1.1.32.00 setup file.
Re: Process injection vulnerability
Posted: 06 Aug 2021, 20:14
by JoeWinograd
Hi lexikos,
Thanks for that analysis...much appreciated! Regards, Joe
Re: Process injection vulnerability
Posted: 07 Aug 2021, 03:09
by swagfag
@lexikos so was anything ever disclosed to u(the vendor)? the cve is old, why is it going public now?
have u investigated what those references to ERROR_INSUFFICIENT_BUFFER are? i presume that's what he wants to target with the exploit. are those (legitimate, ie u call it 2x to obtain the size required) DllCalls the embedded setup.ahk is making? or legitimate calls made by the interpreter? or actual incorrect buffer usage?
regardless. if ure convinced this isnt a vulnerability but just someone padding their resume, u should try taking the cve down. otherwise we'll be seeing a lot more of what @fivef was complaining about, ammo for IT departments...
Re: Process injection vulnerability
Posted: 08 Aug 2021, 02:59
by lexikos
No, the first I heard of it was via this topic.
As I attempted to explain above, the conclusion shown in the assessment appears to be based on false premises. It states that there is a "process injection" vulnerability, but does not explain what the vulnerability is or how it would be exploited. As far as I can tell, none of the factoids presented in the assessment constitute actual evidence of a vulnerability.
To be clear, what they assessed is not AutoHotkey, but AutoHotkey_1.1.32.00_setup.exe, which is merely a standard 7-zip SFX binary (7zS2.sfx version 9.20) with a 7-zip archive appended via a batch script. I use a pre-built binary downloaded from the 7-zip website, but I believe the following is the most relevant part of the source code (this link is to a third-party mirror, for convenience): https://github.com/kornelski/7z/blob/9.20/C/Util/SfxSetup/SfxSetup.c
The assessment does not relate to the portable (zip) download, AutoHotkey.exe or compiled scripts; only the installer.
Both links show that there are currently zero antivirus detections, although the second link shows "malicious, Threat Score: 100/100", presumably due to the "malicious indicators" listed on that page.
Analysis of the malicious indicators
I believe the analysis by hybrid-analysis.com was completely automated, and puts too much weight on heuristics that are inconclusive in reality. However, the "GitHubAssessment" doesn't say much if anything about it, so this might not be particularly relevant.
"The input sample contains a known anti-VM trick" - I believe this is listed merely because the program (which is based on 7zS2.sfx version 9.20) uses the CPUID instruction. As far as I can find in the source code, it uses this only to identify the CPU, to select between two versions of a CRC calculation function, for optimization purposes. The so-called "anti-VM trick" appears to merely be that CPUID can be used to recognize that the program is running within a VM (something that reverse engineers would tend to do).
"Sample was identified as malicious by at least one Antivirus engine" - shows 4% and 2% detection, though the current detection rate appears to be 0%, which I would think should invalidate any past detections by those same engines.
"The analysis extracted a file that was identified as malicious" - It lists the exe and bin files, with 1-5% detection rates. All are, or were, false positives.
"The analysis spawned a process that was identified as malicious" - setup.exe, 5% detection rate. Again, false positive.
"Allocates virtual memory in a remote process" - "AutoHotkey_1.1.32.00_setup.exe" allocated memory in "%TEMP%\7z93896F94\WindowSpy.ahk"" - This makes zero sense. WindowSpy.ahk is clearly a text/script file extracted by the SFX, and not a remote process.
"Writes data to a remote process" - I'd like to know how they came up with this, given that the SFX has no access to WriteProcessMemory. It launches setup.exe via ShellExecuteEx or CreateProcess, than uses WaitForSingleObject and CloseHandle on the process handle. That is all. (Source code here.)
"Checks for a resource fork (ADS) file" - "setup.exe" checked file "C:" - No idea what it's talking about. "C:" isn't even a file.
"Contains ability to reboot/shutdown the operating system" - True, but irrelevant. AutoHotkey binaries import ExitWindowsEx for the purpose of the Shutdown command, which is not called by the installer.
As for the "suspicious indicators",
There are many "contains ability to x" indicators, based on the wealth of functions imported by AutoHotkey binaries and made available to scripts. Most of these are not used by setup.
"1.1.32.00" and "1.0.48.05" (version numbers) are suspected of being IP addresses.
Contacts "random domain names" such as subca.ocsp-certum.com - it doesn't. I assume that some OS component does this during verification of the digital signature, which uses a Certum-issued digital certificate.
Malicious URLs - all relating to certum.pl, and only 1-2% detection rate. Again, this comes from the digital certificates in the digital signature. How very ironic.
Indicators relating to Internet Explorer and cache settings are most likely caused merely by the use of a WebBrowser control for the GUI.
Imports "suspicious" APIs, such as GetTickCount and GetCommandLineW. To be fair, it is rated with 1/10 relevance.
But If we look closer to some of the names of the file, it refers to a hash with a high level of detection.
A close inspection of this link shows that it is a maliciously modified version of AutoHotkey setup, which writes a file named "svchost.exe" in addition to the normal lot. This malicious version of setup was likely created by modifying the 7-zip archive embedded in the installer (which is much less work than building it from source code). The wording "it refers to a hash with a high level of detection" is very misleading - the association is only in the opposite direction, as the malicious file is apparently a trojan based on the genuine setup file. The genuine setup file does not refer to the malicious file or its hash in any way.
It is trivial to create an installation (or self-extracting) package containing arbitrary files, such as someone else's product combined with malware. That someone has done it with AutoHotkey is unfortunate, but is no indication of a vulnerability. Any process with access to a 7-zip library could likely inject a file into the installer, but it seems more trivial to replace the file with a malicious one. Any file which a malicious process has write access to its equally vulnerable.
Their interpretation of this topic as "a similar issue" is debatable. All the topic demonstrates is that older versions of the product are also prone to antivirus detections (which we would argue are false positives). It does not demonstrate any kind of process injection vulnerability.
The problem is likely to be found in the overlay.
virustotal also shows the "overlay" tag, and a definition "overlay: The file contains an overlay, appended data at the end of the file, may be some additional malicious payload." So I presume "overlay" refers to the embedded 7-zip archive containing the installation data, but what's the "problem"?
Also note that this software uses a ShellExecuteEx which could allow local users to gain privilege (CVE-2014-1807).
CVE-2014-1807 is an old vulnerability in ShellExecuteEx:
An unpatched system is vulnerable to attack via an application which is specifically crafted to exploit it. Any such application would make use of ShellExecuteEx (or ShellExecute), therefore any application which makes use of ShellExecuteEx is hypothetically suspect. But in reality, the vulnerability referenced above has no relevance to AutoHotkey_1.1.32.00_setup.exe:
There is nothing in the assessment to indicate that '_setup.exe is using ShellExecuteEx in that manner.
'_setup.exe requires administrative privileges to run, and must be knowingly given such by the administrator unless circumvented by the "RunAsInvoker" compatibility patch. That would make no sense for an application which is crafted to exploit that vulnerability.
If the application was crafted to exploit that vulnerability, that would make the application itself malicious, not vulnerable.
Attributes that we can search for associated with the event of an insufficient buffer are: ...
This appears to be only a list of actions that malicious code might be able to take after triggering an exploit, not an observation of actions taken during the assessment, nor likely results of an API call returning ERROR_INSUFFICIENT_BUFFER. There is no other mention of "an insufficient buffer" or any explanation, only some screenshots of a debugger showing the ERROR_INSUFFICIENT_BUFFER error code. There is nothing in the screenshots to indicate which function returned the error code, or that it was even called by '_setup.exe. The current instruction address (EIP) shown appears to be within ntdll, but which function is not shown, and likely can't be identified without a copy of that specific version of ntdll.
The EAX register contains the entry point of AutoHotkey_1.1.32.00_setup.exe (the address of the first instruction that it executes), which at least proves that the process being debugged was the 7-zip SFX, not the setup script or AutoHotkey itself. As for why EAX would contain the entry point, the only plausible explanation I could think up is that the debugger has intercepted execution before the entry point, in which case the error wouldn't have been caused by setup itself, but by the debugger or some other part of process startup.
Some of the screenshots show disassembly of "code" containing invalid instructions at different addresses. No explanation is provided, but the presence and names of the files imply that these illegal instructions were thought to have some significance to the assessment. I believe they are irrelevant - if executed (which may be impossible), the illegal instructions would trigger an SEH exception and effectively terminate the process. They surely have nothing do with process injection.
One of the screenshots (Lock.png) shows code that isn't even part of '_setup.exe, but part of a system module, windows.storage.dll (abbreviated to windows_, and the base address is shown in DLL_Structure.png).
As for ERROR_INSUFFICIENT_BUFFER, the appearance of this error code does not imply a vulnerability. It is generally returned by a system function when the provided buffer was known to be too small for a return value, in which case the system function typically truncates the data in the buffer or leaves it undefined. In either case, there is no buffer overflow, and no inherent vulnerability if the return value is handled correctly. Some functions set this error code when they are called with a NULL buffer to determine the required buffer size (which would be normal operation of the function).
As far as I can tell, the only function used directly by '_setup.exe (7zS2.sfx) which is capable of setting this error is GetModuleFileNameW, but:
It uses a buffer of MAX_PATH (260) characters, meaning the path used to execute '_setup.exe would need to be 260 characters or greater.
I tested with a path of exactly 260 characters on Windows 10.0.19043, and although Explorer can display the file, it cannot show the icon or execute the file. Attempting to execute it with Run gives an immediate "The operation was canceled by the user" error.
It states that there is a "process injection" vulnerability, but does not explain what the vulnerability is or how it would be exploited. As far as I can tell, none of the factoids presented in the assessment constitute actual evidence of a vulnerability.
as i understood it, cves are purposefully light on details, so if u havent got any extra info theres not much to go on. the next step would be reverse engineering the exploit...(if we assume there in fact is one to begin with)
since hes talking about "a process injection vulnerability ... to escalate privileges", wouldnt that mean if the installer is currently running(or simply present, so it can then be launched) on a compromised system, malicious code can detect that, apply the exploit(process injection) and thus run itself(the malicious payload) as admin?
and ive just noticed theyve now scored it a 9.8 critical what a mess
anyhow, thanks for the thorough writeup
Re: Process injection vulnerability
Posted: 08 Aug 2021, 07:33
by lexikos
Putting aside the so-called "assessment", I have verified that there is a "vulnerability" in all 7zS2.sfx-based versions of the installer. The issue is that the files are extracted into a temporary location before execution, and that location is writable without administrator privileges. Therefore, a process running as the current user (regardless of administrator status) is able to modify setup.exe before it is executed (within the very small window between extraction and execution), or modify the AutoHotkey files before they are moved into the target installation directory.
If the system has been compromised, a malicious process which does not already have elevated privileges could gain them by utilizing this vulnerability, or could infect or replace the files installed by AutoHotkey setup.
If an administrator is running setup under the session of some other non-admin user, the non-admin user could exploit this vulnerability to effectively trick the administrator into elevating the privileges of (or installing into the target installation directory) some other file.
Note that any "exploit" must be carried out during the installation process, as the "vulnerability" relates only to the installer, not AutoHotkey itself.
Also note that if the current user has write permission to AutoHotkey_*_setup.exe, any process running as the current user could modify or replace it prior to execution. This is generally true for any executable file, regardless of what the executable file does when executed.
As I said before, this "process injection vulnerability" does not apply to the portable (zip) downloads. To install from zip, one may extract the files to a temporary location and run the Installer.ahk script, such as by drag-dropping it onto AutoHotkeyU32.exe (and then it will attempt to run as admin). However, note that extracting the files to a temporary location which is writable by standard users would defeat the purpose.
cves are purposefully light on details
The "CVE assessment" published on GitHub isn't light on details. It is full of irrelevant and misleading details.
Re: Process injection vulnerability
Posted: 08 Aug 2021, 14:59
by JoeWinograd
lexikos wrote:To install from zip, one may extract the files to a temporary location and run the Installer.ahk script
Good idea! I've always run the _setup.exe installer. Will switch to the ZIP file method from now on. Thanks, Joe
I would really like to use AutoHotkey at my company but IT sais we can't until this vulnerability is fixed.
The issue here is not that the AutoHotkey scripting language is a problem, but rather the computers of your company will need to have been already compromised by an exploit that NIST and the link to GitHub are not naming.
The real threat would be the exploit or compromised computer(s), which would allow the attacker to take advantage of many software applications, not just AutoHotkey setup.
As I attempted to explain above, the conclusion shown in the assessment appears to be based on false premises. It states that there is a "process injection" vulnerability, but does not explain what the vulnerability is or how it would be exploited. As far as I can tell, none of the factoids presented in the assessment constitute actual evidence of a vulnerability.
I agree about this. The information they are giving is not being helpful, but appears to be negatively tarring or making negative insinuations about AutoHotkey.
It then refers to a link by https://www.hybrid-analysis.com/, that says the AutoHotkey setup file is malicious. However, it is very confusing as to what they are referring to. They seem to be referring to fraudulent files of unknown origins as malicious (not just the AutoHotkey setup file) or that the AutoHotkey scripting language could be used maliciously. Which the latter assertion is totally ludicrous, as any programming language (JavaScript, Lua, C++, etc...) can create malicious programs.
It appears that they are conflating a computer compromised by an exploit and then fraudulent AutoHotkey setup files that comes from some unknown source with the valid AutoHotkey setup files that can be distinguished by hash, signature, and/or download source. The impression is then given that the legit AutoHotkey setup file is dangerous, as oppose to the (unnamed) exploit, fraudulent files (of unknown and unstated origin), dubious website sources (not specified), or that the vulnerability is unique to AutoHotkey.
lexikos wrote:To install from zip, one may extract the files to a temporary location and run the Installer.ahk script
joewinograd wrote:Good idea! I've always run the _setup.exe installer. Will switch to the ZIP file method from now on. Thanks, Joe
With the availability of 1.1.33.10, I just tried this for the first time...downloaded the AutoHotkey_1.1.33.10.zip file, unpacked it, ran Installer.ahk, but it says that the version is 1.1.33.09, not 1.1.33.10:
1.1.33.10 zip file contains 1.1.33.09 installer.png (20.83 KiB) Viewed 3966 times
I then downloaded AutoHotkey_1.1.33.10_setup.exe and it worked fine:
1.1.33.10 setup file.png (21.46 KiB) Viewed 3966 times
Regards, Joe
Re: Process injection vulnerability
Posted: 01 Sep 2021, 03:39
by lexikos
You should run Installer.ahk with the AutoHotkeyU32.exe provided in the download, not the AutoHotkey already installed on your system.