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
| ||
|
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: [FD] 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 _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Powered by blists - more mailing lists