AppLocker Anomoly

For anyone venturing into trying this feature out, it might actually block *.BIN extensions, at least in Openoffice (soffice.Bin), for some strange reason, even though this extension is not listed as one of the two (.EXE & .COM) it manages.

I've discovered the best way to troubleshoot issues using AppLocker is to change the AppLocker-> Configure rule enforcement-> Executable files from "Enforce rules" to "Audit only"; this will enable all applications to run, and anything that would have been blocked will be logged. Then, open up the application that was being blocked previously by AppLocker. Then, go to Start, type in event vie... then choose Event Viewer at the top of Start menu -> Applications and services logs-> Microsoft-> Windows-> AppLocker-> EXE and DLL; you should see in the log entries the program that would have been blocked had AppLocker rules been enforced. Using the information, you can easily modify the rule necessary so the application will not be blocked.

 

It's not an anomaly at all. AppLocker (and SRP) do not work based on file extensions alone. Instead, they work based on what is being executed. It doesn't matter if the file is called i_am_just_a_text_file_honest.txt, if something tries to execute it, create a process out of that supposed text file, AppLocker will be interested. "soffice.Bin" is an Open Office process. Key word being process. That file is being executed, and therefore AppLocker will obviously be interested in it no matter what the file extension is, and will block it, if the rules say it should not be allowed to run. Exactly the same way, you can open an exe file all day long, even though it's in AppLocker's list and the rules deny execution for that file, for viewing the exe file in Notepad for example or in a hex editor, just as long as you don't actually execute it, which AppLocker would prevent. If AppLocker didn't work this way, it would be just... well, stupid, because then anyone could trivially bypass AppLocker just by changing the file extensions: "malware.exe" is not allowed to run, but "malware.bin" would be even though it's exactly the same file and both are being created as a process. File extensions in general are pretty pointless as far as security is concerned - just a part of a name, and a name can be anything. It's not important what something claims to be (it has the name of a text file), important is what something really actually is (an exe file that has been given the wrong file extension but can still be executed).

And yes, audit only is a very useful tool.

 

Hi Windchild and thanks for the explanation. I just take things in the literal sense sometimes; AppLocker states that executable file extensions it manages are .exe and .com, thus my surprise at it stopping the .bin process, even after I had auto-generated hash rules (publisher rules not possible because openoffice files aren't signed) for everything in its program folder. So, interestingly enough and maybe you know why it worked, but I fixed the problem by creating a Path rule for the openoffice Program folder. No more blocked soffice.bin. I'd prefer Publisher or even Hash rules but it is an allowed program anyways so no big deal using the weaker path rule in this case. Your explanation makes sense technically, just that I did not expect AppLocker to behave this way, but I think all is good. Thank goodness for the Audit feature to help resolve these mysteries If only the Win 7 firewall had a similar feature or, better yet, logged applications as well as ip addresses & ports that were blocked.

BTW, take a look at the rules I needed to create, thanks to Audit feature's help, for my son's Unity web player game (I really hate that program because of its requirements but don't want to deny my son his play time ) as well as what I needed to get Process Explorer to work in place of Task Manager.

 

Yeah, it wasn't very smart from MS to only mention .EXE and .COM file extensions with regard to executable rules. It's quite misleading, really, when AppLocker rules in reality would apply to all file extensions, and even on files with no file extension.

I haven't looked into the auto-generate rules feature myself, but from what happened with you, it sounds like it only auto-generates executable rules for files with the .exe or .com file extensions. If so, then that's even less smart, considering that not all executables are .exe or .com... To be precise, was it the case on your system that auto-generate rules generated hash rules properly for open office executables that had the .exe file extension but did not create a rule for soffice.bin? If it didn't, then that's a big minus for the auto-generate rules feature.

The path rule would work, because it allows the entire folder and therefore everything in the folder, no matter what file extension.

 

Yes, it is misleading for me, anyways. But according to the screenshot, it really does imply only to .exe and .com extensions.

You could be right, at least in the case of hash rules. However, with Publisher rules, applicable obviously to signed files, I'm not sure how the auto-generate option is building them; as you can see, when creating Publisher rules manually, it is possible to adjust the slider for more or less granularity, depending upon one's preferences. The screenshot indicates the rule will apply to all files with the publishers signature.

That maybe is what happened but at least it was easily corrected using the Audit feature. Also, Publisher rules are the strongest. Path rules can be circumvented too easily (if they are created as Deny) and Hash rules need updating whenever the file(s) are updated through software updates. Furthermore, and this is the beauty of AppLocker, only the files included in the rule sets are allowed to run for the given user(s). All others in the specified directories not included in the rule sets are not allowed by default to run. However, I agree the Auto-generate feature could use some improvements to make it possible to generate specific Publisher rules, just as is possible with the manual method via the slider.

Yes, this makes sense, as even the Hash rule creation does not (seem to) create hash rules for other than .exe and .com files.

In all, Windchild, I don't really see any glaring weaknesses with AppLocker, though there is room for granularity improvements in the creation of rules. I'd thought SRP was very strong, and actually in a non-enterprise environment and especially just to be implemented on a home computer to stop unsolicited executable from launching, I still feel in this latter scenario it is strong. However, AppLocker is clearly a huge improvement, especially for IT admins, in securing the software environment on computers, even on a large scale.

 

AppLocker seems to be decently strong to me, as well - certainly stronger than SRP, and that was pretty nice by my standards already. And also easier to configure and audit by far than SRP. By my standards, AppLocker is certainly worth recommending and using.

However, there's typically always room for improvement, and I really think there should be a clearer mention that executable rules will affect all files whenever they're being executed, regardless of file extension. And auto-generate rules should apply to more than just .exe and .com, or stuff like this incident with soffice.bin will occur. Fortunately, the audit feature helps greatly with this, and in MS' defense, they do suggest in the docs to always use audit before actually applying the AppLocker policy to an important, non-testing environment. And the docs also explain that AppLocker monitors new process creation and DLL loading - not based on file extensions, but just the functions used to create processes and load libraries.

As far as path rules are concerned, in an environment where users have limited user privileges, path rules can be very much strong enough, assuming they have been created reasonably (such as allowing only the Windows & Proram Files folders where limited users cannot write and leaving everything else denied) so that users cannot circumvent them just by moving files around.

 

Yes, and because the rules are so stringently specific on what can run and where it can run, a user can even be prevented from running single file executables such as a screensaver, for example, so a user won't even be able to launch it on their desktop. I've tested this and it works as advertised

BTW, I've attached another boring, technical screenshot of the Process Explorer image properties of soffice.bin process. It looks like the parent process soffice.EXE launches it.

 

Re: AppLocker Anomaly

I don't like path rules for white-listing either(outside of program files folder), unfortunately AppLocker is not that flexible. I just noticed one of the programs I installed, FLV Player, writes some dll & ocx to temp folder, some of them have another extension. The only secure way to white-list them was to manually change their extension to .dll and use hash rule. As you've discovered, auto-generate feature only scans files by extension, so it wouldn't work here, but there is no auto-generate option for DLL rules anyway...