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