Wondering if anyone has seen or heard of the following scenario. I have several users running HIPS V7.0 patch 6 also running IE6 or IE7. Users can access IE product either through a desk top shortcut, command line with the -extoff command or through Start-Programs, etc. Clean image, new installation, brand name equipment. The URL shortcuts also launch a printer dialog box. IE8 as a test works fine. Thing is can't use IE8 in the production environment. Also cannot use P7 for HIPS. Same reason. Problem reproducable and when system wiped clean and reloaded connection allowed once then same behavior. As a test policies were set to just about everything wide open. Still blocking. Read KB articles about HIPS still blocking even though software says otherwise. Also ran several of the KB's regarding blocking and gathering system information. KB54960, 60078,51699,51577,etc. Verified MS patches on both system and server are latest for system. All current MS and McAfee patches installed. Can obtain screen shots to post. Anyone seen anything like this or similar.
Yes, yes, yes yes a thousand times yes.
We have been rolling out Windows XP (don't ask) with IE7 and HIPs. It breaks IE7. McAfee cannot find a solution for us so far. If you disable HIPs(i.e. permanently disable in the services) and reboot the system, you will find that IE7 works correctly and your shortcuts and the IE7 Desktop icon(if you force one on the desktop) will work without any updates.
The only thing I can figure is that somehow McAfee HIPs is not handling the DLL IEFRAME.DLL correctly. IEFRAME.DLL is one of the main DLL's for IE7 and replaced SHDOCVW.DLL from IE6. Strange thing is IE8 works for us as well and we cannot migrate to IE8.
If you remove the registry entry called LegacyDisable from the IE entries your shortcut should not launch a printer dialog box again.
This should not be a requirement for IE7 to function as intended but whatever the DLL does when those entries exist, HIPs is not allowing it to happen.
Please help McAfee.
we are highly "interested" in this type of problem, because our organization will be introducing intrusion prevention later this year in an IE6 and IE7 environment. A possible evaluation fragment for McAfee HIPS could be to find out about the possible details of this problem of yours.
Would you please detail it in a technical sense? (screenshot, error log, etc.)
I'm not trying to investigate your problem, because we do not have a working copy of HIPS client and cannot compare, but would like to see how a problem is manifesting with using this product. And others here might need it anyway.
(I assume you are managing HISP with ePO. Could you please also tell us the rule name that triggered if any, or the portion of the firewall configuration, if any, relevant to this problem? Thank you.)
AttilaMessage was edited by: Attila Polinger on 4/6/10 5:45:07 AM CDT
I am not sure I can help with the ePO stuff as I am on the other side (i.e. the workstation architect). If you have specifics I can ask the ePO Admin to screen shot me some pics possibly. For us, what happens is if we "enable" HIPs, the IE7 Desktop Shortcut do not function properly when the default IE7 registry settings exist.
If the aforementioned registry settings exist (which do with a default IE7 installation), we have the following issues:
IE7 Desktop Icon will look like Problem #1 in the Word Document attached and will just create shortcuts to the IE7 Desktop Icon and never launch IE7 at all.
URL Internet Shortcuts will look like Problem #2 in the Word Document attached and launch the Printer Dialog box when invoked. Note that the 'pretty' favicons from IE7 disappear as well.
If you delete the "legacydisable" keys, the 2 problems will go away but the favicons will not return. Also, if you go into Tool/Options Advanced Settings of IE7 and "reset" to manufacturer defaults, then the problem will recur as the "legacydisable" keys return with that new feature that Microsoft has provided for IE7.
Mind you that IE7 launched from the Quick Launch Bar and from the Start Menu work as intended without any issues.
Also, our latest issue is when launching an HTA file from an intranet Web URL, the compiled HTA program will not launch unless we disable HIPs (maybe that is a feature :-) )Message was edited by: carlsot on 4/6/10 2:13:36 PM CDT
You mentioned trying KB54960 - Isolating a suspect Component, yet you didn't mention the result.
Try excluding iexplore.exe from Application Protection list. Refer to KB67056 which is posted in the HIP Blog section.
If the issue goes away when IE is excluded from hooking, then follow the instructions to obtain a process dump while IE is in the state of failure.
A better option is if the issue can be reproduced locally off your network. Is the prionter dialog box from an app on the local machine?
If yes to both, create a VM image per https://kc.mcafee.com/corporate/index?page=content&id=KB60323.
Then open a support case.