Endpoint Protection

Hi all,
Using SEP 12.1.1000.157 I have a situation where the Application and Device Control Policy is blocking the installation of Adobe Acrobat Profession 9 on Windows 7.  The issue is, even though I exclude the legitimate key that the install is trying to create, the install is failing because it cannot create this last key.  I’ve already successfully excluded some other registry key that Acrobat Pro 9 needs to write; but this last one is kickin’ my pants.

The App rule is "Prevent registration of new Toolbars (HIPS) [AC16]".  Condition AC16-1.1 is applied to the following registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Toolbar\*\*
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Toolbar\*\*

The conditions above correctly do their job and prevent writes to those keys.  However, a legitimate key that Acrobat Pro 9 tries to create needs to be excluded so it can be written.  During installation, Acrobat Pro 9 errors with "Error 1406.  Could not write value {47833539-D0C5-4125-9FA8-0819E2EAAC93} to key \SOFTWARE\Microsoft\Internet Explorer\Toolbar.  Verify that you have sufficient access to that key…"

I have tried multiple combinations for the condition AC16-1.1 in the "Do not apply to the following registry keys", but to no avail.  The only way it does install is if I disable the condition or remove the keys from the list that are being protected – but that would defeat the purpose of this App & Dev Control rule.  In other words, wildcards are necessary because you want to catch any bad write.  But then how do you get it to allow a certain legitimate key in the same path?

Thanks, Tom.

hi,

Do you have tried Disable SEP antivirus ?

The problem boils down to the inability of Application Control to differentiate creating a registry key from accessing one.

I don't think you can overcome that by changing the condition.

The best idea I have so far is to take a test PC and change the AC16 rule to "Allow Access" with simultaneous logging. Then install Adobe 9. After that, examine the control log at the client to get the application that wrote the registry key (probably Adobe 9, but you never know).

Then put AC16 to "Block Access" again and add the exact program name of Adobe 9 (or the app that wrote the key) to the exclusions at the rule level ("Do not apply this rule to the following processes"). Until now, there are just two pre-defined Symantec entries.

Of course, that only makes sense if the exclusion doesn't allow too much.

HTH!

I'll see about trying that.  If I remember right, the .EXE that is running that tries to create the registry key is msiexec.exe!  But with your idea I may be able to fool it somehow.  Thanks.

Hmmm ... what about a special allow rule in AC16 for msiexec.exe to write this particular registry value?

msiexec.exe must be at the rule level and the registry value in the condition. Action is "Allow Access".

This allow rule should be placed above the blocking rule.

Just an idea ...

Good luck!