Vulnerability summary: Local Privilege Escalation from regular user to SYSTEM, 
via conhost.exe hijacking triggered by MSI installer in repair mode
Affected Products: Intel PowerGadget
Affected Versions: tested on PowerGadget_3.6.msi 
(a3834b2559c18e6797ba945d685bf174), file signed on ‎Monday, ‎February ‎1, ‎2021 
9:43:20 PM (this seems to be the latest version), earlier versions might be 
affected as well.
Affected Platforms: Windows
Common Vulnerability Scoring System (CVSS) Base Score (CVSSv3): 7.8 HIGH
Risk score (CVSSv3): 7.8 HIGH AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H 

I have reported this issue to Intel, but since the product has been marked End 
of Life since October 2023, it is not going to receive a security update nor a 
security advisory. Intel said that they are OK with me making this finding 
public, under the condition that I would emphasize that the product is EOL.

Description and steps to replicate:
On systems where Intel PowerGadget is installed from an MSI package, a local 
interactive regular user is able to run the MSI installer file in the "repair" 
mode and hijack the conhost.exe process (which is created by an instance of 
sc.exe the installer calls during the process) by quickly left-clicking on the 
console window that pops up for a split second in the late stage of the 
process. Left-clicking on the conhost.exe console window area freezes the 
console (meaning it prevents the sc.exe process from exiting). That process is 
running as NT AUTHORITY/SYSTEM. From there, it is possible to run a web browser 
by clicking on one of the links in the small GUI window that can be called by 
right-clicking on the console window bar and entering "properties". Once a web 
browser is spawn, attacker can call up the "Open" dialog and in that way get a 
fully working escape to explorer. From there they can, for example, browse 
through C:\Windows\System32 and right-click on cmd.exe and run it, obtaining as 
SYSTEM shell.

Now - an important detail - on most recent builds of Windows neither Edge nor 
Internet Explorer will spawn as SYSTEM (this is a mitigation from Microsoft); 
thus for successful exploitation another browser has to already be present in 
the system. As you can see I pick Chrome and then spawn an instance of cmd.exe, 
which turns out to be running as SYSTEM. Also, when doing this, DO NOT check 
"always use this app" in that dialog, as if you pick the wrong one (e.g. Edge 
or IE), it will be saved as the default http/https handler for SYSTEM and from 
then further attacks like this won't work if you want to repeat the POC - 
unless you reverse that change somewhere in the registry.

This class of Local Privilege Escalations is described by Mandiant in this 

To run the installer in repair mode, one needs to identify the proper MSI file. 
After normal installation, it is by default present in C:\Windows\Installer 
directory, under a random name. The proper file can be identified by attributes 
like control sum, size or "author" information.
The exploitation process is illustrated in the screenshots below, reflecting 
the the steps taken to attain a SYSTEM shell (no exploit development is 
required, the issue can be exploited using GUI).

Technically, as per the reference, it is recommended to change the way the 
sc.exe is called, using the WixQuietExec() method (see the second reference). 
In such case the conhost.exe window will not be visible to the user, thus 
making it impossible to perform any GUI interaction and an escape.
I am, however, aware that this product is no longer maintained since October 
 and that includes security updates. Still, I believe a security advisory and 
CVE should be released just to make users and administrators aware why they 
need to replace PowerGadget with Intel Performance Counter Monitor.
Another possible (short-term) mitigation is to disable MSI 

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Reply via email to