Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
NOTE: I know this is a long post. If you don’t want to read all the details I discuss here, I still encourage you to go read What Were They Thinking? Anti-Virus Software Gone Wrong, by Skywing, to give you a perspective on “known good” extensions to kernels. Also, as always, this blog post represents my own personal analysis and opinion (based upon my own experience) and not that of Microsoft – and represents my best efforts to figure out what’s really happening.
Last week, I posted Windows Vista x64 Security - Pt 1, that started an overview of some of the additional security features in x64 above and beyond x86 Vista. I’ve been chugging along, researching it and weighing the value and BOOM, a couple of days ago, Symantec releases paper number 3, converging my previous topics, Symantec Stirs the Pot and Further Perspectives on Symantec Vista "Research" with this topic. Go figure. So, first I’m going to discuss Patchguard, and then I’ll have a follow up post with some of my thoughts and opinions on the latest from the Symantec Office of Hyperbole and Exaggeration.
UPDATE: The Windows Vista Security Team Blog has a post on Patchguard too.
Well, first, it turns out it isn’t being introduced in Windows Vista. Patchguard was introduced in Windows Server 2003 SP1 x64 and Windows XP x64 about 18 months ago in early 2005. This raises a side question for me – why are certain parties acting like Microsoft sprung Patchguard on them as a surprise in Vista? To my reading, even the “Bypassing Patchguard” article (see below) was based upon analysis of one of those earlier x64 versions of Windows and not Vista.
In theory, if some antivirus companies worked on adjusting their products to Windows XP x64 and the defined interfaces, they’d have had a lot of leisure and been very well positioned when the Beta versions of Windows Vista were made available to developers about a year ago. I simply can’t imagine anyone assuming that Microsoft would take a step backward and remove a new security protection from Windows XP x64 when moving forward to Windows Vista x64. It is puzzling to me… anyway, moving on.
In Patching Policy for x64-Based Systems, Microsoft provides some explanation of motivation and why x64 provides an opportunity to introduce the new technology. I’ll summarize - extending or replacing kernel services via undocumented means decreases stability, which is a bad thing, and the Patchguard technology monitors and prevents it. Patchguard would break too many existing 32-bit applications, so it was introduced to the relatively new 64-bit versions of Windows because it is possible to do so with much lower levels of impact to existing user software. (Breaking lots of user apps being another bad thing.)
Kernel Patch Protection: Frequently Asked Questions provides further detail by outlining the problems that Patchguard helps to address: reliability, performance and security. Here’s what it says about reliability, for example:
Reliability. The Windows kernel is tested extensively before any release of the operating system to ensure a high level of quality. Because patching replaces kernel code with unknown, untested code, there is no way to assess the quality or impact of the third-party code. Furthermore, kernel code is by its nature complex and critical to system stability, so bugs in unknown code can have a significant negative impact on system stability. An examination of Online Crash Analysis (OCA) data at Microsoft shows that system crashes commonly result from both malicious and non-malicious software that patches the kernel.
I’m not sure I know what “known good” kernel add on looks like. Do good intentions count or is that not enough? – because I might be able to list applications with good intentions. From a security & reliability perspective, I can only ask a few questions:
· Was this kernel add-on part of the overall design? It can be, and if so, there should be predictable, well-defined interfaces that help it fit into the designed architecture. Otherwise (ie using non-documented methods), behavior is unpredictable at best.
· Was this kernel add-on tested to the same level as the rest of the code? Did it meet all of the Security Development Lifecycle requirements? Was the code loaded and test with the 1000s of most common applications for compatibility? In all languages? Usually, I think the answer is going to be “no”. If so, then the best way to design in predictability and stability is to have clearly defined interactions/interfaces.
Of course, there is a difference between a driver developed by, say Hewlett-Packard, and some unknown code posted for shareware download. The former should be allowed to extend the kernel in defined/designed ways (ie. so your printer works) that the latter perhaps should not. The method for that on x64 is Kernel Mode Code Signing.
Of course, this is just my thoughts on “known good” applications, but I found my opinion reinforced pretty strongly when I recently read What Were They Thinking? Anti-Virus Software Gone Wrong in the current volume of Uninformed. Note that Skywing is one of the co-authors that reverse engineered Patchguard last year and wrote Bypassing PatchGuard on Windows x64, also published in Uninformed and referenced heavily in recent papers concerning Windows Vista security. Here is a brief excerpt from the article, to tease you into reading it:
…, there has been a shift towards including personal security software on most new computers sold today, such as firewall software and anti-virus software. Many new computers are operated and administered by individuals who are not experienced with the administration of a secure system. As such, they rely solely on the protection provided by a firewall or anti-virus security suite.
Given this, one would expect that firewall, anti-virus, and other personal security software would be high quality - after all, for many individuals, firewall and anti-virus software are the first (and all-too-often only) line of defense.
Unfortunately, though, most common anti-virus and personal firewall software products are full of defects that can at best make it very difficult to interoperate with (which turns out to be a serious problem for most software vendors, given how common anti-virus and firewall software is) and, at worst, compromise the very system security they advertise to protect.
Okay, to help get a better understanding of the value of Patchguard, let’s look at a common scenario and how it plays out on different machines. Imagine a user has just gotten some new software to install. Perhaps a friend gave them a useful utility. Perhaps it is a great new screensaver, a game or some other free download from the Internet. Maybe it is even a security program to protect against viruses.
Being a conscientious security person, the user logs in to his user-mode account and tries to install the software, and it promptly fails, notifying her that she needs to perform the install as an administrator. After a brief hesitation, she logs out and logs back in as administrator and re-starts the installation. The program installs successfully and one of the things it does is to modify the system services table to redirect certain system calls to itself before returning control to the normal kernel code.
What can the new program do? Pretty much anything it wants. It will definitely affect performance. It may have introduced unpredictable instabilities into the core code paths of the kernel. And lastly, if the code is malicious, then the box is compromised in a way that may not even be easily detectable.
If the program was XYZ Antivirus, we might think this is probably okay. If the program was a game, one might wonder why it needed to put a hook into the kernel. Worse, we don’t even know if a hook was placed in the kernel or not.
How does the scenario work on 32-bit Windows Vista? It is pretty similar.
This time, our good security user starts an install as a standard user, and gets a User Account Control (UAC) prompt, indicating that it needs administrator credentials for it to proceed. After a brief hesitation, the user provides the credentials if she has them and proceeds with the installation, ending up with a hooked kernel.
The scenario plays out a bit differently on 64-bit versions of Windows.
This time, when the installation starts in administrator mode (either via login or UAC prompt, on Vista) and proceeds, Patchguard will stop the attempt to hook into the kernel. Further, on Windows Vista, if a driver is installed, but is not signed by an authorized Certificate (such as one Symantec would have), the driver would not load.
This is a big win for reliability, performance and security, in that it limits the possibilities for unknown, untested and possibly malicious software to insert itself into core code paths in the kernel.
As mentioned before, Skape and Skywing wrote Bypassing PatchGuard on Windows x64, and published it on Uninformed. I enjoyed reading the paper and can tell you I was incredibly impressed with the evidence of reverse engineering implicit in the work. Let me give you a brief quote from it:
The real purpose of this document, though, is to illustrate that it is impossible to securely protect regions of code and data through the use of a system that involves monitoring said regions at a privilege level that is equal to the level at which third-party code is capable of running.
The key thing to extract from this is an assumption in the whole paper – if you can load kernel mode code, then you can find ways to bypass Patchguard. That is a very important if! This still leaves a lot of positive protection by Patchguard for protecting from non-kernel code – the scenario we looked at above for example. What would really strengthen it though is if you had a way to disallow any kernel mode code that wasn’t developed by a Trusted partner … wait a minute! That’s what Kernel Mode Code Signing does!
Microsoft – You are a 3rd-Party Too !
Now, if I am a core kernel architect (which I am NOT), then I don’t want other folks messing with my kernel for all the reasons discussed. And frankly, that applies to those teams in other part of Microsoft as much as it does to third parties. (I’m a developer at heart – I just know they don’t love my code as much as I do and won’t respect the beauty of my design trade offs.) That’s why, once I had defined interfaces, I’d be demanding everybody use them. That’s also why my boss would be backing me up on that (if I was a core architect, which I am NOT). So, I decided to check.
I went to the Host Security product team and asked them if they got to hook the kernel – they did not. They said that the x64 version of their product for Windows Vista would use the defined interfaces, just like any 3rd-party security product. They said they’d have to re-implement certain aspects from the way things were previously done. [UPDATE: Some folks have taken this last statement to imply that the Microsoft product was previously hooking the kernel. This is not the case, as I've went back and re-confirmed. To deliver an x64 product, the team has made changes in terms of recompiling and utilizing a x64 based detection engine, but no changes were necessary with respect hooking the kernel. ~Jeff]
Next, I went to the Windows Firewall product team and asked them if they got to hook the kernel. The said no. A new Windows Filtering Platform (aka defined interfaces) had been introduced for Vista, which they would be using just like everyone else.
After digging into Patchguard, I’ve found it to be like many other security capabilities, such as ASLR, in certain ways. It is not perfect, but it raises the bar for security, eliminating certain scenarios and making other scenarios more challenging. Combined with other security enhancements, I feel pretty good about x64, and definitely think the x64 enhancements give me some higher assurance than the 32-bit counterparts – and that it is another important step forward in improving security over the long run.
Regards ~ Jeff