bugtraq - Defense in depth -- the Microsoft way (part 53): our MSRC doesn't know how Windows handles PATH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <413A2115D366462AB55CBD8224400035@W340>
Date: Mon, 9 Apr 2018 19:40:53 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: <fulldisclosure@...lists.org>
Subject: Defense in depth -- the Microsoft way (part 53): our MSRC doesn't know how Windows handles PATH

Hi @ll,

on their "Security Research & Defense" blog, members of Microsoft's
Security Response Center recently posted 
<https://blogs.technet.microsoft.com/srd/2018/04/04/triaging-a-dll-planting-vulnerability/>

This blog post but clearly shows that the MSRC doesn't know how Windows
handles the PATH!

Error #1
~~~~~~~~

| The directories that are in the PATH environment variable are always
| admin ACLed and a normal user can't modify contents of these directories.
...
| What Microsoft won't address (not a vulnerability)
| PATH directory scenarios - Since there can't be a non-admin directory in
| the PATH this can't be exploited.

OUCH!

The user can modify the PATH environment variable as s/he likes and add
arbitrary directories!

1) Start a command prompt, then run the following commands:

   MKDIR "%SystemDrive%\fubar"
   PATH %SystemDrive%\fubar;%PATH%
   START %ComSpec% /K PATH

2) The PATH environment variable is built during user logon from the
   system's PATH, stored in the registry entry
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
      "PATH"=expand:"%SystemRoot%\\System32;%SystemRoot%;%SystemRoot%\\System32\\WBEM;..."
   plus the user's PATH, stored in the registry entry
      [HKEY_CURRENT_USER\Environment]
      "PATH"=expand:"<arbitrary directory>;..."

   To add one or more arbitrary user-controlled directories to this
   persistent PATH, set the latter registry entry, for example via
   control panel.
   When a user does this, control panel broadcasts a WM_SETTINGCHANGE
   to all applications.
   Especially Windows' File Explorer (the "shell") rebuilds the PATH
   environment variable upon receiving this broadcast!

3) To add one or more arbitrary user-controlled directories to an
   applications <filename.exe> PATH, create the registry entry
      [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths\<filename.exe>]
      "PATH"="<arbitrary directory>;..."

   See <https://msdn.microsoft.com/en-us/library/ee872121.aspx>

Error #2
~~~~~~~~

| 6. The directories that are listed in the PATH environment variable.
|    Note that this does not include the per-application path specified
|    by the App Paths registry key. The App Paths key is not used when
|    computing the DLL search path.

OUCH!

The per-application path stored beneath the "App Paths" registry key is
prepended (NT 5.x and below) or appended (NT 6.x and above) to the PATH
environment variable when an application is started via one of the
ShellExecute*() functions.

Error #3
~~~~~~~~

| DLL planting issues that fall into the category of PATH directories
| DLL planting are treated as won't fix.

OUCH!

The MSRC also ignores the fact that
    CHDIR "<arbitrary directory>"
    START <application>
is equivalent to adding "<arbitrary directory>" in front of the PATH!

JFTR: loading of DLLs from the CWD can be disabled via
        [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
        "CWDIllegalInDllSearch"=dword:ffffffff
      (see <https://support.microsoft.com/en-us/help/2264107>)

stay tuned
Stefan Kanthak