Holy anti-feature, batman

I had the opportunity to attend at talk by Mark Russinovich, of Sysinternals fame, during last week’s Trustworthy Computing Conference.  The topic of the talk was about security boundaries in Windows, and more specifically, what is not a security boundary.  The talk was very interesting, and I don’t want to reveal too much here, but there was one part of it that stuck with me and has been bothering me for a little while now.  One of the technologies he addressed was Patchguard, or Kernel Patch Protection, which was introduced in 64-bit Vista and Server 2008.  Patchguard is intended to keep programs from patching, hooking, or otherwise tampering with the internals of the NT kernel.  It does this by periodically taking a checksum of some important structures in the kernel (SSDT, interrupt table, HAL tables, etc) and comparing the current value with the previous one.  Any discrepancy here will indicate that the kernel has been subverted.  If it notices any changes to these structures, it throws an exception which throws a blue screen error.  Sounds good, right?  Sounds like a great new security feature, no more rootkits!  Well, not really.  The truth is, KPP really does nothing to stop malicious code, and in fact, is pretty useless in doing so.  Mark revealed in his talk, that that was never the intention of KPP, but rather, it was conceived as a way to force legitimate developers to stop using these techniques in their own programs.  See, most anti-virus and security products will use some level of system hooking in order to get a good view of activity.  In fact, one of Mark’s very own tools, RegMon, hook’s the SSDT to watch registry activity.  He even wrote a publication about the technique!  The problem with kernel hooking is that it is entirely unsupported and significantly reduces stability.

So here’s what I don’t understand.  Microsoft has recognized that system hooking leads to instability.  They’ve decided that programmers aren’t good enough to extend a kernel function safely without throwing a blue screen exception, so now they’re not going to allow us to hook certain system structures (pfft, allow is a funny thought).  But, instead of actually fixing the gaping holes in their system, they’re going to simply watch for system hooking, and then guarantee that the system will crash, by causing the crash.  Oh yeh, and they are going to blame it on the developer.  It’s like a car company deciding that talking on your cell phone while driving is dangerous, so they’re going to create a system that detects if you’re on the phone and then drives the car off the road for you.  That will show you! 

I just don’t understand this anti-feature.  There are plenty of legitimate reasons for hook these system functions, and it can be done safely.  I know it can because Mark has done it, and I’ve done it.  If you don’t want developers to subvert the kernel, then provide a complete API that we can use to extend and monitor the system, and fix the problems with your system that allows someone to take write-protected virtual memory, map it to physical memory, strip all the restrictions off of it, and send it back patched.  Don’t just come behind perfectly valid code, throw an exception and blame it on us. 

Vista’s Despised UAC Nails Rootkits

PC World – Business Center: Vista’s Despised UAC Nails Rootkits, Tests Find

PCWorld has a story about test conducted AV-Test.org that was supposed to rate the most popular anti-virus products ability to detect rootkits.  For people that don’t know, a rootkit is a program that takes complete control of a system, and tries to hide itself deep within the operating system.  They are notoriously difficult to detect once they are installed.  The most interesting result from this test wasn’t necessarily the results about which product detected what, but the revelation that Vista’s security framework, specifically User Access Control (UAC) was really effective at preventing rootkit infection.  The test took 30 rootkits written for Windows XP and tested various anti-malware and anti-rootkit suites.  Some of them scored fairly well, but none were perfect.  Of the 30 XP rootkits, only 6 would actually run on Vista, and in order to get them to run UAC had to be disabled.  This means that UAC has significantly raised the bar of entry for rootkits on Windows.  This shouldn’t really come as a surprise to anyone familiarly with this area, but there seems to be a lot of loud mouths shouting that UAC is worthless and should be disabled.  I have an anecdote that tells a different story.

The last product that I worked on was essentially a rootkit.  It was a component of a broader intrusion detection system which needed real-time information about what was going on in the system.  We wrote a simple device driver that intercepted all events within the kernel and logged them out to a database.  This means that every file, registry key, key pressed, port opened, etc, was visible to this program and logged.  We originally wrote it to work on XP, and an application to install it as a service, which involved a couple of calls to the Service Controller to install it.  If the user was running with an Administrator account (which everyone in XP does) then the driver would be loaded completely invisibly.  That means that any program that you have ever installed could very easily be spying on everything you, or any other user on your machine does.  I say it could be “very easily” doing this, not because the code is particularly easy to write, but that the Internet is absolutely littered with rootkit code, especially the .cn domain.  A little while ago we decided to update our driver to work under Vista.  Since rootkits are essentially an extension of the operating system, they become very dependent on certain structures and features of an OS and tend to only work under that version.  So we had to change the code a little bit to get it to run, but for the most part, it was the same program.  The only real difference between the two version was that on Vista, even if the user is logged in as Administrator, the installation of the service would fail if it wasn’t elevated with a UAC prompt.  Privileges in Windows works with tokens; each user and group has a token, there is a system level administrator token, etc.  When a program starts, it is given the token of the user, and is run with what ever permissions that the user has.  So, users of the Administrator group in XP would pass along Administrator, or system level, permissions to any applications.  The difference between XP and Vista, is that when a user is in the Administrators group their token in Vista is not a complete system access token.  For an application to receive system level access, it must be spawned by a system level user group (SYSTEM, LOCAL SERVICE, etc) or being elevated by an administrator with a UAC prompt.  This prompt assures that the user behind the keyboard is aware that they are giving this application complete access to the system.  Sure, it can get a little annoying from time to time, but I’d rather have a prompt alerting me every so often as opposed to a rootkit silently being installed.

When a File Exists, but Doesn’t

I stumbled across a rather obnoxious “feature” in Vista today that I thought I should share with everyone.  With Vista, Windows finally enforces file system permissions and separates applications from user data.  It does this by restricting write access to the C:\ directory.  A user can read and write freely in their C:\Users\$username\ directory, but when they try to write to C:\Program Files or C:\Windows, they are presented with a UAC prompt that demands administrator privileges.   

This poses a problem for legacy applications that weren’t written with Vista’s security model in mind.  When you launch a program you are starting it with your permission set, which by default doesn’t have write access to the C:\ root.  If a program tries to write to say, C:\Windows, it will be denied.  To ease compatibility problems, Vista redirects these programs to a virtual directory that the program does have write access to.  A program trying to write to C:\Windows will be redirected to C:\Users\$username\AppData\Local\VirtualStore\Windows and will never know there was a problem. 

I discovered this the hard way this morning.  I have an application that normally needs to run with elevated privileges.  It has to start a kernel-mode service, read a log file in C:\Windows and write its own log file there.  When the application starts up it loads its own log file and displays it to the screen.  I wanted to run the application with a clean slate, so I stopped the service, deleted the services log and deleted the applications log.  I started up the program and was surprised that it was still loading its log file.  I thought I had deleted it!  Both Explorer and the command prompt claimed that the file was gone.  I tried to enter the path directly into Explorer and it couldn’t load the file.  But still, my application could load it.  I thought there might have been some strange caching with .Net applications, so I wrote a Win32 C program that loads the file and that one worked too!  So, now I’ve got two applications that claim to be loading a file that doesn’t exist!  Now I’m starting to get confused.  I run my program in Debug mode and drop into the debugger when it tries to load the file.  I was hoping that the debugger could give me more information about the file that it’s loading.  Even the debugger is telling me that it’s loading a log file in C:\Windows that doesn’t exist!  How can a debugger lie?  Ok, I know the answer to that, but it really doesn’t apply here…  The most bizarre part of this is that I could read the file from the command prompt with Edit, but only if I ran as a standard user, not an administrator.

As you can see, the admin prompt loads nothing, but the standard one loads the log.  What could possibly be going on here!?  It turns out, the Vista developers decided it would be better to completely lie to an application instead of allowing it to crash.  Apparently, I opened my application once as a standard user, and it got redirected to C:\Users\$usersname\AppData\Local\VirtualStore\Windows and wrote the log there.  Whenever an application tried to load a file from a protected folder, it will check that location, and then check the Virtual Store.  If the file is in the VS, then the application is given a handle to that, but the OS never tells the program where the file actually is located.  This keeps the transition invisible to legacy programs who will end up just reading and writing from the virtual store.  This would explain why Edit could only find the file if it was opened under standard user, since the admin one wouldn’t know which user’s virtual store to look into.

This was all quite aggravating to me and violates venerable UNIX law:

when you fail, fail loudly with lots on information to stderr

I guess this is what happens when you try to make changes to a system but still support backwards compatibility.  My opinion is that developers have been allowed to abuse the user permission system in Windows for too long, and don’t deserve the niceties provided but this feature.  If you want to write in a protect folder, you must run with elevated privileges, otherwise you catch the error or crash.  This Virtual Store is no more than a lie and operating systems shouldn’t lie.

Vista SP1

 

Microsoft released Service Pack 1 for Vista on Monday so I thought I’d give it a spin.  It will be rolled out through Windows Update over the course of the next month.  If you are impatient, you can downloaded the pack directly from their website (32-bit / 64-bit).  There are a number of drivers that are incompatible with SP1 so Windows Update will wait until those incompatibilities are resolved before showing you the update.  If you chose to install yourself be sure to read up on the current issues before you do it.  There is also a short list of incompatible programs to be wary of. 

The most notable changes seem to be better and faster file copying, DirectX 10.1, exFAT support for large Flash drives, fewer UAC prompts, and a host of security improvements.  There are literally hundreds of changes added to Vista in SP1 so grab the Notable Changes white paper and give it a read.

My update went smoothly.  It took about an hour, maybe 45 minutes, and rebooted a couple of times.  I grabbed the stand alone installer from the Microsoft website because WU hadn’t offered it up to me yet and I’m terribly impatient.  I don’t recommend doing that though, unless you are fully prepared for potential problems.  I’ve read about a few horror stories online already, but I’m not sure how much merit they have.  For what it’s worth, it’s been smooth sailing over here and I’m enjoying a slightly more responsive Vista.

DbgPrint output in Vista

I’ve been tasked with updating our kernel mode driver to build off the Server 2008 WDM and run in Vista.  Updating to the 2008 WDM was relatively painless.  There were a couple of new deprecated functions but the adjustments weren’t hard to make.  So, I set up a Vista virtual machine for debugging, attached WinDbg to it, and fired up our service.  To my dismay, none of the DbgPrint() statements that the driver outputs were being shown in WinDbg!  Without debugging output it is almost impossible to debug a device driver.  A little bit of digging online lead me to a great device driver blog: A Hole In My Head

It turns out Vista maps every call to DbgPrint() to the newer DbgPrintEx() function. 

ULONG DbgPrint( IN PCHAR Format,. . . .  [arguments]);

ULONG DbgPrintEx(
                           IN ULONG ComponentId,
                           IN ULONG Level,
                           IN PCHAR Format,
                           . . . .  [arguments]
                          );

DbgPrint is supposed to work just like the printf function except it writes to output to any debugger that is attached.  You would pass in a format string followed by a valist of arguments and it would write it out a debugger.  DbgPrintEx works to same way, but added two new arguments with the intention of filtering the system output.  The ComponentID specifies the type of driver that is writing the output.  The possible values are:

DPFLTR_IHVVIDEO_ID

DPFLTR_IHVAUDIO_ID

DPFLTR_IHVNETWORK_ID

DPFLTR_IHVSTREAMING_ID

DPFLTR_IHVBUS_ID

DPFLTR_IHVDRIVER_ID

 

The Level argument rates the messages severity on a scale of 0-31.  This way the host operating system, and ultimately the person debugging, can decide which messages it wants to see. 

Now, when Vista encounters a call to DbgPrint() it maps it to DbgPrintEx() with the DEFAULT ComponentID.  The set behavior for DEFAULT DbgPrint messages is to hide them.  There are three ways to change this.  One way is to go through your source code an change all the DbgPrints to DbgPrintExs with the ComponentID that most closely matches the device.  Unfortunately this function is only supported in XP or later, so this may not be possible for all drivers.  The other two solutions involve changing the output settings in Vista.

Attach a debugger (KD or WinDbg) and break the machine right after boot.  Enter the  command ‘ed nt!Kd_DEFAULT_MASK 0×0F’ into the debugger.  This will allow all types of DbgPrint output to be shown.  This is not a persistent solution so you will have do it every time you run the VM.

On the Vista virtual machine, open the registry and add the value “DEFAULT” : REG_DWORD : 0xFFFFFFFF to the key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter”  The next time you reboot the system it will output all of the DbgPrint output.

So that mystery is solved.  Now I just need to use my debugging output to figure out why my driver throws a kernel exception and blue screens my VM…