Hi @ll,

the following is a shortened version of
<https://skanthak.homepage.t-online.de/tempest.html>

With Windows 10 20H1, Microsoft moved the function to install and update
device drivers available online, i.e. on Windows Update, from Device Manager
to Windows Update.

Device Manager runs under arbitrary "Administrator" accounts: device driver
installation started from its GUI (MMC.exe DevMgmt.msc) or CLI (PnPUtil.exe,
DrvInst.exe, ...) is performed synchronous and runs under the "Administrator"
account too.
Administrator (and user) accounts have a PRIVATE TMP directory, located in
their user profile under the path %USERPROFILE%\AppData\Local\Temp\, which
is NOT accessible from other (unprivileged) users accounts.

JFTR: in standard installations of Windows, with a UAC-controlled
      "Administrator" account, the vulnerability reported here allows an
      UAC-bypass.

Windows Update on the other hand uses a client/server model: device driver
installation started from its GUI is handed off to the server process which
runs under the "LocalSystem" alias "SYSTEM" account.
This high privileged account but uses the SHARED TMP directory
%SystemRoot%\Temp\, which is writable from UNPRIVILEGED user accounts.

Quite some device drivers (not just those available on Windows Update)
contain secondary components (so-called satellites) with own/independent
(executable) installers which are executed in the course of the device
driver installation.
Many, if not most of these installers are self-extractors which use the
process' TMP directory to unpack files and even execute them there.

The resulting well-known weaknesses are classified as
- CWE-377: Insecure Temporary File
  <https://cwe.mitre.org/data/definitions/377.html>
- CWE-379: Creation of Temporary File in Directory with Incorrect Permissions
  <https://cwe.mitre.org/data/definitions/379.html>

In the latter case, the TMP directory becomes the "application directory"
for the respective process and may become its "current working directory"
too.
The "application directory" is the first directory in the DLL and process
search path, and the "current working directory" is the first directory
in the command processor's search path.
See <https://msdn.microsoft.com/en-us/library/ms684175.aspx>,
<https://msdn.microsoft.com/en-us/library/ms682425.aspx> and
<https://msdn.microsoft.com/en-us/library/ms684269.aspx> for reference.

The resulting well-known weaknesses are classified as
- CWE-426: Untrusted Search Path
  <https://cwe.mitre.org/data/definitions/426.html>
- CWE-427: Uncontrolled Search Path Element
  <https://cwe.mitre.org/data/definitions/427.html>,
while the well-known attack is classified as
- CAPEC-471: Search Order Hijacking
  <https://capec.mitre.org/data/definitions/471.html>

Several device drivers for NVIDIA graphics cards available on Windows
Update, for example
<https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=03e795cf-1ebc-4d35-9c28-080f89f6b922>,
write a vulnerable NvStInst.exe to %SystemRoot%\Temp and execute it there;
NvStInst.exe loads at least ShFolder.dll from its "application directory"
instead from Windows' "system directory" %SystemRoot%\System32

JFTR: Microsoft wrote plenty of guidance, for example
      <https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>,
      <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
      <https://technet.microsoft.com/en-us/library/2269637.aspx>,
      <https://support.microsoft.com/en-us/kb/2389418>,
      <https://support.microsoft.com/en-us/kb/2533623>, but neither
      NVIDIA nor their own WHQL-certification follow suit!

Since unprivileged users can create %SystemRoot%\Temp\ShFolder.dll and
%SystemRoot%\Temp\NvStInst.exe runs under the SYSTEM account this
vulnerability results in escalation of privilege: GAME OVER!

stay tuned, and far away from executable installers
Stefan Kanthak

PS: the response from NVIDIA was: driver is end-of-life

PPS: the response from Microsoft was:

| We're experimenting with ways to mitigate this issue in future
| versions of Windows (https://aka.ms/flighthub). Unfortunately,
| these mitigations are infeasible on existing Windows versions
| because they introduce application compatibility issues.
| [...] even a limited mitigation would still introduce application
| compatibility issues and would not even address all instances of
| the TEMP issue across all third-party drivers (e.g., third-party
| drivers that had hardcoded C:\Windows\Temp, though we don't
| believe that that's the case with this specific driver).