Is this possible? Using Permissions to avoid the SRP "macro weakness".

Guys remember this? Where someone can use Office Macros to bypass SRP even in a limited user account? Has this ever been fixed? If not is it possible to use permissions to cover the weakness?

What I mean is, is it possible to use Permissions to forbid Limited Users from executing programs saved in their User folder? I know it's possible to stop Users from saving/creating/modifying anything outside their own folder in Windows XP using permissions. What I'm asking is, is it possible to stop them from executing from their user folder? That way any corrupt macro can't do any damage since a) it can't save/wreck any files outside the user folder and b) can't execute anything it saves/downloads in the user folder.

Anyway to accomplish what I'm getting at using permissions? I see an option : read/execute in the Security Tab and under the Advanced option I see traverse folders/execute file.

 

I would say use EMET + Sandboie or Geswall to prevent it from infecting the system. a Force Low IL would help as well.

 

Turn off macros in office. I rarely use office products, and when I do, I use office 97, because I rarely use office products. I haven't looked at macros, but they are VBA, and might have an extension you could use?

Handle the macro or macro language.

Sul.

 

Thanks for the replies guys. But I was wondering if it's possible to use permissions to nip this in the bud. More out of curiosity than anything else.

The permission settings I was referring to : read/execute under the Security tab and traverse folder/execute file under Advanced settings are explained here.

 

Sure, you can modify some DACLs for folders or files, but they apply to everything, not just word documents with macros, or xls files, whatever the flavor.

You can use command line tools to simply deny execution for the current user or for the users group if you desire, leaving admins still able to execute.

The problem isn't can you deny execution or deny read access etc, but it is that you either target a specific known file or the entire directory. Do you really want to apply deny execute to your entire directory? Maybe you do, I am just pointing it out is all

Good to see you around zopzop, its been awhile since you have been posting in my corner of Wilders

Sul.

 

In short, the answer is "no".

Sure, nothing prevents you from taking away Execute permission from users regardind just one file, one folder, or the whole file system. But. That's not going to help "against" macros. They're not traditionally executed, at all. That's to say: when you "execute" a macro, there's no CreateProcess or any such function being called to create a new process out of that macro. No, the program that runs the macro (like Excel) does all the work in its own process that's already allowed. Depending on the program, you can run a macro that doesn't even exist in any file on the file system, so file permissions can't prevent that. The only thing one needs to be able to "execute" a macro is to be able to read it and we can't start denying basic Read permissions on everything.

 

Two options here
a) disable macro's
b) set a deny execute in user folder

Ad a - disable macro
This will prevent the execution of the embedded visual basic script

Ad b deny execute in user folder
This will prevent execution of the program stored in the user folder by the script

Ad b:
Use ICACLS or right click properties of the directory and add a deny execute for Everyone, see pic for right click option.
This tool adds security tab on XP (XP Pro has got it, as all versions of Vista and Windows 7) http://www.fajo.de/main/en/software/fajo-xp-fse
This tool is a nice tool to check access rights http://dabai.mysinamail.com/npt.html

 

@Sully

Hey Sully, thanks It's been slow, security wise, since setting up all my PCs with SRP/LUA/KAFU. I've tested by doing some crazy things and I'm still virus free after all this time. The reason why I started this thread is because I find this "macro weakness" disturbing. Just because virus makers haven't taken advantage of this hole yet, doesn't mean they won't sooner or later.

@Windchild

I understand but I'm not trying to stop the macro from running. I'm trying to stop the macro from executing programs in the User folders. For example, I don't want an Excel macro being used to run "adult solitaire" or something by bypassing SRP restrictions. I already used permissions to stop Users from saving/creating files anywhere on C: except their own folder. I wanted to use permissions to stop them from executing files in their User folder. So if a compromised macro ran, it can't execute any program it downloads/stores in the User's folder (rendering malicious macros powerless).

@Kees

Thanks for the graphic and explanation. But I have two questions, who is "Everyone"? I don't see that under the "Groups or User names" under the Security tab. All I have are : Users, Admins, and System. Do I have to create the "Everyone" group?

If I deny the traverse folders/execute files and apply it to : folder, subfolders, files, how will the User be able to navigate around his desktop/my documets/xxx? Shouldn't I apply it to : files only?

PS I'm on Windows XP Pro SP3

 

I don't use office at home. At work, I program VB, VBS and VBA for primarily access databases, building forms or VB front ends. I set all machines to disallow macros by default.

What are the ramifications of running excel at user level rights when a macro runs? Wouldn't excel be restricted, thus the macro inherit the restrictions? I have never looked at it, but I would imagine it would work that way.

What is the issue then with SRP and macros in the context of a restricted process, that the macro can defeat deny execute? Or is it something deeper where the fear is it gets root somehow?

Sul.

 

Well, well, well, what do you know? It works!

I did what Kees said but I changed it up a little since I don't have an "Everybody" in the Limited's Security tab section. I selected the folder of the Limited User Account user, right clicked, went to the Security tab, selected Advanced, added a Deny rule for "traverse folders/execute files" but applied it to : Files only.

Now the test. I downloaded a test executable (in my case it was ATF Cleaner), saved it to my limited user desktop, went here and got the test macro and ran it. Guess what? The permissions STOPPED IT! Said I didn't have the permission to run ATF CLeaner.exe!

The other half of the test, making sure I did it right, I tried running an executable that is not in Programs or Windows folders (since SRP already allows them to execute) but somewhere else on the C: drive (like C:\dell\ab10232\setup.exe), ran the test, the file executed! SRP was bypassed!

So I did the test correctly! Permissions>>>>>>>>>>>>>>>>>>SRP in terms of security.

--------------------------------------------------------------------------------------------​

Part II

I wanted to ask the experts here, instead of SRP, what do you think of using Permissions to mimic it, since Permissions seem WAY safer?

For example, using this setup for a limited user instead of SRP for them :

• C:\ - limited users have ZERO permissions
• Limited User folders - all permissions allowed except executing files
• Program and Windows folders - read/execute permissions ONLY allowed

These stips would only apply to limited users, admins have full rights of course. Yes no?

 

Yes, have a little more trust in my tweaks, please

It woks, on user space flders, just select add and type Everyone, check name and add. It works for traverse folder, subfolder, files. I donot know whether it works for subfolders also when you select files only. Could you check? On system space folder, you would need to add a deny write for LUA users (not everyone!

Registry User space
Another great way of using permissions is changing manually the ownership of user space (HKCU) registries entries. Use regil when on Vista/Windows, use TLU's trick of taking ownership by the admin.

TLU's trick (better than KAFU, because it protects more)
Just run autoruns of microsoft/sysinternals, set show empty keys. For every HKCU entry, use jumpto, when the key is not present, add it with regedit. When it exists, check whether the user has full acces, when user has, go to advanced, select the tab ownership and choose ADMIN.

Write Access in Windows/Programs FIles of standard user
You can also add the 1806 trick to cover the 'holes' in admin space which a user has write access to (downloads of mail and internet get a deny execute). Off course one can also set SRP deny execute of these folders for limited user (or/and give them basic user rights on XP and Vista).

Regards Kees

PS1. I hope Sully will find the time to finish SAFE-ADMIN, so manual tweaks are easy to apply. I run WIndows 7 Ultimate with no security software (well only Trusteer Rpport on IE9 and Trafficl light/Site Advisor on Chromium), SAFE-ADMIN is really secure and light.

 

As I said, you can apply deny execute (disabling traverse/execute) a directory, and it will work. This is easy to do. However, you must know all the directories you are going to do this on. It is, what would the correct words be, "cumbersome and messy" I guess would be best.

A member of the Users group is by default allowed ONLY read/execute (generically) in c:\ , c:\program files and c:\windows. They are denied areas like users profiles that are not thier own, and some rights on c:\ and a few other areas. They are allowed to do about anything in thier own user profile directories or custom made directories (ie. c:\myDir). So, you already have a defined set of restrictions in place for USERS.

When you use SRP as you are, in default deny, you are saying for all users EXCEPT admins, deny execution, everywhere except %windir% and %programfiles%. This allows installed applications in %programfiles% to run, and obviously all the files in %windir% that are required, to run. It stops all other executions. In the case of macros, when you allow excel to run, it can in turn run a macro, which as you know can then be coded to start other processes.

When you apply a deny execute setting to a directory, SRP isn't even in the picture any more. You obviously apply it to the USERS group, or to a SPECIFIC USER, but the result is the same, no executions. So when you macro attempts to run, it succeeds. When it attempts to start a program in a deny execute folder, it will fail.

Now, what you are contemplating will require inheritance. You cannot just go to a folder and check a box and expect everything under it to be the same. It might do that, or it might not, it depends on what the inheritance settings are, both in the parent folder and sub folders. You cannot just take away rights to c:\ , that is not good. Well, you can, but you probably don't want to. The rights for the c:\ itself are that you can create new things, which you might need to do. Denying execute would be better IMO.

Getting rid of SRP would entail setting rights on top level directories, and applying inhertance so that those rights propagate to all child and grand child and great grand child directories. This is why I say "cumbersome and messy". Believe me, I have done it, and it can quickly become a nightmare. Not a big deal in a test environment, but something I really really really shy away from on a live system if I can help it.

I know what you are trying to do, and I applaud you for thinking beyond the norm for average users. However, I think you will be rather disappointed at the end results, because you will most likely get some strange things happening from the inheritance that you don't want.

I am not the authority on such things. I can only say that I have been there and done that many times before. My experiences have taught me that I should be choosy about what rights I grant or deny, and that whenever inheritance comes into play, to be 10x as cautious.

I don't think there is going to be a super duper solution to the whole SRP-Macro business except for disabling macros. If you know that there are malicious macros that exploit in a certain way, in a certain directory, you can easily use rights to mitigate the situation. However, applying deny execute everywhere will mean that anything you want to execute MUST BE AT ADMIN LEVEL. Are you ready for that? As it is, with SRP, you can exclude specific places and still know that what starts will have the restrictions of a user. Once you implement deny execute for a user or members of the USERS group, you have no recourse but to RunAsAdmin or modify your rights on that object/container.

I don't know, I would certainly encourage you to try it out, it is very educational. I would be very interested to hear what you think of it and how it works. You never know, you may have a certain spin on it that makes it easy and effective That would be great. I can only go by what I have experienced, and that is the whole thing is complicated and can break things very quickly.

Let us know how you fare.

Sul.

 

Ah, okay, I misunderstood you before, thinking you wanted to stop macros from running entirely. Because, even if you can run just a macro and nothing more, you can still do lots of stuff. Macros are pretty powerful. I suppose not all folks remember the days of the macro virus anymore. There's really no reason why that adult solitaire couldn't be just an Office macro. As a nice example, didn't Didier Stevens recently post an Excel spreadsheet that pretty much does Task Manager's job by the power of graysku... I mean, macros.

But, yeah, if you just want to prevent some program file in some folder from being executed by a macro, you can in fact use file permissions for that. Most people don't know Windows even has a functional Execute file permission, but it does, and it works, and it can be used for exactly what the name implies. You could even go the way of the Linux and just take away all Execute permissions from users, except of course for those "allowed" files that admin has installed for everyone, like the usual Program Files folder contents and so on and on. Lots of work, and as Sully said, may involve funny inheritance hickups, but it's doable, although I personally wouldn't bother with that, considering the threat environment.

If Excel is running in a limited user account then any macros executed by Excel are also running with limited privileges. The concern folks have is that even with such limited privileges, that macro could do nastiness, like delete user-accessible files and such, or perhaps even exploit some privilege escalation vulnerability to gain root. That, and the whole SRP/AppLocker bypass thing.

Me, though? More concerned about being struck by lightning while out in the woods.

 

@Sully

You know way more about this than I do, so if you say it's a headache to implement, then I won't even try it I wasn't even thinking about inheritance issues. Thanks for the warning.

@Kees

Ok created the "Everybody" group. Can't believe it wasn't there. How would I test this Kees?

To see if it works for subfolders, if files only is selected?

And PS, I never doubted your tweaks, not even for a second!


To anyone with Vista or Win7, can you test the "Parental Control" option to whitelist programs vs the macro hole?

 

Don't let me stop you from experimenting and learning. I think you should try it in a test environment, I am just telling you what I know.

Sul.