Endpoint Protection

Hi all,

Just to draw everyones attention to a flaw with Symantec Endpoint Protection Application and Device Policy rules - I have "Stop Software Installers [AC8]" enabled in SEPM, and this works well - stopping installations from running. This also stops executable files being saved anywhere (i.e. users documents, downloads etc.). Google Chrome, however, seems to allow users to circumvent this - if one downloads an executable installer in chrome and runs it from the downloads bar at the bottom (NOT the location where it has downloaded to via Windows Explorer - see picture below), the installation will be allowed and the program will install correctly! This even allows executable files to be saved (though SEP kicks in if I were to attempt to make a copy of the file)...

Has anyone else experienced this? If so, any way to fix? Or is it worth logging something with Symantec on this?

Windows 8.1 Professional, SEP Client 12.5337.5000, SEP Manager 12.1.4104.4130

Thanks,

Kim

Would need to see the rule details as it may need to be tweaked for Chrome.

If you cannot share then I would log a support case. I'd be surprised if this was a bug/defect. ADC is quite flexible in what it can do.

I have ADC configured as follows:

ADC exception to allow svc host to create, delete or write exe or dll files:

And AC8-1.1 - as shown above:

AC8-3.1 is as follows to prevent creating, writing and deleting .exe and .dll files for all other applications; which is what should stop Chrome writing exe files when downloading applications - it's this that isn't working properly for Chrome (works for IE and Firefox though!)...

And the corresponding actions:

I can successfully implement a rule that stops Chrome launching; but this isn't what I want - it needs to stop Chrome writing exe files / launching downloaded exe files (i.e. launching subprocesses - though Task Manager doesn't list downloaded executables as subprocesses of Chrome; so Chrome also shouldn't be able to launch processes in general)...

So this is the stock rule, no changes were made, correct? Want to make sure I'm testing correctly....

So I just tested this with the stock rule and it failed:

What am I missing?

I think it's the stock rule - I've included a screenshot of both the actions and properties sections.

The only exception is for svchost - as the screenshot above shows.

That's the one I'm using. It fails for me on Chrome so I'm not sure what I'm missing or doing differently compared to you?

I just tested this rule and tried downloading an exe file and it failed for me too.

Check to see if you have a rule in the ADC policy that is above the AC-8 that is set to allow this action.

You Can also try enabling logging for all the actions (allow / block / continue with next) in all the rules of the ADC policy and then check which rule is allowing the download before even the AC-8 rule is processed.

EDIT: Please ignore this duplicate comment. The page expired and so I added it again.

I just tested this rule and tried downloading an exe file and it failed for me too.

Check to see if you have a rule in the ADC policy that is above the AC-8 that is set to allow this action.

You Can also try enabling logging for all the actions (allow / block / continue with next) in all the rules of the ADC policy and then check which rule is allowing the download before even the AC-8 rule is processed.

That's the thing! It doesn't work for Chrome - as can be seen, it stops IE saving exe files, but doesn't even recgonise Chrome trying to save these - they succesfully get writtent to the Downloads folder. Could be because chrome downloads them as CRDOWNLOAD files first then renames then when the download is successful? (Although this doesn't work when I try to change the extension of a TXT file to EXE, so I don't see why this works for Chrome!)

I will try creating a new policy and simply applying the default "Stop software installers" rule and update with results.

Not sure what you mean? I've tried in IE, FF, and Chrome and all three are blocked. Even Chrome as per my screenshot above. Nothing is downloaded to my Download folder when tried in Chrome. So I guess I'm confused.

That's strange! Still not working for me; IE and FF are both blocked from writing / executing exe files, but Chrome allows them! What version of Chrome are you using? I'm on 43.0.2357.130 m

This is with the default settings on application and device control by the way, so no changes by me at all. It is being applied to the group successfully, so that's not the issue.

Will log a case with Symantec Support though as it looks like this is quite an issue.

Thanks Brian for your assistance anyway, much appreciated :)

Kim

Have continued to test with all three browsers and all are blocked :) so can't say for sure. I would say it could be some policy corruption or something along those lines but I would expect all three browsers to have the same results. Could always aplpy a new policy and see what that does.

Support should be able to help as well.

I guess that Chrome.exe (or any other file related to chrome) is being excluded from Application control in the centralized exceptions policy.

Check the centralized exceptions policy for the followings.

1: Check if any folder related to chrome is excluded from "All Scans" (Exclusions added for "All Scans" includes Application control).

2) Check if an application exception is created for the chrome executables as mentioned in the following lilnk.

http://www.symantec.com/docs/HOWTO95454

If you are not sure, create a new centralized exceptions policy (with no exceptions) and assign it to the test client and check if application control is then blocking the downloads.

Hi,

Thanks for your reply - I have created a new ADC policy with default settings and this didn't work.

There are no exceptions configured in the Exceptions policy; and clients aren't permitted to exclude items from scans.

Thanks,

Kim

Did you also check if there are any exceptions already added on the client side?

Just checked and no exceptions added client side.

Do you have system lockdown turned on in "Whitelist mode"?

The only thing at this point that would make sense is some sort of exception.

Also, are you on the latest version of Chrome?

I'd typically recommend enabling logging on all Application Rules to see which one is allowing Chrome to write, then figure out why it's matching it.  Obviously, this goes a lot faster if you first disable any/all rules apart from the one you want to test too.

How would I go about doing this? Do I have to manually go into each rule and choose to log in the actions section or is there an easier way to do this?

Thanks

That's the way to do it, and there's no shortcut AFAIK.  Though this logging only needs to be done on the enabled rules (and if I were you, I'd disable all rules except the "software install" one to be certain that it's actually that rule that's causing the issue).

Nothing is logged when the exe is downloaded by Chrome. Is there a way to log all file writes attempted?

Opera is blocked from creating the exe file on the disk - so the rule is partially working.

This is a big problem! Support haven't responded to me yet, so the issue is still ongoing. I've had to block users opening Chrome for now until this vunerability is fixed.

On my system, all write attempts are logged for Chrome or any other browser like I would expect. I'm not sure why this is an issue for you but I would get back to support and advise them that this is a critical issue for you.

That's kind of the point really, the fact that nothing is logged means it's not hitting the rule you expect it to hit (or it's a bug that affects only you).  In order to find out which rule it is hitting, you need to enable some additional logging.

As you have already tested this with a new default ADC policy (with only modifying the AC-8 rule), I believe that the issue is not caused by a different rule in the ADC policy.

Create a new (blank) centralized exceptions policy and assign it to the affected client and test it.

Thanks for this one - I didn't think about logging on the default (pre-added) exception for the svchost process - never thought that Chrome would attempt to use svchost as indicated by my log screenshot below!

Adding logging for all ADC rules is a good way to go for future issues like this :)

Right! Result - As I was working with a brand new default policy (including an unmodified ADC rule set), I wasn't logging the default svchost exception. I enabled logging for this (most sensitive "Info - 15" level), which allowed me to find how this bypass was happening...

The logs showed that Chrome was calling svchost.exe for the write of the file (strange way of doing it!):

To fix, I added an exclusion to the default AC8-1.1 rule as follows:
 

This has worked for the test group, so changes have been made for all production policies...

Thanks for all of your help everyone :D

Kim

Looks like the default rule had been modified. Mine is significantly different.

That's interesting! What version of SEPM are you using? When I create a new ADC policy, the TrustedInstaller and svchost processes are automatically included in the "Apply" box.

I should've mentioned the dllhost rule exception is one I added previously to assist with a few problematic driver installs. It's presence previously didn't affect the issue.

To clarify, the exception I added was for the following process:

%programfiles(x86)%\Google\Chrome\Application\chrome.exe (added with all defaults selected)

Ignore the dllhost exception - this is one I use on all policies to aid problematic driver installs!

12.1.5.

Not sure what version you're but if lower it could be that rule was updated in later versions.

I can confirm that 12.1RU6 has the same sort of settings that Brian has in 12.1RU5, but in theory this situation would have happened regardless (as that allow for svchost is still there).

It sounds like it was chrome that went nuts in your case (or some sort of config change perhaps?) as Brian's screenie earlier clearly shows his Chrome is saving files via the chrome.exe process rather than getting svchost to do it.

Yes, that sounds about right - I saw this in Brian's screenshot, hence it never crossed my mind to log the default svchost exception.

I need to update my SEPM install anyway, so will address this and see if the issue resurfaces with a default rule after the update.

Thanks for your assistance.

I'm on 12.1.4; though have just started the inline update to 12.1.6. I will experiment with default policies after the update has completed - though as SMLatCST suggested, it could be Chrome attempting to do something silly after it's latest update.