Windows GPO Software Restrictions Policy not working with %TEMP% variable

group-policySecuritywindows

I'm trying to put in some meagre additional malware prevention measures, by restricting the execution of *.exe in a handful of locations — in particular, the temporary folders that various compression tools unzip to, when a user might choose to open an executable straight from a Zip file.

From the TechNet article, http://technet.microsoft.com/nl-nl/library/cc786941%28v=ws.10%29.aspx:

You can use environment variables in a path rule. Since path rules are evaluated in the client environment, the ability to use environment variables (for example, %Windir%) allows a rule to adapt to a particular user’s environment.

A path rule can incorporate the ? and * wildcards, allowing rules such as "*.vbs" to match all Visual Basic Script files. The following examples illustrate the use of wildcards:

  • “\DC-??\login$” matches \DC-01\login$, \DC-02\login$
  • “*\Windows” matches C:\Windows, D:\Windows, E:\Windows
  • “c:\win*” matches c:\winnt, c:\windows, c:\windir

I have these Path rules (which I have applied both singularly and in various combinations):

  • %APPDATA%\*.exe
  • %APPDATA%\*\*.exe
  • %LOCALAPPDATA%\*.exe
  • %LOCALAPPDATA%\*\*.exe
  • %TEMP%\*.exe
  • %TEMP%\7z*\*.exe
  • %TEMP%\wz*\*.exe
  • %TEMP%\Rar*\*.exe

…which theoretically should represent executables directly under the user's temp folder, and executables in temp folders named in the manner that Winzip, WinRAR and 7-zip might name their temp folders (e.g. %TEMP%\7zSF20.tmp\the_file.exe).

The %APPDATA% and %LOCALAPPDATA% ones work; the %TEMP% ones don't. Executables appear to be blocked under %TEMP% but this is only because, in a default setup, they also match the %LOCALAPPDATA%\*\*.exe rule (Temp is under AppData\Local, by default).

I had originally thought this was an issue with wildcards in partial folder names, but it appears this is specific to the use of the %TEMP% variable (hence the rewrite).

The two workarounds I have confirmed (and why I'd prefer not to use them) are:

  1. using %LOCALAPPDATA%\Temp in place of %TEMP%

    • Strictly speaking, this is not correct, as the %TEMP% variable can be set to differ from %LOCALAPPDATA%\Temp.
  2. using %HKEY_CURRENT_USER\Environment\TEMP%

    • Registry-based path rules seem to apply to all subfolders — I would prefer a slightly lighter touch (so I don't have to go around whitelisting everything else)
    • Registry-based rules appear to be limited such that you cannot have anything more specific, e.g. %HKEY_CURRENT_USER\Environment\TEMP%\7z*\*.exe
      • I have since discovered %HKEY_CURRENT_USER\Environment\TEMP%7z* will get close (the \ between the variable and the subfolder should not be specified, and you can't specify a filename mask afterwards)
    • It is also also technically incorrect, as this registry location only contains the value as it should be at the start of a process and not what it might be changed to during the course of that process — e.g. it would not apply if you opened a Command Prompt, issued SET TEMP=C:\ and ran the program from the prompt).

(For what it is worth, I have tried configuring the SRP in both the Computer and User sections of the GPO, both independently and simultaneously, in case one overwrote the other, or %TEMP% was resolved differently at Computer and User level.)

What's so special about the %TEMP% variable that it would not apply here, whereas something like %LOCALAPPDATA%\Temp\\wz*\\*.exe would?


Update:

It appears that the limitation is specifically with the %TEMP% environment variable. I have edited the question, as such.

Best Answer

The program might see a different contents of %TEMP% than you, when you check it in cmd.exe or command.com. Sometimes they are not the same.

But using Environment Variables in Software Restriction Policy is a bad idea anyway, because a malware can change the variable.