Group policy exception to disallowed

group-policymalwarewindows-server-2008-r2

I'm trying to setup a group policy on a domain to block cryptolocker (among others). I'm mostly following the Cryptolocker Prevention Kit (http://community.spiceworks.com/topic/396103-cryptolocker-prevention-kit-updated). Using a 2008R2 DC.

However, I need to make an exception for Firefox, since the installs are 7zipped exe's, which are blocked. I added the exception, did a "gpupdate /force" on a test machine (Win 7), then rebooted. But the exception is ignored. Here is the relevant snippet from GPMC:

%LocalAppData%\Temp\7z*\*.exe 
Security Level Disallowed 
Description Block executables run from archive attachments opened with 7zip 
Date last modified 11/8/2013 10:56:08 AM 

%LocalAppData%\Temp\7z*\setup.exe 
Security Level Unrestricted

These policies are in the Global Machine Policy if that makes any difference. The actual file being blocked is %LocalAppData%\Temp\7zSE455.tmp\setup.exe according to event viewer. The "SE455" in 7zSE455.tmp changes, so I can't hard-code that.

I have verified that the first policy above is doing the blocking via searching for the SrpRuleGUID from event viewer in the registry of the test machine. I also see the unrestricted rule there too, so it is applied.

If I remove the first policy/rule above, do the gpupdate reboot dance, then it works, so that means it IS that rule blocking me.

From my readings, Unrestricted is supposed to take precedence over Disallowed. So why am I still being blocked by group policy?

Edit: A technet document (http://technet.microsoft.com/en-us/library/bb457006.aspx) indicates a more specific rule match overrides a less specific rule match. In my case above, setup.exe IS more specific than *.exe. So I was wrong about unrestricted overriding disallow, but my rules SHOULD still work as expected. Unfortunately, they don't.

Best Answer

The technet document above is correct, but unclear. The path rules are really folder based. So for example, say you want to block c:\temp\xyz\*.exe but allow c:\temp\xyz\setup.exe. If the block rule is c:\temp\xyz\*.exe , the allow rule will be ignored. This is because "If two identical rules with differing security levels are applied to software, the more conservative rule takes precedence."

Identical here means the same folder/path. Since the PATH in c:\temp\xyz\*.exe is c:\temp\xyz and the path in c:\temp\xyz\setup.exe is also c:\temp\xyz, they are considered identical rules. Even c:\temp\x*\*.exe would be considered the same path since c:\temp\x* can match c:\temp\xyz . Yes, it seems like a bug to me too, but that's the way it is.

In order to get setup.exe to run, you have two options:

  1. Create a hash rule for setup.exe. Hash rules always override path rules. They are also quite secure and fairly easy to setup in Server 2008R2. Just create a new hash rule and browse to the file. It creates the hash for you. This also allows that setup to run from ANY path, regardless of the other path rules you may have. The downside is you have to update the hash rule every time setup.exe changes. You also have to do every file you need to whitelist.
  2. Change the disallow rule c:\temp\x* (or c:\temp\x*\*.exe , or c:\temp\x*) to c:\temp. There is an understood *.* after the trailing \ . But, it won't override a specific folder, so c:\temp\xyz\ in an unrestricted rule will work properly. However, this is new disallow rule is *.*, so it may catch other folders you didn't mean to restrict, such as c:\temp\rarc6da\setup.exe. In which case, you need a separate path rule for each of those.
Related Topic