Problem using SRP in c:\windows\temp

Actually, I don't think it is exactly as you guys suggest.

In win7, for me anyway, if I make a copy of notepad.exe, it won't execute from anywhere else. In fact, notepad is owned by TrustedInstaller, so moving it to a custom directory won't work. Further giving ownership of notepad to admins or my admin account (actual user name as the owner), one still cannot "cut" or "move" notepad. If you copy it, it won't execute and you can't move it. So notepad is a bad example to use in this case.

If we consider how SRP works we can gain a better understanding. First we must understand the heirarchy, or more aptly name, precedence:

Here we see that the default of "disallow" or "deny" is the very last thing that happens in a default deny policy. Path rules are what most will use, and those are processed before the default deny rule.

Here we see that a more exact match has actions first, pretty simple really. How does this correlate to what we think is happening?

So why is notepad.exe starting when you rename wfc.exe to notepad? I think notepad.exe would be denied when you copy it to your desktop, regardless of what SRP is doing, because it is somehow a protected file. The renamed wfc.exe shows this to be true, as it is not notepad, but when it is called to create a process, likely the command interpreter is the culprit, whether it is from an environment varible (path) or not, who can say. It is notepad that is the issue IMO, not your SRP rules or whether notepad.exe is in an approved SRP directory. Of course, notepad must be in an SRP approved directory, but that isn't really part of the issue you are seeing.

There are other files that behave the same way as notepad that I have tested, such as regedit. Copy that one and you will see the exact same things that you saw with notepad. This is likely due to permission inheritance of the windows directory, although I haven't looked at it yet.

Sul.

 

I had no issue copying notepad, then renaming it to something else... Not sure what you mean here. In fact, I typically copy notepad.exe around to test applocker from the windows GUI. Never had an issue.

I'm going to stop the quote right here, because I think that it does not matter what your SRP rules are, because my theory is that SRP mechanics never comes into play. IMO, you are simply running the white-listed notepad.exe in C:\windows\system32\. You can go to the command prompt and type in notepad.exe from any directory location, and C:\windows\system32\notepad.exe will run (as this path is allowed by SRP).

If you have notepad.exe in your current directory (lets say C:\windows\temp\), notepad.exe will run from that location. If its not in an SRP whitelisted location, it will deny you.

Now what I believe is happening with you guys is that you are taking away permissions that allow you to view the files in a directory. As far as your command prompt knows, the notepad.exe is not in the current directory (even if it is actually in there). The reason for this is that your command prompt (running with your user credentials) does not have permission to find out what is actually in that directory. Since it can't find notepad.exe in your current directory (C:\windows\temp\), Windows then launches the C:\windows\system32\notepad.exe (which is of course whitelisted).

If you want confirmation, all you need to do is rename the REAL notepad.exe in C:\windows\system32\notepad.exe . If your notepad.exe in C:\windows\temp\ still runs, then I am clearly wrong. If you get a file not found, or a denied error, then clearly I would be correct.

Test it out, let me know..

EDIT: as you noted, this should also be happening with tools like regedit, or any other utility in the windows system paths..

 

I agree on your SRP thoughts about this. It denies or whitelists, and if it is redirected to the sysdir, then it is allowed, pretty simple.

If you are not aware, SRP cannot protect environment variables, and those "could" pose a threat because a command prompt could change them easy enough, but that is another matter best left for another topic.

What I find interesting is that you say you can copy/paste notepad.exe to other locations and it works. Are you using win7 ultimate? I absolutely cannot, in any way yet, move or copy notepad.exe from either windir or sys32, to any other directory and have it work. Actually just the act of cutting and pasting gives errors, and I am denied, even after changing ownership.

It has been that way for me since day 1 with win7. To me it makes sense as to what wat0114 was talking about with its strange behaviour. Can you verify what OS you are running and whether it works (not that I doubt you, just verification) to copy and execute or if you can even move it at all?

BTW, I have no special permissions added or removed from anything except my downloads directory right now. I am not using UAC and have turned it off on this machine, but in my VM last night with everything at default, it was doing the same thing. Quite interesting to me

Sul.

 

Thats what I was saying I guess, is that if I copied it there, from the SUA account it would not give a DIR on it, and would not even recognize it existed without passing an FQP, and only then would it be denied.

But, was it denied because SRP was actually denying it, or was it just not executing because (for me anyway) I cannot execute a copy of notepad from anywhere else but windir or sys32.

Heck, I can't even rename much less move notepad.exe in either windir or sys32 (it lives in both, and neither are junctions or symlinks). I wonder how you have been allowed to do this.

Sul.

 

Sully just to clarify... You can't even copy and past notepad.exe to, say, the Desktop? Or, you can copy and past, just not execute?

I can copy and paste, but due to AppLocker cannot execute. Makes sense. I didn't disable my rules... So, I cannot say whether or not it would still run. But, I can copy and paste, though.

Windows 7 Ultimate x86.

 

I can copy and paste anywhere, but it will never execute, ever.

I cannot cut and paste or move notepad from either windir or sys32, always an error no matter what I try I never have permissions, even as admin, even as owner.

Regedit.exe located in windir does the exact same thing for me too.

Win7 Ultimate x86 as well.

Sul.

 

OK. I just created an allow rule in AppLocker for notepad.exe, placed in Desktop, and execution is allowed (I checked Event Viewer), but Notepad doesn't open.

Standard User Account, by the way.

 

I have not set AL up on this install, nor SRP.

I see no process being created at all when I execute notepad from a copied location.

Strange behaviour I have always thought.

Sul.

 

I should note that I copy and move the file as an Administrator... I'm using windows 7 x64. My standard user account can then execute it (if Applocker allows).

I haven't done anything special either, except my Admin account has no UAC prompting... I will check whether my standard user can do this later on though. My work computer is XP, my Win7 computer is at home..

EDIT: just tested on a Win7 computer in my office. copied without incident using a standard user account. Could not test executable privileges since I am in fact forcing my users to submit to my SRP rules..

 

When you get to your win7 machine, check if both regedit and notepad can actually be "moved". I am admin in win7 with UAC off, and I cannot achieve this.

Sul.

 

It can't be "cut" or "moved" with the default settings, but it can be copied.

If you want to rename or delete the file, of course you have to edit the security settings. To make things easier on yourself, you can just use unlocker.. We don't really care about permissions of the original notepad.exe, we just want to test which notepad you are really running (at least for the test I proposed)..

 

Hmm. I don't need to move it at all. I was wondering how you managed to do so since I could not seem to. Some of the posts earlier were discussing why notepad exhibited certain behaviours, and I knew I could not move it or execute it, and assumed others had for some reason been able to.

I still wonder what it is about win7 that keeps one from moving it or renaming it. XP never had that issue that I recall. It must be a permission somewhere, but it is still different.

If notepad could be moved, then SRP would act according to how it is supposed to - it would be allowed in excluded directories (or a wildcard) or denied, unless some of the environment variables were to be tampered with.

Sul.

 

I was under the impression that you couldn't COPY notepad.exe, which as you know leaves the original... Many files in the windows directory seem to be under the ownership of "trusted installer" though. Everyone except trusted installer has read permission.

My guess is this is to prevent users (and maybe malware) from doing some damage. If someone deleted these files in XP, they'd have no problem hosing a few important features if not the OS itself. I guess Windows 7 went more down the path of dummy proofing and protecting from this kind of thing. Makes sense I guess.

 

I copied notepad.exe from \Windows into \Windows\temp. Then started a cmd prompt in a standard account, CD into \windows\temp. And tried to run notepad, and a notepad did come up.

I think the test should be to copy notepad.exe from Windows to \Windows\temp but renaming it to notepa. I renamed the file to \windows\temp\notepa.exe and it refused to run.

I think the first try ended up running the original notepad from \Windows because it is in the PATH environment variable. Remember the DOS days? The PATH environment variable stores a list of directory names, and tells the system where to look for exe's when what you typed is not found in the current directory. And both \Windows and \Windows\System32 are part of the defined PATH var. Just type SET and you will see it.

 

Hello again everyone, hope you didn't think I'd cut and run from this thread, but a family emergency has prevented me from getting back until now . Looks like a lot of good stuff to read through when I get the time.

You may have already covered this ground, but I have done some quick testing of my own. I reset permissions on windows\temp to default and removed the SRP disallow rule on it. I then copied some random .exe files from a thumbdrive to it. Once again had no problems doing this from a User account, as Users have WRITE access to windows\temp.

But I was unable to execute any of them. Seems they were all unrecognised as executable or batch files. Does this suggest that in order for Users to execute anything it has to be installed first? And as Users can't install anything new, then they can never execute anything new from windows\temp?

SRP was removed from the equation, however the OS was still preventing a User from executing User-copied binaries from windows\temp. At the end of the day, this is what I really wanted. It doesn't matter whether it's SRP doing it or something else, I just don't want Users executing from anywhere they have WRITE access.

 

I'm 99.9999% certain that you cannot run any file in C:\windows\temp . You were only able to run notepad.exe because you were running the C:\windows\system32\notepad.exe, not the one in C:\windows\temp. As I suggested to Sully, if you simply rename C:\windows\system32\notepad.exe to something else, notepad.exe will no long launch. (NOTE: in order to do this, you will have to take ownership, then change permissions. You can also use the tool "unlocker" to rename it).

 

If you are a member of users only (SUA or LUA or whatever you want to call it), with everything at default, you are not allowed to browse to the temp directory using explorer.exe. In fact, even using a 3rd party tool like q-dir does not allow you to. Putting Qdir in windir, and running it from there, still won't allow it.

If you use cmd, you can navigate to temp, but you find nothing if you use DIR there. From temp, typing in a filename.exe will not produce any results, as no files are found.

If you use an FQP (Fully Qualified Path, ie. c:\windows\temp\filename.exe) then it will execute. You can execute using an FQP from CMD, Run box and even explorer itself if you put an FQP in the address bar.

If you copy notepad.exe into temp, as you noted, it runs but actually it runs from sys32. The same applies for write or calc as simple tests.

So, to get executions to stop in temp, you should either modify the rights for users or use something like SRP. It is strange why, without SRP being used, cmd or explorer or the run box will allow execution, but you cannot actually browse there. In looking at the rights, the USER GROUP has rights to
Traverse/execute file
list folder/read data
read attributes
read extended attributes
read permissions

The USER ACCOUNT has the same rights. These are typical rights of a user, read and execute but not modify, yet the directory is still limited, without SRP or any other change from defaults.

So the original question of this thread, supposing there are no strange rights other than those default ones, is that you cannot browse there to execute, but you can execute with a FQP. To stop exeuction, use rights or SRP. Either "should" deny the execution.

The rest of this thread was quite informative as to the quirks that were noted. The "why" of some of these is still unknown, and maybe not relative for anything, but still interesting to know to some I suppose, at least those who like to understand the inner workings.

Sul.

 

I'm starting to believe this too, though not quite yet with your level of conviction. I still see people in other threads and other forums recommending adding windows\temp to SRP. Hopefully this thread can help me make up my own mind .

So why does SRP block notepad.exe when copied to other folders on my PC? If the OS is calling c:\windows\notepad.exe then wouldn't that bypass the default disallow on the other folders? And in the same vein, why does adding List Folder/Read Data permission to windows\temp allow SRP to then work on notepad.exe there?

*EDIT* I can answer this myself - because these other folders had READ permission. Therefore the OS didn't have to go looking for it in the PATH variables, and could apply the disallow rule to the notepad.exe which was actually in the same folder. Boy this can get confusing!

 

Correct.

Not for me. Pls see my post #15:

Not for me. Pls see my post #5

This is where things may be different in our setups. On my W7 Pro, Users have the following permissions in c:\windows\temp:

Traverse/Execute File
Create Files/Write Data
Create Folders/Append Data

They are listed as "Special Permissions". When I added List Folder/Read Data, then DIR's worked, and also, most importantly SRP worked. Hence my theory in post #16

I have no idea whether this theory is correct or not, and at the end of the day I don't really care. As stated above I just want to deny execution to users in locations they can write to.

Thank you all for bearing with me I now understand how notepad.exe was able to execute and how it is not a good test .exe to use in this situation. It was the lack of READ permission on my windows\temp which appeared to show a hole in SRP which wasn't really there. Maybe I'll start another thread asking for opinions on whether an SRP policy is really required on windows\temp or not.