NOD and DEP/ASLR

somebody pointed this article about most AV software ignoring and not using these 2 built in security features from Windows.

astonishing and disappointing that neither NOD's executables nor dll are DEP/ASLR protected. wondering if they were ASLR enabled whether NOD would still crash on my system during in-depth scan whilst self-defence enabled (does not crash with self-defence disabled)?

from the article

 

Re: NOD and DEP/ASLR - use of Enhanced Mitigation Experience Toolkit 2.0

would it harm usability/stability or enhance security of NOD to deploy MS Enhanced Mitigation Experience Toolkit 2.0 settings?

 

Re: NOD and DEP/ASLR - use of Enhanced Mitigation Experience Toolkit 2.0

I'd like to know this as well.

 

Re: NOD and DEP/ASLR - use of Enhanced Mitigation Experience Toolkit 2.0

ASLR is not going to do anything for you if you're having crashes under a scan. Likely situation is a hardware problem or some kind of software conflict. As for the feature itself, it is up to Eset to compile their binaries to support it. It is only going to help protect against things that try to exploit the Eset kernel directly, and I don't really know how common that is. Usually they will use other vectors to exploit and run code with admin/system rights that then compromises your AV software. It's something of a common sense thing to impliment it, but there really isn't a big rush on that because the risk is small. It is far more important for end-user apps like your browser, office suite, browser plugins, and whatever else being compiled to use ASLR because that is where things are going to try to come through the door.

As for DEP, just change your workstations to OptOut mode if you can. Starting with Server 2003 SP2, all of Microsoft's out of the box server DEP configurations have been set to OptOut mode while the desktops run in OptIn. I frankly don't buy the line about their testing matrix in this case because the server OS's have running with it forced on for years now. And especially in the case of the Win 6 kernel, the desktop and server kernels are now identical. But once again, DEP (and also SEHOP) is far more important when it comes to the programs that users are actually running and are the likely sources of exploit execution, not so much the AV kernel.

 

not sure whether I can follow you there:

is there a proven record that NOD is crashing with ASLR applied? How is ASLR causing hardware problems/software conflicts? ekrn.exe is not even using DEP nor ASLR.

that I highly doubt since dll can be attacked too, and neither the NOD kernel nor the related dlls are featuring ASLR.

from what I know there is quite a few malicious stuff out there being able to suspend/crash/stop various AV software, once the malicious code made it into the system. and even the entering and breaking is not that uncommon, seeing in the forums by what is getting past NOD in the first place.

basing you risk assessment on what? that the number of 0day exploits is decreasing?

DEP OptOut/always-on may conflict with some software on a workstation, on my W7 64bit it did e.g. with the Safari browser, reverting to OptIn solved the issue

 

Ok, to clarify

• I am saying that if the Eset binaries were compiled to use ASLR, it would do nothing to fix your stability problems
• Dlls have to be loaded by a process. It is the process that uses ASLR or not. You should really read up on Technet a bit to fully understand where this technology is. Yes, the AV kernel libraries may have potential vulnerabilities in them, but they need a VECTOR to execute. Since the Eset kernel isn't leaving ports sitting open, the vector for compromise of your AV software is through other software like your browser and it's plugins. Malicious programs will attempt to exploit those processes and if they can get admin rights, they will directly modify the registry and attempt to kill services to deactivate the AV software (or drop in a rootkit and hide from it). You're AV software isn't surfing the web so it isn't going to be exposed to that kind of malicious content, and ASLR won't do anything because nothing is modifying the AV kernel's stack.
• It is common knowledge at this point that the vast bulk of exploits are targeting 3rd party user apps. Windows is much better about patching critical services these days and malware writers have adjusted to target what is left and exposed. Just look at the Secunia CVE statistics if you don't believe me.
• DEP has an exclusion list sitting right in the GUI menu where you can whitelist processes if they break under OptOut mode (that's the opting out, part). Safari itself works with DEP. Odds are some other library or plugin does not and was causing it to crash for you.