Kernel Patch Protection – Looking forward to actual Kernel Security!
As a part of the Trusted Computing Base (TCB), comprising of hardware, software and firmware, one of the very important criteria of rating the security level of a system is the protection that it provides to the kernel of its operating system.
Operating system kernel is supposed to be the most trusted piece of software that is loaded first when the system starts. According to the Basic Security Theorem –"If a system initializes in a secure state and every consequent transition happens securely, then every subsequent state of the system will be a secure state". But the same theorem also suggests that to maintain the secure state of the system, every transaction must be a secure transaction i.e. no transaction on the system must be executed that tries to bring any kind of instability or insecurity in the system.
While an application that tries to "patch" or "hook" itself to the kernel, not only compromises the integrity of the Operating System kernel, it also brings about insecurity and instability into the system. This happens because it lowers the security and reliability of the kernel by replacing the kernel code by a different code that has not been documented or tested by the vendor.
Protection Rings –
With reference to the 4 Protection rings, the OS Kernel resides in the innermost ring (ring 0) and hence has the highest privilege to system resources. This is because amongst, all the software, the kernel is assumed to be the most trusted piece of code that works closely with the hardware to provide a protected access to the system resources to all the applications.
On the other hand, if an application like a rootkit patches the kernel with some new code, which may be malicious, it holds the capacity to bring about a much serious damage to not only the system software but even the hardware and firmware, as it has complete control of all the resources.
While Microsoft has always discouraged the installation of such applications that patch the kernel, however the enforcement of this rule was only brought about in Windows Server 2003 (x64 bit), and Windows XP (x64 bit), and Windows Vista (x64 bit) editions. This was so because there are simply too many applications in the current x86 Windows environment that will need to be rebuilt to work under those restrictions. While recoding the applications for 64-bit platforms is already underway by most of the security vendors, they can easily bring about these changes much ahead of time, till the transition from 32-bit to 64-bit platform happens slowly.