We're in the process of migrating from 4.5.6139 to 5.2.0225; thus far, the migration is going extremely well - with one bizarre issue haunting my sleep.
I started seeing this behavior about 2 weeks ago, on machines that (so far as I can determine) have not had any changes made (ie, the latest round of Windows Updates have not been applied, the machines are tightly controlled, no software has been installed). It also impacts some machines running CSA 4.5.6139.
However, it does not impact ALL machines - only we have a couple machines that are not impacted.
Versions of Outlook include 2000 and 2003; all machines are Windows XP Sp2, current with patches with the expcetion of August 2007 batch.
Scenario: user opens an e-mail, and right clicks on an attachment to save it. When the common dialog control for saving as comes up, the "My Computer" icon is missing - replaced with the "blank" generic Windows icon, and CSA triggers rule 576, saying that Outlook.Exe attempted to access Explorer.Exe, and was denied.
Additionally, the machine might display more icons as blank: for example, one of our admins has the ASA ASDM Launcher on his desktop, and that shows up with a blank icon in the save as dialog, and Rule 576 is triggered with "Outlook attempted to access ADSM.exe and was denied."
In attempting to get a handle on this issue, I have put the entire "Untrusted Classification Content Module" into test mode, reset the agent on a test machine, and still rule 576 is triggered - which strikes me as bizarre, if I understand the triggering conditions correctly.
Anybody have any thoughts?
This is not a showstopper, but I'm concerned because I don't understand why this rule has started to get triggered when we have made no change to our environment.
You may get this problem if you have antispyware installed in your machines. The reason why the problem appears all of sudden (ie. without doing anything) is because antispyware downloads updates and configures settings as required automatically. This in turn conflicts with CSA and so CSA blocks attempts made by certain software to explorer.exe since antiapyware is also monitoring this attempt and CSA detects it as malicious attempt. Removing antispyware may help you.
No, sorry - no antispyware.
The AV product we use (McAFee) is at the same version (engine, dat, and product) on both classes of machines (those displaying the icons and those with missing icons). It does not include the anti-spyware module.
What you are seeing looks like the result of the System State being set. CSA is preventing access to the desktop shortcut target file so it can't get the icon from it.
Find out why these files are being dynamically quarantined from Outlook and why on some machines and not others.
Try resetting the agent on one of these hosts and see if the messages disappear.
I'd also look at the Virus Scanner module for McAfee and make sure it's configured correctly.
You are correct; however, if I put the entire "Untrusted Content Classification Module" into test mode, and reset the agent on the offending machines, they still display the behavior. That's what I find _bizarre_; unless I'm missing something, that is the module which does the content classification, correct?
Virus Scanner is correctly configured; or at least consistently configured - managed via EPO, and set the same for all machines. Checked and double-checked.
Thanks. Much appreciated.
Hi Bob, since the set rule sets any file writes by Email as untrusted, the system state kicks in and triggers rule 576.
The "Untrusted Content Classification Module" is not associated with any policy (by default) and has no exceptions so you may need to create exceptions for Outlook.exe in the set rule since users are saving attachments.
The other rules in the Email Client Module - base security [V5.2 r225] should stop any questionable stuff or at least query the user.
Not sure I quite understand.
I'm looking at the MC, and see that "Untrusted Content Classification Module" is associated with the "Application Classification" poilcy, which is included as part of the "All Windows" group.
I was operating under the assumption that, since it is included in this policy as part of "All Windows", this was the module responsible for doing the content classification. Indeed, if I turn on logging for some of the rules, it's pretty active - and pretty active in setting e-mail content as "untrusted".
Rule 576, the one firing, is (according to the description), blocking access to @dynamic - dynamically quarantined files.
My thought was that I could create exceptions so that common stuff like "excel.exe" would not be tossed into @dynamic, and hence, Outlook could access Excel.Exe, and display the appropriate icon for spreadsheets.
But then I get all confoozled by the fact that I have some machines, with the same OS/SP/patch level, same AntiVirus, and same group membership in CSA, which do not exhibit this problem.
(If you read closely, there's a question buried in all the above. I just can't quite get it out due to my ignorance with how CSA is working it's magic.)
Thanks for taking the time to help with this.
Bob, you understand just fine. It is I who was confused. You are absolutely correct that the "Untrusted Content Classification Module" is associated with the "Application Classification" policy on an 'unmodified' MC. It appears I was a little too zealous (or tired) when cleaning up after the upgrade to 225!
Sorry for the confusing post.
Your other assumptions are also correct.
The exceptions should probably be in the set rule so that it doesn't set all files that the executables read as untrusted.
As to why some machines trigger the set rule and others don't, are there any other differences you can see as far as groups and rules go?
Did you do a clean install of 225 or upgrade from 203 or 210?
Now, while I go restore the deleted policies to my pilot MC... ;-)
Migrated from 4.5.6139 to 225.
The machines are in the same group.
You really didn't think it would be that easy, did you? :-)
I'm not sure about the exception: what seems to be happening on the affected machines is that if a user has, e.g., a shortcut to a Remote Desktop Connection on the desktop, and goes to save an attachment to the desktop, we see Outlook attempting to access MSTSC.EXE; if there's a shortcut to an Excel workbook, we see Outlook attempting to access EXCEL.EXE. These attempts are being denied, and the shortcuts/files are displayed with the "no icon" icon.
So...since there's any number of possible types of items which might be displayed in the "Save As" dialog, I'd basically have to write an exception which permits OUTLOOK.EXE to access anything...and I'm not sure I like that a whole lot.
I've even gone so far as to check versions of the "save as" DLL, the common dialog dll. Of course, they're identical across machines.
Hi Bob, I hope I'm on track here...
I think the key will be to find out what is putting files in dynamic quarantine and stop that. You shouldn't need to make exceptions for everything Outlook accesses.
I've been running the untrusted content classification, email and document security modules with Outlook and GroupWise and though it classifies many files as untrusted, it never quarantines them.
What is listed in your quarantine?
You might try cleaning out the legitimate files (if present), forcing an agent poll and see if that stops it.