A note on the Windows XP x64 kernel protection patch KB914784

[Paul Adams]

There have been some people complaining that Microsoft broke some applications (typically Tiny Personal Firewall, Daemon Tools and Alcohol) with this kernel update on x64 versions of Windows, but the fact of the matter is that the application developers have not followed the guidelines for writing kernel mode code, and now it has come back to bite them:

If your driver must perform a task that you think cannot be accomplished without patching the kernel, contact Microsoft Product Support Services or your Microsoft representative to help determine if a documented alternative exists. If no documented alternative exists for the functionality you want to implement, then the functionality will not be supported on any Windows operating system that includes patch protection support."

Patching the kernel is basically what rootkits do - modifying the system so that certain information is hidden from sight: registry values, files on disk, running processes.

Because the code and data is hidden from even the OS itself, anti-virus programs can find themselves unable to detect it, also the kernel is compromised in terms of stability - the developers are writing code that may only be 'compatible' with specific versions of the kernel and make assumptions about how the (undocumented) internal functions work.

Modifying the kernel can have an impact of performance as the code in here is called millions of times per minute and is optimised for speed - if 3rd parties are inserting their additional code then it could be introducing a delay with unrelated kernel activities with which they are not concerned.

There is also no guarantee that the kernel patch could not be used for malicious purposes even if that was not the original intent - Sony's DRM code is a prime example of this kind of short-sightedness.


For those considering leaving the kernel protection patch off their x64 versions of Windows, consider what this means for future kernel updates from Microsoft - you have effectively left yourself with a kernel that cannot be updated, and anything that has a dependency on future versions of the kernel will not work/install.

OS service packs include all public hotfixes since release, so Windows x64 SP2 and onwards could not be installed either as it will include this kernel patch protection enhancement.


In the same way that users should follow best practice (keep OS & apps patched, use most recent drivers, do not use admin account for day-to-day use, have AV installed, etc.), developers also need to follow the recommended guidelines (not using undocumented methods to make their program work, not assuming the user has admin rights, etc.).

This will have greater significance in the future when Windows versions may be natively 64-bit only, and of course Vista x64 already has this level of kernel protection in place so if developers want to look to the future then they should be working within the realms of supportability, stability and compatibility.


I have had to debug memory dumps from crashes where the kernel has been hooked and it becomes impossible as the (Microsoft) source code can be traced up to a point, but then the code jumps off to a random memory location and starts running 3rd party code which we have no idea about.

Buffer overruns, null pointers, deadlocks and so on in the in the 3rd party code would appear (incorrectly) to be within the Microsoft kernel component so lead to false troubleshooting.


References:
KB article 914784
Security Advisory on KB 914784
64-bit Kernel Patch Protection FAQ
Patching Policy For x64-Based Systems

[aidanjt]

Great advice Paul as usual

3d party developers have little or no excuse to inject sloppy code into the NT kernel anymore. Lets hope they come around and start developing programs to work properly in userspace. Windows is a true multiuser operating system and it's about time developers respected that.