Security, Hypocrisy and the Kernel Patching Spat

Security, Hypocrisy and the Kernel Patching Spat
( Page 1 of 2 )

Opinion: McAfee and Symantec aren't trying to save you from kernel patch protection; they're trying to save their own business models.Its not easy being Microsoft. Not that you should feel sorry for the company, at least not usually. But it is often put in impossible positions, as McAfee and Symantec are doing now.

The two companies are arguing, mostly in European papers in order to influence antitrust policy in the European Union, that security design decisions in Windows Vista are unfair to them and actually weaken system security. Their arguments are, for the most part, transparently false and self-serving.

There are two main issues being bandied about, kernel patching and the Windows Security Center.

Resource Library:

Ill focus on kernel patching here and on the Security Center in another column, although the big issues are largely the same: Microsoft has made design changes in Windows Vista that make the system more secure, but that limit the technical options for third-party products. Those third parties are unhappy.

Click here to read Microsofts Ben Fathis response to questions about these issues.

When I say "Windows Vista" I should be more specific: Kernel patch protection is implemented only in the 64-bit version of Windows Vista, just as it has been in the 64-bit versions of Windows XP and Windows Server 2003.

"Kernel patching" refers to the hooking, at run-time, of operating system calls. A good explanation of this process may be found in the descriptions of its most infamous use: the Sony DRM rootkit affair of about one year ago. As described by Mark Russinovich, now a Microsoft employee, the Sony rootkit used kernel patching to do its dirty work:

A common way to intercept kernel-mode application APIs is to patch the kernels system service table, a technique that I pioneered with Bryce for Windows back in 1996 when we wrote the first version of Regmon. Every kernel service thats exported for use by Windows applications has a pointer in a table thats indexed with the internal service number Windows assigns to the API. If a driver replaces an entry in the table with a pointer to its own function then the kernel invokes the driver function any time an application executes the API and the driver can control the behavior of the API.

Old-time DOS programmers like me are reminded of TSR-hooking in order to implement popup programs and similar facilities.

Sonys example demonstrates what is obvious, that kernel patching can be used for nefarious purposes, and especially for rootkits. This is why Microsoft decided, in the 64-bit versions of Windows, to put checks in the operating system to disallow patching of the system service table. Why not the 32-bit versions as well? Basically out of consideration for vendors like McAfee that had come to rely on it for their own purposes.

Next page: McAfee and Symantecs claims.

>>> More Network Security & Hardware Articles          >>> More By Larry Seltzer