https://www.av-test.org/en/news/news-single-view/check-2015-self-protection-of-antivirus-software/
Hopefully we will soon see some improvements here…
There’s room for improvements
https://www.av-test.org/uploads/tx_news/0915_dep_aslr_consumer_balken_en_01.png
Hi.
Today I have stumbled upon this article:
[url=http://fossbytes.com/which-antivirus-software-protect-themselves-from-hacking-attacks/]
http://fossbytes.com/which-antivirus-software-protect-themselves-from-hacking-attacks/[/url]
It’s stated that using ASLR and DEP (features of anti buffer overflows and privileged memory corruption)
increase antiviruses’ capability to protect the end user.
COMODO does not appear to be on that list.
So…
- does COMODO makes use of ASLR and DEP?
- are these two features really necessary for an AntiVirus software? Will they increase its protection by a significant factor?
Thank you.
comodo was tested and here is the original report https://www.av-test.org/en/news/news-single-view/check-2015-self-protection-of-antivirus-software/ and according to av-test results, comodo averages a 53% across 32bit an 64bit PE files(.dll, .exe,etc) for DEP and ASLR. However when I checked for myself, I had higher percentage for DEP and ASLR compatibility. For example the results for 64-bit DEP coverage is 61.9% and 52.2% for 64-bit ASLR coverage, but my results were 97.77% for 64-bit PE files that have DEP enabled and 84.44% for 64-bit PE files that have ASLR enabled.
To answer your question’s yes comodo does make use of ASLR and DEP and it is only necessary for a security suite to have ASLR and DEP for dll and exe files that get loaded or injected in other processes, in comodos case that would be guard32.dll that gets injected into every 32-bit process, and guard64.dll for 64-bit process, both of which are DEP and ASLR aware.
How did you check DEP and ASLR compatibility? What do you mean with compatibility?
I split from CIS Certifications, Test Results & Reviews topic and merged another topic about the same subject with the new topic.
Using a PowerShell script that is available on github here: GitHub - NetSPI/PESecurity: PowerShell module to check if a Windows binary (EXE/DLL) has been compiled with ASLR, DEP, SafeSEH, StrongNaming, and Authenticode. accompany blog post:Verifying ASLR, DEP, and SafeSEH with PowerShell. By compatibility I am referring to the /NXCOMPAT linker option that should be set so that an executable will be compatible when DEP is applied to the executable during runtime. Same for ASLR, the /DYNAMICBASE linker option makes the executable use the ASLR feature that is available on Vista and newer.
Thank you. 
https://www.av-test.org/en/news/news-single-view/check-2015-self-protection-of-antivirus-software/
Self-protection tested.
53% for Comodo.
this is not self protection per se, its just compiler settings. Not sure if this test actually tests the software against vulnerabilities, i think it only checks if its enabled or not… Also DEP etc is not the only way to protect, there are other techniques that the software could be using which this test is not testing. Matousec on the other hand do test the software against vulnerabilities rather than check if the setting is there or not. I do like AV-Test guys, but this test does need some more meat behind it. I have full confidence in the AV-Test guys to take this test to next level and turn it into a real meaty and valuable test.
here is an excerpt from this site:
“If a programmer uses DEP and ASLR technologies as a supporting measure, this reduces the risk that a possible vulnerability may actually become exploitable. If an application does not employ DEP and ASLR, this does not necessarily mean that it is unsafe. If the programming is 100% error-free, the level of security cannot be increased either. Thus DEP and ASLR are an additional precaution that a programmer or manufacturer should not do without. Implementation is so easy: it involves existing functions in the compiler that simply need to be activated. The technology has no negative impact on the code size or program run time.”
Would there be any downsides for Comodo to enable DEP and ASLR? I mean, if it’s as simple as flipping a switch (Which I don’t know if it is) and if it doesn’t cause any issues, then why not just use it for the potential of gain? I’d assume Comodo doesn’t use it for a reason though?
If it’s there for free why not use it across all executables that make up the suite? It will help against exploits. Classical HIPS like Matousec tests do not protect against exploits.
I don’t know if it enabling has implications for how security software is written. If that’s the case then wouldn’t it make sense to rewrite the code to enable DEP and ASLR in all executables of the suite?
even before DEP we were protecting our users against buffer overflow etc…
worry not…you got the protection…unless you can or any testing organisation can show how they can penetrate CIS because it doesn’t have DEP enabled. DEP is not the only way…the testing organisation is not testing if protection is there or not, they are just checking if DEP is there or not. So if you have other protection instead of DEP they won’t know…Also DEP in the past had compatibility problems with some software…thats why we had to use different methods…
I’m not sure how AV-test came to these results as I have a much higher percentage for PE files that have DEP and ASLR enabled, in my previous reply I only checked PE files that were 64-bit and now I just did a check against a CIS x86 install which only contains 32-bit PE files and the results were very much the same: 85.10% ASLR and 97.87% for DEP. They way I checked was that I put every exe and dll file from the CIS insallation directory and the dll files that are placed in the system32 directory and put them all in one folder. Then using this powershell script GitHub - NetSPI/PESecurity: PowerShell module to check if a Windows binary (EXE/DLL) has been compiled with ASLR, DEP, SafeSEH, StrongNaming, and Authenticode. I ran it against the folder that contained all of CIS dll and exe files. I have attached my results.
Yes, CIS did have buffer overflow protection in previous versions of CIS but as of late that is no longer true as it seems the code behind detecting the buffer overflow attack/shellcode injection has been removed but the HIPS setting to enable to detect such attacks is still available. I can penetrate CIS by exploiting a buffer overflow vulnerability in a trusted application that suffers from such security flaw, I have made a bug report about this issue and was told by a comodo staff member that they would look into it and provide an update about the fix date, this staff response was back in June, care to have a look into it now?
https://forums.comodo.com/format-verified-issue-reports-cis/cis-doesnt-prevent-buffer-overflow-attacksdetect-shellcode-injections-m1489-t111010.0.html
[attachment deleted by admin]
Confirmed (at least according to Joxean Koret, the author). At least a few years old:
Link removed.
Linking this here will likely resurrect an old controversy.
Any how, just something to consider…
Mod Edit: Link to the PDF download removed due to obscene language and images within the document, Captainsticks.
Very interesting read! Thanks for sharing.
Mod Edit: Link to the PDF download removed due to obscene language and images within the document, Captainsticks.
So, what can we learn from this paper?
- No security product is perfect
- There are always improvements to be made
- Don’t ignore these warnings and regularly have your product audited.
if this pdf is real (if its from real works and tests) then I guess comodo should pronounce about these faults pointed of that pdf. maybe… i guess…
PDF and research results in it are real.
Every software can be bypassed, the point is not “if”, but “how long” it takes.
If you can do it in just 1h and (for example) hijack a well-known website, that can make sense. If you need to work one month to bypass a software and all you can get is to annoy few users, it’s not worth.
This guy focused only on one AV at each time, he understood how it works and made a code with the only purpose of bypassing it.
What makes me thinking is that he said he took only 1h to do so with Comodo…
I said “thinking” and not “worry” because I don’t think this guy would purposely attack me or any normal user, but for sure a virus based on his code could bypass Comodo.
I agree with him about advertising, but that’s normal and it’s not only Comodo’s shame