Security → Popular security suites open to attack

»www.av-test.org/en/news/ ··· oftware/ from »www.zdnet.com/popular-se ··· 0036149/ from »www.hardocp.com/news/201 ··· _attack/ ...

"An Internet security suite provides full system protection, employing all available protection technologies. But what about the self-protection of the system protectors? Do they use protection technologies such as DEP and ASLR for their own use? AV-TEST examined 32 applications to find out..." --AV Test

"Summary: Your anti-malware system does you no good if it's successfully compromised. Few security suites use ASLR and DEP in all their executables..." --ZDNet

Interesting results.

Hmm, I didn't see any mention of Windows Defender/Microsoft Security Essentials (MSE). I would hope they use DEP/ASLR.

According to Process Explorer, MSE on W7-64 uses ASLR, with DEP marked as "n/a."

That is 'n/a" as in "not available" as in "you ain't touching this process".

Run procexp as administrator.

Thanks. When run as Admin PE 16.04 reports

"DEP (Permanent)"
"ASLR"

Still not sure why Windows Defender/MSE was totally ignored by the article.

At least on my machine Kaspersky Internet Security 2014 is running both DEP and ASLR.

Too bad the chart is too dark for me to read on the av-test site. So, any information is useless to me.

I'm a little unclear just what an application has to do to "support DEP". Part of this has to do with Microsoft's marketing-speak use of "DEP" to cover several different things.

The most important DEP feature is support for no-execute pages, aka NX.

NX: pages allocated for stack/data space do not permit execute access. The hardware traps attempts to fetch instructions from such pages. No application support needed.

It's true that if your crufty old 32-bit code expects to allocate data pages and put instructions in those pages (rather than asking for executable pages) then NX will cause it to fail. In that case, you have to take action when building the code to say "not NX compatible". But this seems to me like a rare case (building code on-the-fly is unusual).

You can say "the program code don't like NX" by building /NXCOMPAT:NO or by executing SetProcessDEPPolicy at runtime. Note that looking at the .exe flags won't tell you about the second method.

The setting of /NXCOMPAT is irrelevant in DLL files. NX use is on or off at the process level, not the module level.

I believe 64-bit code can't disable NX, but I could be wrong there.

"Software DEP" is related to structured exception handling (SEH), and stops attacks due to overwriting the exception chain. This depends on a table of safe exception handlers being present in the image file, i.e. code needs recompiling to support it.

But modern versions of the OS use a prevention mechanism 'SEHOP' that does not require that table; so I suppose that /SAFESEH is no longer important.

Summary: that article looks a little under-researched, or possibly just under-reported, to me. In particular, their reporting on 64-bit files makes me wonder.

P.S. This diagram seems about right to me, though dated.

P.P.S. Corrections welcomed, it's been a while since I've done any serious Windows programming.

My understanding of DEP is the same as yours FWIW.Interestingly EMET can override the compile-time NX-bit (DEP) setting. Not sure why one would want to do that but I assume there are situations where it is useful.I think that's what PE reports as "DEP (Permanent)" for 64-bit processes.

Windows Defender isn't shown in PE even when running a scan. Windows Defender Status Manager is shown (with both DEP and ASLR as permanent). It's a program that gives Windows 8 users a systray icon for WD.

MSE and Windows Defender are used in AV Test and AV Comparatives by agreement with Microsoft as baseline so they don't show up usually in test results.

Bah to Avast and Kaspersky on 64bit machines.

After reading the article, I was a little curious too.
I'm sure Kaspersky has it's own protection process for itself.
I know in the beta testing days of the first trial of self-protection, the programmers/developers wanted everyone to report any tool that broke the protect chain.
Sure it could use a Microsoft protection process, but then your allowing Windows to protect your product, when your actually protecting Windows.

Is the test saying it didn't use DEP, or they could bypass the protection?

I'm still a little confused by the results.

The report says Kaspersky 2015 uses DEP 87% of the time on 64 bit Windows PE files. The weird thing is that Kaspersky uses DEP 98.5% of the time on 32 bit Windows. That's nutty. Those percentages should be reversed to make sense.

ALL my programs use DEP (most marked as "permanent" DEP) according to Process Explorer. I'm wondering how Kaspersky would show there since it uses DEP but not 100%.

Just ran a quick MSE scan (Win7 x64) and MsMpEng.exe is the process that was using CPU time. Maybe it started a thread to do the scanning (didn't check).

FYI MsMpEng = Microsoft Malware Protection Engine

msseces.exe is the MSE user interface/tray icon process.

Both are using DEP/ASLR.

But NX isn't "allowing Windows to protect your product", it's allowing the hardware to protect your product. Windows's involvement is to set page table entries accordingly.

(If any program was dicking around with PTEs directly, that would be a good reason to never use any program written by those people)

I'm inclined to the simpler explanation that the article is a confused mess.

Edit: note that the best way to protect your product is to not write bugs into it. A "buffer overflow vulnerability" doesn't just show up like some sort of plague, it results from inadequate attention to programming.

Yup its a service and hence runs all the time and whether you're logged in or not.

I guess I was a little too general in my reply..

I was referring to the software DEP, not the NX bit.
»support.microsoft.com/kb ··· 875352#3

quote:

---

Software-enforced DEP
An additional set of Data Execution Prevention security checks have been added to Windows XP SP2. These checks, known as software-enforced DEP, are designed to block malicious code that takes advantage of exception-handling mechanisms in Windows. Software-enforced DEP runs on any processor that can run Windows XP SP2. By default, software-enforced DEP helps protect only limited system binaries, regardless of the hardware-enforced DEP capabilities of the processor.

---

But then I might be remembering the XP days, I've not followed up enough in Win 7 or 8.

Well as dave says the NX bit is a feature built into newer processors (not just Intel ones). It's a hardware feature that has little to do with Windows or any other OS except in a very limited way (i.e. changing it when starting a process).

XP came out in 2001 or so and it's probable (I don't recall) that not all CPU's of that era had the feature so Microsoft invented a software equivalent.

Even as late as 2006, when I bought another XP Pro computer, most Intel CPU's did not have hardware DEP and software DEP back then didn't work on a lot of software including Microsoft Word. My CPU, which was the last gaming Intel Pentium 4 hyper threading CPU, had hardware DEP. Software DEP was not very useful unless all software complied and that was no way the case. When you had to exempt a lot of software....well...