Process injection vulnerability

Report problems with documented functionality
User avatar
JoeWinograd
Posts: 2165
Joined: 10 Feb 2014, 20:00
Location: U.S. Central Time Zone

Process injection vulnerability

02 Aug 2021, 13:11

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
fivef
Posts: 1
Joined: 03 Aug 2021, 02:26

Re: Process injection vulnerability

04 Aug 2021, 03:34

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."?
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Process injection vulnerability

06 Aug 2021, 18:46

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.
User avatar
JoeWinograd
Posts: 2165
Joined: 10 Feb 2014, 20:00
Location: U.S. Central Time Zone

Re: Process injection vulnerability

06 Aug 2021, 20:14

Hi lexikos,
Thanks for that analysis...much appreciated! Regards, Joe
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Process injection vulnerability

07 Aug 2021, 03:09

@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...
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Process injection vulnerability

08 Aug 2021, 02:59

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
But If we look closer to some of the names of the file, it refers to a hash with a high level of detection.

Ex: fa0842f2292240e5405af9e2d03177ce40335b3d94e881305ce9b43c1eeb02a8 https://www.virustotal.com/gui/file/fa0842f2292240e5405af9e2d03177ce40335b3d94e881305ce9b43c1eeb02a8/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.
A similar issue was previously observed in older versions of this product: https://www.autohotkey.com/boards/viewtopic.php?t=13985
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:
The vulnerability could allow elevation of privilege if an attacker runs a specially crafted application that uses ShellExecute.
Source: Microsoft Security Bulletin MS14-027 - Important | Microsoft Docs
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:
  1. There is nothing in the assessment to indicate that '_setup.exe is using ShellExecuteEx in that manner.
  2. '_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.
  3. 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.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: Process injection vulnerability

08 Aug 2021, 06:45

lexikos wrote:
08 Aug 2021, 02:59
No, the first I heard of it was via this topic.
well, that sucks
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 :facepalm: what a mess

anyhow, thanks for the thorough writeup
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Process injection vulnerability

08 Aug 2021, 07:33

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.
User avatar
JoeWinograd
Posts: 2165
Joined: 10 Feb 2014, 20:00
Location: U.S. Central Time Zone

Re: Process injection vulnerability

08 Aug 2021, 14:59

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
SOTE
Posts: 1426
Joined: 15 Jun 2015, 06:21

Re: Process injection vulnerability

09 Aug 2021, 05:00

fivef wrote:
04 Aug 2021, 03:34
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.
lexikos wrote:
08 Aug 2021, 02:59
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.

The GitHub (https://github.com/GitHubAssessments/CVE_Assessments_02_2020) refers to a link, where AutoHotkey is 100% clean (0 detections), https://www.virustotal.com/gui/file/ce505d272f8d36c5599ac81f005e1d2d586eeaaa778c779ad858e44fdadfdb0d/details.

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.

I think people have to contact NIST (https://www.nist.gov/about-nist/contact-us) or contact CrowdStrike ([email protected]), who appears to be the owner of Hybrid-Analysis (https://www.hybrid-analysis.com/). It looks like they need to make corrections to what they are posting for clarity and provide proper details.
User avatar
JoeWinograd
Posts: 2165
Joined: 10 Feb 2014, 20:00
Location: U.S. Central Time Zone

Re: Process injection vulnerability

29 Aug 2021, 12:54

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
1.1.33.10 zip file contains 1.1.33.09 installer.png (20.83 KiB) Viewed 3689 times


I then downloaded AutoHotkey_1.1.33.10_setup.exe and it worked fine:

1.1.33.10 setup file.png
1.1.33.10 setup file.png (21.46 KiB) Viewed 3689 times

Regards, Joe
lexikos
Posts: 9494
Joined: 30 Sep 2013, 04:07
Contact:

Re: Process injection vulnerability

01 Sep 2021, 03:39

You should run Installer.ahk with the AutoHotkeyU32.exe provided in the download, not the AutoHotkey already installed on your system.
User avatar
JoeWinograd
Posts: 2165
Joined: 10 Feb 2014, 20:00
Location: U.S. Central Time Zone

Re: Process injection vulnerability

01 Sep 2021, 07:05

lexikos wrote:
01 Sep 2021, 03:39
You should run Installer.ahk with the AutoHotkeyU32.exe provided in the download, not the AutoHotkey already installed on your system.
Ah, got it...worked perfectly! Thanks much, Joe

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 17 guests