BugTraq
[CVE-2018-3667, CVE-2018-3668] Escalation of priviilege via executable installer of Intel Processor Diagnostic Tool Jul 04 2018 09:14AM
Stefan Kanthak (stefan kanthak nexgo de)
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 (at) intel (dot) com [email concealed]>

no reply, not even an acknowledgement of receipt

2018-04-05 resent vulnerability report to <secure (at) intel (dot) com [email concealed]>,
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.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus