SRP rules questions

On my Windows XP Pro system, I just added the SRP path deny rules from https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm
I found that some executables that I wanted to block exist in two different folders under C:\WINDOWS\
Therefore, I added blocking rules specifying just the executable names. I found that their execution was allowed on the LUA.
I changed the blocked executables rules to use a complete path, and then they took effect.
Have others had the same experience?

At http://technet.microsoft.com/en-us/library/bb457006.aspx I read that the SRP uses the rule that is most specific.
I guess this means that the SRP interprets the allow rule for C:\WINDOWS\* to be more specific than the deny rule for name.exe.

Something that confuses me... The default rules are:
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% Unrestricted
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe Unrestricted
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe Unrestricted
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% Unrestricted

Aren't the 2nd and 3rd rules redundant with the first? Why did Microsoft add the 2nd and 3rd rules?

Edit: fixed the link

Binky wrote:On my Windows XP Pro system, I just added the SRP path deny rules from https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm
I found that some executables that I wanted to block exist in two different folders under C:\WINDOWS\
Therefore, I added blocking rules specifying just the executable names. I found that their execution was allowed on the LUA.
I changed the blocked executables rules to use a complete path, and then they took effect.
Have others had the same experience?

Not sure if I fully understand this, so I've got a few questions:
1. Exactly which executables (that I advised to block) exist in two different folders?
2. How do you mean by "blocking rules specifying just the executable names"? Blocking them by complete path sounds like what I do. For example, to block "cmd.exe", I'd enter the following path as "Disallowed":
C:\WINDOWS\system32\cmd.exe

Binky wrote:At http://technet.microsoft.com/en-us/library/bb457006.aspx, I read that the SRP uses the rule that is most specific.
I guess this means that the SRP interprets the allow rule for C:\WINDOWS\* to be more specific than the deny rule for name.exe.

That's not how I interpret it, and I'm pretty sure that's not how it works. In my experience, SRP will follow the Deny rule first, and then only the Allow rule. A good example is how I've setup my SRP - I keep the default rules as they are (they allow anything from C:\Windows and C:\Program Files to run), but then I add in specific Deny (path) rules for "cmd.exe" etc. So even though everything in C:\Windows can run, "C:\WINDOWS\system32\cmd.exe" will be blocked from running because I've specifically denied it...I guess you're correct to some extent, but you mis-worded what you wanted to say?

Binky wrote:Something that confuses me... The default rules are:
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% Unrestricted
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe Unrestricted
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe Unrestricted
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% Unrestricted

Aren't the 2nd and 3rd rules redundant with the first? Why did Microsoft add the 2nd and 3rd rules?

Great question, and something I've always wanted to know too haha. I also believe the 2nd and 3rd rules are redundant, but I just leave them alone anyway.

Good to know you use full paths in specifying blocked executables. You may want to clarify this in your SRP summary.

ssj100 wrote:1. Exactly which executables (that I advised to block) exist in two different folders?

C:\WINDOWS\ie8\vbscript.dll
C:\WINDOWS\system32\vbscript.dll
Also, many of the executables are also found in the DLL cache and KB uninstall folders. I am not sure if they can be executed from the LUA.

ssj100 wrote:2. How do you mean by "blocking rules specifying just the executable names"?

An example of a specification I tried:
*\vbscript.dll

ssj100 wrote:That's not how I interpret it, and I'm pretty sure that's not how it works. In my experience, SRP will follow the Deny rule first, and then only the Allow rule.

A quote to support my interpretation:

http://technet.microsoft.com/en-us/library/bb457006.aspx wrote:Path Rule Precedence. When there are multiple matching path rules, the most specific matching rule takes precedence.

I have tested that the SRP blocks my intended executables on the LUA. How can I test that the SRP blocks execution from my intended folders on the LUA?

Binky wrote:Good to know you use full paths in specifying blocked executables. You may want to clarify this in your SRP summary.

If you read it carefully, you'll see that I have:

In addition, here are some extra rules I would suggest adding to your SRP deny list with path rules:

I'm still not sure what you meant by "blocking rules specifying just the executable names". As far as I know, you can only block rules by "Path", "Hash", "Certificate", or "Internet Zone".

Binky wrote:C:\WINDOWS\ie8\vbscript.dll
C:\WINDOWS\system32\vbscript.dll
Also, many of the executables are also found in the DLL cache and KB uninstall folders. I am not sure if they can be executed from the LUA.

Wow, I didn't realise that haha. Yes, I'll probably have to revise additional paths to be blocked (in hidden folders etc). I'll post about this later. I'm also not sure if they can be executed from the LUA. However, it's probably all redundant anyway, if one is using Sandboxie as the first line of defence and is following my setup/approach.

Binky wrote:An example of a specification I tried:
*\vbscript.dll

I see, I didn't think of using a "path" rule like that (and I don't think Microsoft did either haha). In my freshly installed Windows XP VM, I just tested it by adding "*\cmd.exe" and it didn't work. Now I see what you mean by "full path" too.

Binky wrote:A quote to support my interpretation:

http://technet.microsoft.com/en-us/library/bb457006.aspx wrote:Path Rule Precedence. When there are multiple matching path rules, the most specific matching rule takes precedence.

I have tested that the SRP blocks my intended executables on the LUA. How can I test that the SRP blocks execution from my intended folders on the LUA?

You should be able to test that folders are blocked by placing an executable in those folders and trying to execute it - SRP should deny it from running.

Okay, after some quick testing, "C:\WINDOWS\ie8\vbscript.dll" is the only additional path rule that would need to be added.

Anything in "C:\WINDOWS\system32\dllcache" is denied access from running in a Limited User Account. The same applies for the "KB uninstall folders". Therefore, any executable that's found there can be ignored.

I found a simple solution. Use SRP blocking path rules for executables like:
C:\WINDOWS\*\ExecutableName.Ext

This handles cases in C:\WINDOWS\system32\, C:\WINDOWS\ie8\, C:\WINDOWS\system32\dllcache\ and KB uninstall folders under C:\WINDOWS\, even if an attacker finds a way to access the folders with LUA privileges. The SRP considers these rules more specific than the allow rule for C:\WINDOWS\, so the blocking rules take precedence. I confirmed that the new style path rules work in WinXP Pro x86 SP3 and Win7 Ultimate x64.

Here is a way to test the SRP on the LUA for any executable. Open a Command window (or Start->Run->enter name of cmd.exe used by Sandboxie). Enter: ExecutableName.Ext /?
If blocked by the SRP, the response will be "The system cannot execute the specified program." Event Viewer/Application will have a warning entry with Source=Software Restriction Policies.

With the Command window still open, a way to test the SRP on the LUA for any blocked folder is: copy C:\WINDOWS\NOTEPAD.EXE TestFolder\
Then try to execute it: TestFolder\NOTEPAD.EXE
If the SRP blocks it, the response is the same as above.
NTFS permissions take precedence over the SRP. Some of the folders are blocked because LUA users have permissions to change permissions. So NTFS ACL blocking may occur until execute permissions are granted to the copied NOTEPAD.EXE.

Binky wrote:I found a simple solution. Use SRP blocking path rules for executables like:
C:\WINDOWS\*\ExecutableName.Ext

Nice thinking - I might implement this myself, although it's a bit academic (reason below).

Binky wrote:This handles cases in C:\WINDOWS\system32\, C:\WINDOWS\ie8\, C:\WINDOWS\system32\dllcache\ and KB uninstall folders under C:\WINDOWS\, even if an attacker finds a way to access the folders with LUA privileges.

This is indeed a theoretical scenario. However, from my understanding, if an attacker finds a way to access the folders (and execute from them) that are not allowed to be accessed as a Limited User, wouldn't they be using a Privilege Escalation Exploit? And therefore, any SRP rules would be useless anyway. I suppose you could apply the SRP rules for Administrators too, but this wouldn't stop the attacker applying a malicious executable file into eg. "C:\Program Files" and execute it from there (since they have Admin privileges from the Privilege Escalation Exploit).

Therefore, as I stated before, applying your rules like above is a bit academic and perhaps arguably pointless. However, it certainly appears to be a more complete method.

Binky wrote:The SRP considers these rules more specific than the allow rule for C:\WINDOWS\, so the blocking rules take precedence.

Yes, that's how I've always understood it - the specific blocking path rules take precedence over the allow rules.

Binky wrote:Here is a way to test the SRP on the LUA for any executable. Open a Command window (or Start->Run->enter name of cmd.exe used by Sandboxie). Enter: ExecutableName.Ext /?
If blocked by the SRP, the response will be "The system cannot execute the specified program." Event Viewer/Application will have a warning entry with Source=Software Restriction Policies.

With the Command window still open, a way to test the SRP on the LUA for any blocked folder is: copy C:\WINDOWS\NOTEPAD.EXE TestFolder\
Then try to execute it: TestFolder\NOTEPAD.EXE
If the SRP blocks it, the response is the same as above.
NTFS permissions take precedence over the SRP. Some of the folders are blocked because LUA users have permissions to change permissions. So NTFS ACL blocking may occur until execute permissions are granted to the copied NOTEPAD.EXE.

Yes, using the command prompt is a good method of testing whether an executable can run from a certain folder. This is something I overlooked in the past, and one should always use something like AccessEnum to check the privileges of Limited Accounts, ensuring that no folder has both Write and Execute access:

With a fresh installation of Windows XP Professional, there are seven folders that allow writing by default, even in a Limited User Account:
C:\WINDOWS\Tasks
C:\Windows\Debug\UserMode
C:\Windows\system32\spool\PRINTERS
C:\Windows\Registration\CRMLog
C:\Windows\Temp
C:\WINDOWS\pchealth\ERRORREP\QHEADLES (this is only created if you have left Error Reporting on and an error occurs)
C:\WINDOWS\pchealth\ERRORREP\QSIGNOFF (this is only created if you have left Error Reporting on and an error occurs)

Therefore, you can add the above seven folders to the SRP deny list with path rules.