Agnitum panicked because of Microsoft’s security measures

In the Sunbelt Blog I read today, that Agnitum, vendor known for its firewall mainly, is panicked because of Microsofts Kernel Patch Protection. Sorry, but that caused me to laugh. No idea how new the news are, but to those following the driver developer mailing lists and fora it is certainly no news. Let’s look at some of the claims of Agnitum:

To provide proactive protection, security software solutions need to get control over low-level system activities like file and registry operations.

Good idea. But what’s the point, how about using the CM callbacks and a file system filter driver (FSFD)?

To achieve this level of control, one approach uses a documented API provided by Microsoft. However, this API does not allow ISVs (independent software vendors) to control system activity pre-emptively and on the fly.

Oh, it does not? That is strange. What do you guys mean by “pre-emptively and on the fly”? Is that possibly your problem? You can very well prevent loads of registry changes by using CM callbacks. You can do whatever you want (literally) using an FSFD.

It limits the number of file and registry operations that can be controlled.

Seriously, which are not included that you have to include urgently, guys? I mean we are talking about post-W2K3. The API is quite complete actually.

It does not allow control of process memory modification and imposes a number of other restrictions. This does not help independent software vendors to provide system protection using native interfaces.

True, memory modification is one of the things that cannot be controlled. I’d be curious though, what the “other restrictions” are.

Unlike other techniques suggested by Microsoft, this approach enables third-party software to protect the OS by gaining full control over file and registry operations.

Doh, exactly those two things again that are well covered by a well-written FSFD and the CM callbacks. Okay, I agree, it could be more convenient and backwards compatibility with Windows 2000 or even earlier requires some compromises. Even XP is not without problems, because the callback interface has changed with the release of Windows 2003 Server and some CM callbacks on XP were reported broken. So for registry access I’d even agree that a better solution could be offered. However, unlike with process/thread creation notifications, you have an unlimited number of callbacks that can be registered using CmRegisterCallback().

Microsoft believes kernel patch protection defends code and critical structures in the Windows kernel against modification by unknown code or data.

Yap, that’s the problem, there it goes our beloved trusted computing base (TCB). It’s not trusted any longer. But seriously guys, the structures such as the SSDT are undocumented by Microsoft. Using this approach right now is not the right way to go either. It is hackery, no ifs and buts! Okay, I guess all of us have done it every now and then – I for one admit to it – but that does not mean it was “politically correct”. Some have done it because their employers did not have the resources to develop an FSFD, others have done it because on Windows 2000 and NT4 there was no CM callback. Anyways, these operating system versions can now be considered stable and the methods (such as SSDT hooking) can be considered proven, but this does not hold for future versions of Windows …

Kernel patch protection stores and periodically verifies checksums of specific kernel memory areas (network components); if a checksum mismatch is found, the result is the dreaded Blue Screen of Death (BSOD). According to Microsoft, this technique should prevent SDT modification and thwart the intentions of a number of rootkits.

Which it surely does to a certain extent …

Research by Agnitum security experts has determined that, in practice, kernel patch protection does not prevent hackers from reverse engineering specific OS code areas to re-acquire the desired capabilities. While it does disable compatibility with future kernel versions, quality-assurance is not a big concern for most malware writers.

Now one that must have been written by some PR guy . Of course it does not prevent reverse engineering, neither dynamic (using a debugger) nor static (using a disassembler such as IDA). So it disables compatibility with a vastly undocumented monolithic piece of code? Interesting? Could that be because you guys are using the hacker approach already? Undocumented methods to hook into the SSDT and elsewhere? That is like illegally watching pay-TV and complaining about the TV stations changing keys …

Microsoft seems to be saying that it is enough to use just standard built-in protection tools.

Rather built-in APIs, yes. If you don’t like the APIs you are free to suggest new ones. Especially the development since Windows 2000 has shown that Microsoft is open towards suggestions.

Agnitum and other third-party security developers would strongly disagree with that position. Third-party security solutions create a much-needed additional level of protection, and having a variety of these tools available empowers the user while handicapping the hacker. Simply put, it is much harder for malware writers to adapt malicious code for different protection mechanisms from multiple vendors than it is to attack a single-vendor solution that purports to be a universal fix.

Are you saying I should install half a dozen of anti-[whatever] software solutions to slow my PC down? How about education of PC users? That is something mostly neglected by anti-[whatever] vendors, just because educated users making educated decisions could possibly harm their business.

Besides, does it make sense to consider triggering a Blue Screen of Death as a way to defend against rootkits?

Guess what? The answer is yes, because the blue screen is the system’s way to tell the user that it cannot trust itself anymore because someone played with it or that some other exceptional condition occured which made the system (or rather the programmers of the system) “believe” it might be safer to bring down the system in a controlled manner instead of letting the user continue work and lose hours of work! By the way, this is well-known to driver developers, isn’t it?

Under Microsoft’s proposed solution, a rootkit that could previously be detected by and remedied with anti-virus software will now cause the BSOD. The same result will occur after installation of security software that is not compatible with kernel patch protection technology.

Are you saying that your software does not check for that situation? Well, that is definitely your and only your problem. It is well-known that anyone employing the hacker methods should ensure to employ them only on systems where they have been heavily tested.
Nevertheless sometimes defective code slips through. I once reported a bug to Kaspersky, because they did not check for invalid parameters, causing a BSOD if a user-mode application called the hooked APIs with invalid parameters. This had only been revealed because some greenhorn would tell me that he could bring down his system by passing invalid parameters. I checked the same test-case with Windows NT 3.51 through Windows 2003 SP1 and the error did not occur. So I checked the system and found one of the Kaspersky AV drivers being the culprit. That might be another reason for MS to stop kernel patching: it harms their reputation if third-party drivers are badly written. Not in all cases one can find the culprit that easy.

The security experts at Agnitum believe this move by Microsoft is designed to force users to rely on Microsoft and only Microsoft for Windows security, removing the option to use third-party security solutions that, if past experience is anything to go by, are likely to be more robust and provide better protection than Microsoft offerings.

To that one I agree to a certain extent. Does it justify “shady” methods though? Aren’t you actually admitting that your product uses these shady methods instead of the ones it should use?

Well, what can I say. Some of the claims are laughable since the problem is known for a while and it can be addressed in different ways. Using documented interfaces such as the IFS kit and the CM callbacks is one way, and according to Microsoft it’s the way to go …

// Oliver