locked
EMET 4 in Win 7 64 VM under VirtualBox 4.2.10 RRS feed

  • Question

  • Not a happy experience. In no particular order:

    Phantom CPU usage, i.e. guest OS reports constant 30% CPU usage that doesn't seem to be attributable to any process. This can be caused by transient processes, and indeed, there were instances of mscorsvw.exe appearing and disappearing.

    All Office 2010 executables failed on start, but without EMET notifications.

    The obese .NET 4 went back for dessert, causing a slew of updates that never completed.

    The only protected executable was firefox.exe, which wasn't doing much.

    Could not get much info on the behaviour of DEP, or indeed any other mitigation, under a virtual machine, although I suspect that DEP works only on the host OS. Without time to investigte each mitigation, I had to roll back the whole EMET installation.

    I still think EMET is probably a better bet for a lot of VMs than old fashioned pattern matching virus checkers, but we need more testing and info.

    The lack of a setting to apply mitigations to any unknown executable is a shortcoming, imho, that should be easy to fix. Or am I missing something? A mask for *.exe doesn't make intuitive sense to me and I haven't tried it, not least because I don't know what order the masks are applied in.

    Thanks!

    Saturday, October 5, 2013 12:47 PM

All replies

  • > Phantom CPU usage, i.e. guest OS reports constant 30% CPU usage that doesn't seem to be attributable to any process. This can be caused by transient processes, and indeed, there were instances of mscorsvw.exe appearing and disappearing.

    So, no problem with EMET itself? But: The EAF mitigation is often a problem in virtual environments: http://social.technet.microsoft.com/Forums/security/en-US/2e65d8ef-b76d-4488-8063-53632ed90456/eaf-mitigation-still-bloody-slow-in-hyperv-guests-with-emet-v4-beta?forum=emet

    > All Office 2010 executables failed on start, but without EMET notifications.

    Office 2010 in general is compatible with EMET. Maybe it is a 3rd party add on or other incompatible software. You may disable EMET and check for example with Process Explorer which additional modules are loaded.

    > The only protected executable was firefox.exe, which wasn't doing much.

    ?

    > The lack of a setting to apply mitigations to any unknown executable is a shortcoming, imho, that should be easy to fix. Or am I missing something?

    Yes, you missed that this is documented in the EMET 4.0 User Guide: "Please note that wildcards are only accepted in the path portion, and are not valid in the executable image name itself. For instance “wmplayer.exe” or “*\wmplayer.exe” are valid paths, while “*player.exe” or “*wmplayer.exe” are not. This is due to a limitation of the Application Compatibility Framework in Windows that EMET relies on."

    Monday, October 7, 2013 9:09 AM
  • Thanks for the pointers. I think you are right, most of my problems relate to .net. When I get some time I will try again. Looks like EMET is a sensible option if you have time to optimize and if you have total control of the environment.

    I forgot to mention that I am running EMET 3 on Win 7 32 under VirtualBox without problems.

    Sunday, October 13, 2013 7:09 PM