Me, myself & IT

Stop malware with Software Restriction Policies alias SAFER

Bug

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"SafeModeBlockNonAdmins"=dword:00000001 ; Disable 'Standard Users' in 'Safe Mode'

Purpose

This technique is known as Application Whitelisting; the setup scripts presented here perform a rather permissive implementation: they allow execution of all applications which are properly installed by an administrator.

Note: the MSDN article Security Considerations: Microsoft Windows Shell gives details for proper installation.

Reason

Unlike unreliable, unsafe and vulnerable antivirus software which almost always fails to detect new or unknown malware (ransomware, trojan horses, viruses, worms, …), known as false negative, or misdetect legitimate clean software as malware, known as false positive, this method effectively stops all kinds of known as well as new or unknown malware and all other unwanted or unauthorised software that uses executable files to infest Windows NT installations, while allowing all legitimate software to run!

Impact

• are still able to download arbitrary (executable) files from arbitrary web sites, to receive arbitrary (executable) files as attachments of mails, etc. and store them anywhere they are allowed to write files, but they can’t execute these files any more;
• can execute all Win32 applications that meet the minimum requirements of the more than 20 year old Designed for Windows specification, i.e. have their executable files installed beneath the directories %ProgramFiles%\ or %SystemRoot%\;
• can’t execute applications installed in their User Profiles, stored on external, portable or removable devices and media, or on other computers;
• can open all files with any application installed on their machines by their administrators, i.e. they can work with all their documents and all local applications without any restriction.

Warning: some imbeciles who don’t recognise the simple word data in %ProgramData% alias C:\ProgramData, in %APPDATA% alias C:\Users\‹username›\AppData\Roaming, or in %LOCALAPPDATA% alias C:\Users\‹username›\AppData\Local, and are unable to realise its meaning install but executable files below these directories!
For a recent demonstration of such incompetence, see the MSKB article 4052623.

Note: the exemption of privileged users from Software Restriction Policies leaves no loophole!
Privileged users can write files in the directories where execution is allowed, can disable or remove Software Restriction Policies and can thus execute any file.

If you want or need to restrict administrators too, use the setup scripts NT6_SUPER.INF (for all editions of Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2) or XP_SUPER.INF (for all editions of Windows XP, Windows Server 2003 and Windows Server 2003 R2).

Caveat: on Windows Vista and newer versions of Windows NT, all SAFER security levels except Unrestricted alias Fully trusted are equivalent to Disallowed and deny execution!

Note: user accounts created during Windows NT setup are but privileged user administrator accounts!
Change their account type to Standard User (on Windows Vista and newer versions of Windows NT) or Limited User (on Windows XP, Windows Server 2003 and Windows Server 2003 R2) respectively if you use them for your routine work!

Change a user’s account type:

When you set up Windows, you were required to create a user account. This account is an administrator account that allows you to set up your computer and install any programs that you'd like to use. Once you finish setting up your computer, we recommend that you create a standard account and use it for your everyday computing. If you create new user accounts, you should also make them standard accounts. Using standard accounts will help keep your computer more secure.

Note: the dumb User Accounts control panel applet denies to demote the last or only privileged user account even if the builtin (real) Administrator account has been activated!
Use the real User Accounts control panel applet instead: to start it, run one of the equivalent command lines

"%SystemRoot%\System32\Control.exe" UserPasswords2
"%SystemRoot%\System32\RunDLL32.exe" "%SystemRoot%\System32\NetPlWiz.dll",UsersRunDll

Caveat: don’t forget to enable the builtin Administrator account!
Run the command line

"%SystemRoot%\System32\Net.exe" User Administrator /Active:Yes

Caveat: Windows 10 has the nasty habit to disable the builtin Administrator account during updates and upgrades!

Note: the (predefined) privileged user account NT AUTHORITY\SYSTEM alias LocalSystem is always exempt from Software Restriction Policies; the (predefined) unprivileged user accounts NT AUTHORITY\LocalService alias LocalService and NT AUTHORITY\NetworkService alias NetworkService are but subject to them!

Operation

For executable files except DLLs, one of the messages shown above is displayed and an entry 865, 866, 867, 868 or 882 from source Software Restriction Policies (on Windows XP, Windows Server 2003 and Windows Server 2003 R2) or Microsoft-Windows-SoftwareRestrictionPolicies (on Windows Vista and newer versions of Windows NT) is written to the Event Log.
For Windows Installer packages, patches and transformations, one of the messages shown above is displayed and an entry 1007 or 1008 from source MsiInstaller is written to the Event Log.

To retrieve these entries from the Event Log, start a Command Prompt and run (one or more of) the following command lines:

"%SystemRoot%\System32\WBEM\WMIC.exe" NTEvent Where "EventCode='865' Or EventCode='866' Or EventCode='867' Or EventCode='868' Or EventCode='882'" Get /Value
"%SystemRoot%\System32\WBEM\WMIC.exe" NTEvent Where "SourceName='Software Restriction Policies'" Get /Value
"%SystemRoot%\System32\WBEM\WMIC.exe" NTEvent Where "SourceName='Microsoft-Windows-SoftwareRestrictionPolicies'" Get /Value
"%SystemRoot%\System32\WBEM\WMIC.exe" NTEvent Where "(EventCode='1007' Or EventCode='1008') And SourceName='MsiInstaller'" Get /Value

Advanced Logging

The NTFS access rights of the directories %SystemRoot%\Debug\ and %SystemRoot%\System32\LogFiles\ allow only privileged users (NT AUTHORITY\SYSTEM and BUILTIN\Administrators) to create the file %SystemRoot%\Debug\SAFER.log or %SystemRoot%\System32\LogFiles\SAFER.log respectively.
The file’s inherited access rights also allow only privileged users to write, but unprivileged users (BUILTIN\Users) to read.

On Windows Vista and newer versions of Windows NT, file and directory operations of 32-bit applications run by unprivileged users which fail due to missing write access rights in %SystemRoot%\ and below as well as %ProgramFiles%\ and below, on 64-bit editions also %ProgramFiles(x86)%\ and below, are redirected to the directory %LOCALAPPDATA%\VirtualStore\, resulting in %LOCALAPPDATA%\VirtualStore\Windows\System32\LogFiles\SAFER.log.

Caveat: the files SAFER.log can grow quite large!
Note: they can be cleared or erased any time.

Availability and Vulnerability

Note: their successor AppLocker is available on Ultimate and Enterprise editions of Windows 7 and newer versions of Windows NT only, while Device Guard is available on Enterprise editions of Windows 10 only.

Unlike antivirus or other so-called security software which is often typically vulnerable itself, Software Restriction Policies introduce no additional code which allows to leverage successful attacks in the first place!

Some, but not all (now fixed) vulnerabilities in Microsoft^®’s anti-malware products for consumers are documented in the MSKB articles 932135, 952044, 2823482, 2847927 and 3074162, the Security Advisories 2491888, 2846338, 2974294, 3074162 and 4022344, plus the Security Bulletins MS07-010, MS08-029, MS13-034 and MS13-058.

The additional updates to harden the anti-malware products for consumers are documented in the MSKB articles 2781197, 2856373, 2883200, 2894853, 2939153, 2976536 and 3025417.

Note: so-called security products of other vendors are equally bad or even worse!

Analysis and Exploitation of an ESET Vulnerability:

Do we understand the risk vs. benefit trade-offs of security software?
Tavis Ormandy, June 2015
[…]
Attackers can cause I/O via Web Browsers, Email, IM, file sharing, network storage, USB, or hundreds of other vectors. Whenever a message, file, image or other data is received, it’s likely some untrusted data passes through the disk. Because it’s so easy for attackers to trigger emulation of untrusted code, it’s critically important that the emulator is robust and isolated.

Unfortunately, analysis of ESET emulation reveals that is not the case and it can be trivially compromised.

Because antivirus products typically intercept filesystem and network traffic, simply visiting a website or receiving an email is sufficient for exploitation. It is not necessary to open or read the email, as the filesystem I/O from receiving the email is sufficient to trigger the exploitable condition.
[…]
Product Design Flaws

I've also reported some major design flaws in various other components of Kaspersky Antivirus and Kaspersky Internet Security. The patches for the remote network attacks I had planned to discuss here were delayed, and so I'll talk about them in a second post on this topic once the fixes are live.

Security Software Considered Harmful?

We have strong evidence that an active black market trade in antivirus exploits exists. Research shows that it’s an easily accessible attack surface that dramatically increases exposure to targeted attacks.

Today we're publishing details of multiple critical vulnerabilities that we discovered, including many wormable remote code execution flaws.

These vulnerabilities are as bad as it gets. They don’t require any user interaction, they affect the default configuration, and the software runs at the highest privilege levels possible. In certain cases on Windows, vulnerable code is even loaded into the kernel, resulting in remote kernel memory corruption.

Reliability and Safety

On the right, the screenshot of a message box shows antivirus software that has been disabled by malware (ab)using Software Restriction Policies, i.e. this antivirus software was even unable to protect itself!

Note: Self-Protection for Antivirus Software gives an overview!

Trend Micro: Antivirus industry lied for 20 years:

In the antivirus business, we have been lying to customers for 20 years. People thought that virus protection protected them, but we can never block all viruses. Antivirus refresh used to be every 24 hours. People would usually get infected in that time and the industry would clean them up with a new pattern file.
In the last 20 years, we have been misrepresenting ourselves. No-one is able to detect five and a half million viruses. Nowadays there are no mass virus outbreaks; [malware] is targeted. But, if there are no virus samples submitted, there’s no way to detect them.

The best kind of desktop is a secure desktop. As you all know, hackers are a tricky bunch. You have to go beyond Symantec Antivirus and actually lock Windows down if you want to make sure your computing environment is actually secure.

For example, application whitelisting on end-user devices stops advanced and zero day attacks from infecting the system by preventing unauthorised code execution, protecting memory, and blocking attempts to exploit a whitelisted app before it gains a foothold and impacts the business. Application whitelisting is listed as a Quick Win in the SANS Critical Security Controls list and the Australian Government Top 4 Mitigating Controls cybersecurity guidance. According to Australian Signals Directorate Deputy Director Steve Day, attackers have not stolen any sensitive data from government networks because of their adoption of the Top 4 mitigating controls.

But there are very effective protections that you can put in place, and they need not require new investment in technology or personnel. The Australian Defence Signals Directorate (DSD) has published guidance on the top 35 strategies to mitigate against targeted cyber intrusion and concluded that at least 85 % of the intrusions they responded to in 2011 and 2012 would have been prevented if only the top four of these mitigations had been in place.
These top four mitigations only require organizations to employ application whitelisting technology, maintain current, patched applications and operating systems and effectively restrict the use of administrative accounts.

Interoperability

One of the common misconceptions about UAC and about Same-desktop Elevation in particular is that it prevents malware from being installed or from gaining administrative rights. First, malware can be written not to require administrative rights, and malware can be written to write just to areas in the user’s profile. More important, Same-desktop Elevation in UAC is not a security boundary and can be hijacked by unprivileged software that runs on the same desktop. Same-desktop Elevation should be considered a convenience feature, and from a security perspective, "Protected Administrator" should be considered the equivalent of "Administrator." By contrast, using Fast User Switching to log on to a different session by using an administrator account involves a security boundary between the administrator account and the standard user session.

One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, […]
The most effective way to secure a system against malware is to run with standard user privileges.

[…] the primary purpose of elevation is not security, though, it’s convenience: […]

[…] this is also where we run into some of the limitations of UAC. Remember, there is no effective isolation; there is no security boundary that isolates processes on the same desktop.

It’s important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can’t access the data belonging to another user without having that user’s permission.

Note: on Windows 7 and newer versions of Windows NT, with default settings UAC performs silent (automatic) elevation for programs that

• have the autoElevate property set in their embedded application manifest,
• are digitally signed by Microsoft with the Windows Publisher code signing certificate, and
• are stored in secure locations like %SystemRoot%\ and its subdirectories.

See UAC-a-mole for some examples, their exploits and the mitigations.

To prevent the silent (automatic) elevation, set UAC to its highest level Always notify; to prevent any bypass, use a Standard User account and disable elevation requests there:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000002 ; Prompt for consent on the secure desktop
"ConsentPromptBehaviorUser"=dword:00000000  ; Automatically deny elevation requests

Note: according to numbers published by Microsoft in their Security Intelligence Reports, about ½ to ¾ of all (some 600 million) Windows NT installations engaged in their malware telemetry reported only a single active user account.

Google’s Project Zero reported several bugs which allow to bypass UAC that Microsoft won’t fix: Issue 156 and Issue 220.

Also note that in combination with UAC Windows Explorer shows surprising and dangerous behaviour (documented in the MSKB article When you click Continue for folder access in Windows Explorer, your user account is added to the ACL for the folder) which generally impairs security and safety!

To detect directories with additional NTFS ACL entries created by Windows Explorer as well as (writable) files eventually created in these directories from your user account, start a Command Prompt, run the following command lines and inspect their output, then remove the additional NTFS ACL entries:

"%SystemRoot%\System32\ICACLs.exe" "%SystemRoot%\*" /FindSID "%USERNAME%" /C /T
"%SystemRoot%\System32\ICACLs.exe" "%ProgramFiles%\*" /FindSID "%USERNAME%" /C /T
"%SystemRoot%\System32\ICACLs.exe" "%ProgramFiles(x86)%\*" /FindSID "%USERNAME%" /C /T
"%SystemRoot%\System32\ICACLs.exe" "%ProgramData%\*" /FindSID "%USERNAME%" /C /T

"%SystemRoot%\System32\Attrib.exe" +H +S "‹directory›"

Prerequisites

• APPCERT.DLL must be installed on all versions of Windows NT to prevent circumvention of Software Restriction Policies!

• On Windows 7 and Windows Server 2008 R2, the hotfix 2532445, the hotfix 2894252, or the convenience rollup update 3125574 must be installed to prevent circumvention of Software Restriction Policies!

• On Windows 7, Windows Server 2008 R2 and newer versions of Windows NT, the optional update 977542 should be installed and the Registry entry

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
  "SafeModeBlockNonAdmins"=dword:00000001 ; Disable 'Standard Users' in 'Safe Mode'

  should be created to prevent unprivileged users to log on in Safe Mode.

• On Windows Vista and Windows Server 2008, the optional update 969972 or one of the optional updates 2257986, 2414106 or 2812950 which contain a newer version of the file replaced by 969972 should be installed!

• On Windows Server 2003 and Windows Server 2003 R2, the optional update 973825 should be installed!

• On systems with AMD64 alias x64 processor architecture running Windows XP, Windows Server 2003 or Windows Server 2003 R2, the optional update 942589 must be installed to enable the special directory pathname %SystemRoot%\SysNative!

Limitations and Dependencies

• On Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Embedded POSReady 2009, Windows Embedded Standard 2009, Windows Vista and Windows Server 2008 Software Restriction Policies can be bypassed: the hotfixes 2532445 and 2894252 are not available for these versions of Windows NT!

  Note: an adversary must be able to call the Win32 function LoadLibraryEx() to exercise this bypass.

  Since Software Restriction Policies block the direct execution of Win32 applications an adversary has to find a way to run code inside one of the trusted Win32 applications installed on a victims computer, which typically means to (ab)use a vulnerability in these applications and compromise them.

• Software Restriction Policies control the execution of
  • Win32 applications loaded via the Win32 functions CreateProcess(), CreateProcessAsUser(), CreateProcessWithLogonW(), CreateProcessWithTokenW(), LoadModule() and WinExec(), independent of their file extension,
  • DLLs loaded via the Win32 functions LoadLibrary(), LoadLibraryEx() and LoadPackagedLibrary(), independent of their file extension,
  • files launched via the Win32 functions ShellExecute() and ShellExecuteEx(), depending on their file extension,
  i.e. all Win32 functions that load and execute Win32 binary executables or open files for execution.

• Unless disabled with the Registry entry

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings]
  "UseWINSAFER"="0"

  Software Restriction Policies control the execution of scripts interpreted and run by the Windows Script Host, independent of their file extension.

• Software Restriction Policies control the installation of Windows Installer packages and patches.

• Software Restriction Policies don’t control the execution of MS DOS and 16-bit Windows applications: these run inside the NTVDM alias WOWEXEC subsystem, available only on systems with I386 alias x86 processor architecture.

  To disable the NTVDM and the WOWEXEC subsystem, set the Registry entry

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat]
  "VDMDisallowed"=dword:00000001

  as documented in the Security Advisory 979682 and the Security Bulletin MS13-063, plus the Registry entry

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WoW]
  "DisallowedPolicyDefault"=dword:00000001

  as documented in the Security Bulletin MS10-098.

• Software Restriction Policies don’t control the execution of OS/2 or POSIX applications: these run inside their own optional and separate OS/2 or POSIX subsystem, either SFU (available for Windows XP and Windows Server 2003) or SUA (available for or included as Optional Component in Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8 and Windows Server 2012, but deprecated).

• Software Restriction Policies don’t control the interpretation and execution of code, macros or scripts inside Win32 applications unless these explicitly call the Win32 functions that implement SAFER:

  • the Windows Script Component Runtime, implemented in SCRObj.dll, called for example via RegSvr32.exe, can run arbitrary Windows Script Components alias Scriptlets, i.e. COM objects written in JScript, VBScript or any other scripting language supported by an installed Windows Script Engine;
  • PowerShell can run arbitrary scripts from its command line, can call arbitrary methods of the .NET runtime, can call arbitrary Win32 functions, can instantiate and call arbitrary COM objects;
  • a Java runtime engine can run arbitrary applets;
  • an Office Suite can run arbitrary macros;
  • a WWW browser, a Mail client, an Instant Messenger or a PDF viewer can run arbitrary JavaScript;
  • a Flash Player can run arbitrary ActionScript;
  • …
  Note: use the policies and settings of the respective host application to control its execution behaviour!
  For Internet Explorer for example, the MSKB articles 883256 and 915729 document how to disable execution of scripts.

Details

• Win32 binary executables, i.e. applications and DLLs, independent of their file extension, typically .EXE, .DLL, .SYS, .SCR, .CPL, .OCX, .IME, .MUI, .AX, .ACM, .VCM, .TSP, .RLL, .WLL, .XLL, .COM, .EFI, …;
• packages, patches and transformations for the Windows Installer, previously known as Microsoft Installer (.MSI, .MSP and .MST);
• setup scripts (.INF);
• batch scripts (.BAT and .CMD);
• scripts for the Windows Script Host, independent of their file extension, typically .JS, .JSE, .VB, .VBS, .VBE, .WSC, .WSF, .WSH, …;
• HTML applications (.HTA and .HTC);
• …

Caveat: the Local Security Policy snap-in reads the additional SAFER rules only from the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol, not from the Registry: additional SAFER rules written directly or only to the Registry therefore don’t show in the Local Security Policy snap-in!

If this file exists modifications of the SAFER settings or rules written directly or only to the Registry will (periodically) be overwritten with the SAFER settings and rules from the file!

If this file contains neither SAFER settings nor rules (or does not exist) the Local Security Policy snap-in (creates it and) writes the default SAFER settings and rules to the file and to the Registry, thereby overwriting existing SAFER settings and rules in the Registry!
To avoid this either run the program SRP2LGPO.EXE (available upon request) once to export all SAFER settings and rules from the Registry to the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol or download the (empty) REGISTRY.POL that contains the (missing) setting

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"Levels"=dword:00071000

Note: if the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol is hidden the Local Security Policy snap-in fails and displays a (bogus) error message access denied when applying changes!

Background Information

More than 15 years ago Microsoft introduced Software Restriction Policies alias SAFER and published the MSDN articles
Using Software Restriction Policies to Protect Against Unauthorized Software,
How Software Restriction Policies Work and
Using Software Restriction Policies to Protect Against Unauthorized Software. �

Note: � � � �: �

From Strategies to Mitigate Cyber Security Incidents:

At least 85 % of the adversary techniques used in targeted cyber intrusions which ASD has visibility of could be mitigated by implementing the following mitigation strategies, referred to as the 'Top 4':
• use application whitelisting to help prevent malicious software and unapproved programs from running
[…]

From NCSC Applocker Guidance:

Application whitelisting is one of the best available protections against malware.

More than 12 years ago Microsoft introduced DEP alias W^X and enabled it by default.

� �

But even today all (data) files created in the User Profiles, the %PUBLIC%\, %ProgramData%\ and almost all other data directories too are still executable: although not needed the (inheritable) NTFS ACLs of all these directories include Execution permission for files!
And Software Restriction Policies are still not enabled by default! � �

The immediate benefit of an NTFS ACL without Execution permission or the default SAFER ruleset is: no (unintended) execution of files like invoice.pdf.exe etc. stored in data directories, so spreading malware to Windows NT systems becomes utterly useless.

If you want to try DEP in the NTFS filesystem for yourself choose one of the following:

• Add the NTFS ACL entry (D;OIIO;WP;;;WD) meaning deny execution of files in this directory for everyone, inheritable to all files in all subdirectories for your own %USERPROFILE% directory (or all of them plus %ALLUSERSPROFILE% alias %ProgramData% and %PUBLIC% if you have administrative privileges).

  Note: deny ACL entries have precedence over allow ACL entries.

• Enable the default SAFER ruleset which allows execution (of *.exe) only in the directories %SystemRoot%\ and %SystemRoot%\System32\ and all executable files in the directory %ProgramFiles%\ and below.

  Note: this ruleset leaves many loopholes!

  For systems with AMD64 alias x64 processor architecture you'll have to add rules for %SystemRoot%\SysWoW64\*.exe and %SystemRoot%\Sysnative\*.exe as well as %ProgramFiles(x86)%\

• Follow the step-by-step instructions presented on How to make a disallowed-by-default Software Restriction Policy.

  Note: these instructions let Windows Apps (which were introduced with Windows 8) fail and leave multiple loopholes!

• Download and install the setup script XP_SAFER.INF (for Windows XP, including embedded editions, Windows Server 2003 and Windows Server 2003 R2), NT6_SAFER.INF (for Windows Vista and Windows 7 as well as Windows Server 2008 and Windows Server 2008 R2) or NTX_SAFER.INF (for Windows 8, Windows 8.1 and Windows 10 as well as Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016) respectively.

Myths and Misconceptions

• SAFER has to be installed.

  Software Restriction Policies alias SAFER are a builtin feature of Windows XP and newer versions of Windows NT!

• SAFER is not available in Home editions.

  SAFER is available in all editions of Windows XP and newer versions of Windows NT!
  Home and Starter editions only lack the Local Security Policy snap-in of the Microsoft Management Console.

• SAFER is not suited for ordinary users.

  The SAFER ruleset configured by the setup scripts XP_SAFER.INF, NT6_SAFER.INF and NTX_SAFER.INF is made especially for ordinary (unprivileged) users who work with the applications installed on their computers!

• SAFER needs constant maintenance.

  The SAFER ruleset configured by the setup scripts XP_SAFER.INF, NT6_SAFER.INF and NTX_SAFER.INF allows to run all properly installed applications which meet the minimum requirements of the Designed for Windows guidelines!

• I use UAC, I don’t need SAFER.

  The UAC does not protect against execution of programs which run with standard user rights, for example ransomware like Locky!

• SAFER locks me out of my computer.

  The SAFER ruleset configured by the setup scripts XP_SAFER.INF, NT6_SAFER.INF and NTX_SAFER.INF restricts unprivileged users only, but not administrators, and does not restrict applications shipped with Windows NT!

  Additionally, Software Restriction Policies are not active in Safe Mode, where they can be disabled, for example via Registry Editor:

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
  ;"PolicyScope"=dword:00000001       ; exempt 'Administrators'
  "TransparentEnabled"=dword:00000000 ; no enforcement

Implementation and Build Details

All SAFER registry path rules which allow execution reference only Registry entries below HKEY_LOCAL_MACHINE to prevent users from tampering.
Note: never define a SAFER path rule that allows execution and references an environment variable or a Registry entry a user can write or modify!

SRP2LGPO.EXE, the program to export SAFER settings and rules from the Registry to the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol, is a pure Win32 application, written in ANSI C, built with the platform SDK for Windows Server 2003 R2 without the MSVCRT libraries, for use on Windows 2000 and newer versions of Windows NT.

SRP2LGPO.EXE is available for the I386 alias x86, AMD64 alias x64 and IA64 processor architectures of Windows NT.

Authenticity and Integrity

Serial number of the certificate

73420882

0x04605052

Fingerprint of the certificate

MD5: e5 0b 01 66 ce 2e 7a 03 f4 98 39 37 f6 f9 9f ba

SHA-1: 79 05 5d 63 2f 03 31 83 04 e2 ff 3b 25 b9 cc b6 70 ad ec 31

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAwoDvctTIkyz5KyHlms35ue9lm7I2yPVqZbRjGL26OKxei/R9APYKA47yoJQu
QZvr0husZPI/XQEGDicmBH1Gw/T821Y/E3pwUrumhw2dRI83Vn3wqO1OaAfkcOxjtNthr04r
YT+8f1SJtZabDP0Fv7dF4ltrUSwvy+lxV4jLLU2y7qtJ6XawLHEIBZAurozEGUVlgF93nsIZ
ydcHLxQzUEbSSsegkeY+aaaC/pGFE9Q3P3c4Nn5kOwK8ElwPwbHFMiK4t8RT3DSPXX0XQl2M
yoB3XAhZj6VOC9JyHC4COVSTnbFz3mmDkxYL/qyKFkDH/V5JWZhEv+T0Rl2Bebh91wIDAQAB
-----END RSA PUBLIC KEY-----

Note: due to its counter signature alias timestamp the digital signature remains valid past the X.509 certificates expiration date!

Download

Installation

Note: on systems with AMD64 alias x64 processor architecture the installation must be run in the native (64-bit) execution environment!

Automatic online installation

Manual offline installation

Update

Upgrade

Deinstallation

On Windows XP and Windows Server 2003 open the Add/Remove Programs applet of the Control Panel, tick the checkbox Updates, select the entry Softwarebeschränkungsrichtlinien für 'Windows XP/2003 [R2]' underneath Systemkonfiguration and click the Remove button.

On Windows Vista and newer versions of Windows NT open the Control Panel and click the entry View installed updates underneath the Programs and Features or Programs category.
In Installed Updates select the entry Softwarebeschränkungsrichtlinien für 'Windows Vista/2008 [R2]/7' underneath Systemkonfiguration and click the Uninstall menu entry.

Note: deinstallation neither removes the file %SystemRoot%\System32\GroupPolicy\Machine\Registry.Pol nor any SAFER settings and rules from it.

Contact

Use the X.509 certificate to send S/MIME encrypted mail.

Notes: I dislike HTML (and even weirder formats too) in email, I prefer to receive plain text.
I also expect to see a full (real) name as sender, not a nickname!
Emails in weird formats and without a proper sender name are likely to be discarded.
I abhor top posts and expect inline quotes in replies.

Terms and Conditions

• The software and the documentation on this site are provided as is without any warranty, neither express nor implied.
  In no event will the author be held liable for any damage(s) arising from the use of the software or the documentation.
• Permission is granted to use the current version of the software and the current version of the documentation solely for personal private and non-commercial purposes.
  An individuals use of the software or the documentation in his or her capacity or function as an agent, (independent) contractor, employee, member or officer of a business, corporation or organization (commercial or non-commercial) does not qualify as personal private and non-commercial purpose.
• Without written approval from the author the software or the documentation must not be used for a business, for commercial, corporate, governmental, military or organizational purposes of any kind, or in a commercial, corporate, governmental, military or organizational environment of any kind.
• Redistribution of the software and the documentation is allowed only in unmodified form of its current version and free of charge.