wwarren schrieb:
Hi Everyone,
Here's a thread to potentially spur some discussion
In the coming release of Patch 1 for VSE 8.8, we will be introducing a new Access Protection rule that will be enabled by default.
The rule protects certain McAfee processes from DLL injection, which is a technique used by malware that allows the ill-intentioned code to then run inside a McAfee process. And since certain security measures "Trust" our own McAfee processes, the malware is then allowed to perform some pretty darstedly deeds... like terminating a scanner.
With the new AP rule, this technique will not be possible - for certain critical processes of ours, like scanners.
But this DLL injection technique is used by many a legitimate 3rd party application too. Often leveraging it to gain insightful information about the processes they inject into, perhaps for application metering, usage monitoring, encryption, and more. Those legitimate applications will be prevented from injecting into our process...
I hope with this AP rule we can get rid of those mfehidk-Warnings with VSE8.8 installed?
akl71 wrote:I hope with this AP rule we can get rid of those mfehidk-Warnings with VSE8.8 installed?
Yes, it will. They will no longer occur because the 3rd party will no longer be able to inject our VSTSKMGR or scanner processes.
What 3rd party applications have you noticed are interacting with the McAfee processes in question so far?
I recall seeing lots of AP events from WSRM.exe which seems to have a penchant for attaching to running processes with a read/write handle.
Matt
robpow wrote:
What 3rd party applications have you noticed are interacting with the McAfee processes in question so far?
I recall seeing lots of AP events from WSRM.exe which seems to have a penchant for attaching to running processes with a read/write handle.
Matt
There have been less than 10 by my count. Citrix has been the most popular, injecting no less than 12 of their DLLs into our processes.
The frequency with which you see our Event log entries, warning of the 3rd party code inside our process, is dependent on how active the 3rd party code is. Every time their code does something, it runs through our validation code - we see it's not our code that's executing, and log an event.
Blocking the 3rd parties from injecting our process will put an end to those events.
What we don't know is how those 3rd parties will then react. We expect they'll fail gracefully, but it's up to you to verify their behavior and make sure it's "OK" for you to have our new AP rule enabled. Just remember it's an essential rule to have enabled if you wish to be protected against the latest of malware threats.
When can we expect 8.8 P1 ?
We are reworking the schedule as I type, actually. This new set back will likely put us toward end of August perhaps into September for the RTS release date.
Keep in mind the general availability release (where we post the patch to the web) is expected about 4 weeks later.
This has some impact too for the 8.7i hotfix we were planning to release Aug 11 - it's expected the release of that fix will now be toward end of August also.
In the interest of quality we will keep these fixes as long as we need to, so we hope it's understood that any delay on our part is because assessment of the issue warranted the time needed to address it.
Thanks William,
Can you confirm that this issue will be fixed in the Patch 1:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
Apart of mfehidk warnings issue we also experience scriptscan errors as wek keep ss disabled due to performance issues. Unregistering the DLL helps.
Is P1 readme already available?
Regards
Piotr
Can you confirm that this issue will be fixed in the Patch 1:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
Patch 1 will address that issue.
The readme is not expected to be added to the KB until the managed release begins, end of August being the expected timeframe there.
Hi,
are there any updates regarding RTW date of Patch 1?
regards
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA