Emsisoft and DEP+ASLR

[Guest Tempus]

Hi

 

 

Does Emsisoft anti malware take advantage of Dep (DEP prevents data from being executed) + ASLR (making it more difficult to predict the location of code within memory) ? With other Words, is Eam. coded to take advantage of these  two features ? If not, then why not? Wouldn't it be an advantage against exploits?

My question came after reading this blog: On the effectiveness of DEP and ASLR

 

Thanks

 

Jan

 

 

 

 

 

[Insert Real Name 1]

I'd like Emsisoft tech support to also address the related question of the compatibility of running Microsoft's "Enhanced Mitigation Experience Toolkit 4.1"  with Emsisoft's Anti-Malware. This Microsoft software allows the user to opt-in potentially exploitable software (e.g. that access the Internet) to an extended range of enhanced anti-malware protections (ASLR, DEP, heap spray, anti-detours, etc.) and it does this by injecting itself into the running programs and by monitoring and limiting the hooking of system APIs.

 

I'd be really happy if the Emsisoft developers would take some time to look at this additional mitigation software and determine if there are any conflicts with using it concurrently with Emsisoft Anti-Malware. What protections are already implemented by Emsisoft and what protections will interfere with Anti-Malware's own functioning?

 

I'm attaching the User Guide for the Microsoft EMET 5.0 Technical Preview

[Pilis 3]

According to Process Explorer and SlopFinder these files have ASLR enabled:

• BlitzBlank.exe
• a2acc.dll
• a2contmenu.dll
• a2contmenu64.dll
• a2core32.dll
• a2core64.dll
• a2dix86.dll
• a2engine.dll
• a2hooks32.dll
• a2hooks64.dll
• clean32.dll
• cleanhlp32.dll
• evcdiff.dll
• frme32.dll

And those files have not:

• a2service.exe
• a2start.exe
• a2wizard.exe
• a2cmd.exe
• a2guard.exe
• a2HiJackFree.exe
• a2framework.dll
• a2mor.dll
• a2update.dll
• a2wsc.dll
• avxdisk.dll
• bdcore.dll
• logging.dll
• quarantine.dll
• resource.dll
• a2accx64.sys
• a2accx86.sys
• a2ddax64.sys
• a2ddax86.sys
• a2dix64.sys
• a2dix86.sys
• a2util32.sys
• a2util64.sys
• cleanhlp32.sys
• cleanhlp64.sys

I guess the Emsisoft-guys know what they are doing and the most important files which interact with "attacker code" have ASLR enabled. Not sure of the reasons why not also enabling it for the other files though. (Stability? Compatibility?)

[GT500 813]

I personally haven't tested the Enhanced Mitigation Experience Toolkit, however I don't know of any reasons why it wouldn't work with our software (I know some of our customers do use it). That being said, there have been cases where EMET have been bypassed, so it may not be as great as Microsoft claims.

As for DEP, it is a technology that is implemented by operating systems and processors (or at least certain DEP features require processors to have certain features). It has been a part of Windows since Service Pack 2 for Windows XP, and all versions of Windows that our software runs on have it. You can read more about it here.

For more information than that, a developer would have to reply.

[Guest Tempus]

Thanks Gt500 for your answer, it's appreciated . Thanks Pilis, I wasn't aware of " SlopeFinder " Yes it do seems that some of the file has ASLR enabled. But as to my understanding, then must Emsisoft anti malware specifically be configured  to take advantage of DEP and ASLR. So my question was basically, in what extent was Emsisoft using the benefits of Dep and ASLR. (which are an  excellent layer against exploits).

Thanks

Jan

[Insert Real Name 1]

Thanks for the answer re. Microsoft EMET. EMET was something I was using with Microsoft's MSE before I switched to Anti-Malware (MSE's detection rates have really gone down in the last two years), so I just wanted to know how many protections they had in common, based on Microsoft's published documentation, and if they would tangle each other up... Maybe I'll try a test.

[Pilis 3]

But as to my understanding, then must Emsisoft anti malware specifically be configured  to take advantage of DEP and ASLR. So my question was basically, in what extent was Emsisoft using the benefits of Dep and ASLR. (which are an  excellent layer against exploits).

As to my understanding you simply build a PE-file with the linker option "/DYNAMICBASE" (and optionally "/HIGHENTROPYVA" for 64-bit files). That's basically it. ASLR has now been "enabled" for that file and Windows knows to load it at a randomized address.

I've listed you all of Anti-Malware's PE-files which either have that linker option or don't. I'm not sure what you could "specifically configure" more. The only thing I could think of is using the new Force ASLR feature but that doesn't really make sense since Emsisoft won't just load unknown dlls. Also compatibility.

Of course you could use EMET to manually force an executable to use "Mandatory ASLR" (which actually only forces address space randomization on dlls loaded by a process) but I wouldn't recommend that on using it on security software. Better use the supplied list of recommended processes. That way I'm using EMET in combination with Emisoft Anti-Malware since a long time without any issues.

[GT500 813]

... But as to my understanding, then must Emsisoft anti malware specifically be configured  to take advantage of DEP and ASLR. ...

I'm fairly certain that that's not the case for DEP, and that the operating system takes care of protecting memory (Wikipedia's explanation of DEP makes it sound this way at least). That being said, the types of exploits that DEP was created to protect against are very old, and anti-virus software typically has completely different threats to worry about.

As for ASLR, I'm fairly certain (and please keep in mind that this is coming from the perspective of someone who is not a developer and is not privy to all of the technical details about how this works) that that would be impossible for a2service to really make use of, because the way a2guard and a2start interface with it is by reading and modifying its memory (which is, as I understand it, pretty much an industry standard in security software).

[Guest Tempus]

Thanks Guys, GT500 and Pills, for shedding some light over my posts. What I have done for now, is to do a complete up to date Image backup of my system, and have downloaded and installed Emet. version 4.1, and sat it to "Recommended Settings". There may be something more that I would like to add to Emet later , but for now I will test (and learn) it for a period (in recommended settings), to see how it will behave and interact with my overall systemkonfiguration.

Thanks

Jan

[GT500 813]

You're welcome.

[hackerman1 6]

I have been using EMET together with EAM for months and I have not noticed any problems.

I tried to find information about configuring EMET for EAM, but since I could not find any I decided to instruct EMET to ignore EAM.

I see no reason to let EMET mess with EAM´s processes (a2guard.exe & a2service.exe)....

And I have also added exceptions for EMET in EAM.

[Guest Tempus]

I had come to the same conclusion as you, after the feedback that I received from the above posts.The only thing that I might what to add to EMET, is my Twitter and Skype. But then again, then I don't think it is necessary, because I use those programs from Windows Metro interface. And they are already isolated, in app containers,so that has to be enough, I guess. I have not created exceptions for EMET in Eam, but it is definitely a good approach, thanks for the idea. But for now I will let it run in recommended settings, until I have a better understanding of what I'm doing. Thanks for your post " hackerman1 "

[hackerman1 6]

Have you checked what the "recommended settings" are ?

I´f I remember correctly EMET sets several if not all options to On (active) for EAM´s a2guard.exe & a2service.exe

[Guest Tempus]

Yeap " hackerman1"   , checked the recommended settings, as soon EMET were installed, see image. I can see the two processes running in Emet's main window. " a2guard " and " a2service ". But those are not set to run under EMET's protection. And as you write, then I think like you, that those are best to be left as there are. If I should run into some compatibilities issues, then I will place EMET in the " Manage Whitelist " under the tab " Fileguard ", i would guess . Btw I received a heavy manuel, 42 pages, with the download. So now I am trying to bend my brain around all the technical stuff. My frontal lobe hurts, but in a pleasant way.  

 

 

Download Image

[Fabian Wosar 390]

The main issue is, that a lot of our executable files are not built using the Microsoft tool chain (Visual Studio). So it is not as easy as adding "/DYNAMICBASE" simply because that parameter doesn't exist in development tools outside of Visual Studio. All files that are built using the Microsoft tool chain have both DEP and ASLR already enabled. The files that don't have DEP or ASLR enabled are files that are built with a tool chain that does not officially support DEP or ASLR.

[Guest Tempus]

The main issue is, that a lot of our executable files are not built using the Microsoft tool chain (Visual Studio). So it is not as easy as adding "/DYNAMICBASE" simply because that parameter doesn't exist in development tools outside of Visual Studio. All files that are built using the Microsoft tool chain have both DEP and ASLR already enabled. The files that don't have DEP or ASLR enabled are files that are built with a tool chain that does not officially support DEP or ASLR.

Somehow it has slipped my attention, that you have given a fine explanation. Thanks Fabian Wosar, and sorry for my late response.

[hackerman1 6]

The main issue is, that a lot of our executable files are not built using the Microsoft tool chain (Visual Studio). So it is not as easy as adding "/DYNAMICBASE" simply because that parameter doesn't exist in development tools outside of Visual Studio. All files that are built using the Microsoft tool chain have both DEP and ASLR already enabled. The files that don't have DEP or ASLR enabled are files that are built with a tool chain that does not officially support DEP or ASLR.

Thanks.

 

I have been using EMET together with EAM for months and I have not noticed any problems.

I tried to find information about configuring EMET for EAM, but since I could not find any I decided to instruct EMET to ignore EAM.

I see no reason to let EMET mess with EAM´s processes (a2guard.exe & a2service.exe)....

And I have also added exceptions for EMET in EAM.

 

I know that EMET is not created by Emsisoft, but do you have any recommendations for how EMET should be configured ?

Should it ignore a2guard.exe & a2service.exe ?

And should it be configured for any other EAM-files ?

 

And since your post above is from April 2014, and newer versions of EAM has been released since then, has there been any change regarding DEP & ASLR in those versions ?

AV-test.org published a report about the use of DEP & ASLR in antivirus software on 2014-11-25

Self-Protection for Antivirus Software: http://www.av-test.org/en/news/news-single-view/self-protection-for-antivirus-software/

 

Unfortunately EAM is not included is that report, so it would be very interesting to hear about EAM´s use of DEP & ASLR.

[Fabian Wosar 390]

We only test EMET with default settings. If you want to tinker with its settings, you are on your own. All Emsisoft components support DEP and ASLR since version 9.0.

[hackerman1 6]

We only test EMET with default settings. If you want to tinker with its settings, you are on your own. All Emsisoft components support DEP and ASLR since version 9.0.

 

Thank you.

But, what exactly are the "default" settings ?

Do you mean everything checked for both a2guard.exe & a2service.exe ?

And, are we talking about EMET 4.1 or 5 (5.1) ?

To make sure we all get it right, It would be very nice if you could post a screenshot of the correct "default" settings.

[Fabian Wosar 390]

But, what exactly are the "default" settings ?

Do you mean everything checked for both a2guard.exe & a2service.exe ?

No. Default means the settings you get after running the wizard and choosing "Use recommended settings". We do not test how certain a EMET mitigation effect any of our own processes, but we do make sure that we don't interfere with protections put in place by EMET in other processes that we monitor as well, as EMET and our behavior blocker use very similar techniques to intercept code flow that often result in incompatibilities.

And, are we talking about EMET 4.1 or 5 (5.1) ?

We always test with the latest stable release which is version 5.1.

[hackerman1 6]

No. Default means the settings you get after running the wizard and choosing "Use recommended settings". We do not test how certain a EMET mitigation effect any of our own processes, but we do make sure that we don't interfere with protections put in place by EMET in other processes that we monitor as well, as EMET and our behavior blocker use very similar techniques to intercept code flow that often result in incompatibilities.

We always test with the latest stable release which is version 5.1.

 

That was the reason for asking, as i thought there might be Incompatibilities between EAM & EMET.

I did run the wizard when I installed EMET, but since I wasn´t sure that those mitigations really should be checked, I unchecked all of them.

And I didn´t save the recommended settings because I was hoping to get the needed information from Emsisoft....

 

But, what exactly are the "default" settings ?

To make sure we all get it right, It would be very nice if you could post a screenshot of the correct "default" settings.

 

Could you please list the settings or post a screenshot ?

[hackerman1 6]

I just ran the wizard again.

The recommended setting in EMET 4.1 is everythinh checked for both a2guard & a2service.

But then EMET block EAM....

I get a notification from EMET: SimExecFlow mitigation for a2guard....

Now I remember that being the primary reason for unchecking everything.

So a list of the settings or a screenshot are appreciated.

[Fabian Wosar 390]

This are the default settings and the only settings we test with:

Adding any of the EAM processes is not covered by the defaults. As I said before, we do not test whether EMET protections interfere with our processes (they very well may). We test whether or not our behavior blocker interferes with EMET in other processes that are included in the default EMET settings.