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. 

Meshing the Common Feed List

Last week I blogged a little bit about a new cloud syncing product called Live Mesh.  I mentioned how in its current incarnation it really only serves as a file syncing and sharing tool, but in the future it will have an open API that will allow programmers to add application specific data to the system instead of whole files.  I concluded with a short wish list of programs that might take advantage of this API which included a cloud synced RSS feed list.  Well, I was playing around with this the other night, and figured out that this can already be done with just the file-based Mesh.

Quick Background:  with IE7, Microsoft introduced what is known as the Common Feed List within Windows.  When you click on the little orange RSS icon in IE and subscribe to a feed, it gets added into a system wide collection of feeds.  There is a background service that keeps all of these feeds up to date.  The feeds are then visible to any application on the system that wants to interact with them.  Right now, FeedDemon and RSS Bandit interact with the Common Feed List as well as IE, Outlook and Live Mail.  So, as far as offline feed readers go, the Common Feed List is a pretty good idea.  What I would like to do is push that list up into the cloud, and allow me to access it from any computer I’m at.  I’m not talking about just an OPML file of feeds that I’m subscribed to, but instead it’s a full version of the CFL, including a read and unread marking on all entries.  So far, I think I’ve got a working solution.

In Vista, and Feed List is stored in

C:\Users\$USERNAME$\AppData\Local\Microsoft\Feeds

and, in XP it is in

C:\Documents and Settings\$USERNAME$\Local Settings\Application Data\Microsoft\Feeds

I just added that folder to Mesh and synced it to that location on all of my other machines.  It seems to work like a charm.  While Google Reader is probably a better solution to all of this, I still sort of like this set up.  You must be careful to allow Live Mesh to update before the Common Feed List does, or your read/write tags will get a little messed up.

[UPDATE]

I’ve been running this set for about a week or two now and I can say for sure that it does work, however it will clutter your Recycle Bin with .feed-ms files.  Why?  I cannot explain…

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.

.NET Framework Library Source Code now available

Microsoft has made the source code for the .Net framework available.  It has been released under a read-only license which has an interesting clarification: “the license does not apply to users developing software for a non-Windows platform that has “the same or substantially the same features or functionality” as the .NET Framework.”  Does that mean that the Mono team can look at the source code and not be bound by the read-only clause, or that they can’t look at the source at all?  I’ll have to read the license and find out. 

There are detailed directions on how to get source code debugging set up in Visual Studio 2008 posted here [blogs.msdn]:

.NET Framework Library Source Code now available – ScottGu’s Blog [Announcement]

Updated Kernel Debugging

In my last post I explained how to set up kernel debugging with WinDbg and a Virtual PC running Windows XP.  I understand that this is a little outdated now, and there are some people that may be wondering how this can be done if the Virtual PC is running Vista.  The process is nearly identical to the one I outlined in my previous post, with the exception of step two.  In Vista, Microsoft changed the way boot options are defined and replaced the manual editing of a boot.ini file with an application called BCDEdit.exe.  This program can be invoked from the command prompt and you must use it configure your Vista boot for debugging.  Windows Hardware Developer Central has a step-by-step explanation that I am not going to try to reproduce here.  If you are interested, follow this link.

Kernel Debugging: WinDbg and Virtual PC

My new job has me doing a lot of device driver development, which naturally leads to quite a bit kernel debugging and system crashes.  Thankfully, with WinDbg and Virtual PC it is simple to set up kernel debugging for a virtual machine.  Since I am developing for a Windows environment, I am using Virtual PC 2007 and WinDbg.  This process will also work for Virtual PC 2004.  This is all probably possible with VMWare, Virtual Box, or any other virtual machine program out there, I am just not sure of the steps.  The following steps are all you need to get debugging, assuming that you have a Windows virtual machine already set up:

Step 1:  Edit the settings of you virtual machine to use a named pipe for a COM port  

Edit
Settings
COM1 
Named pipe:
Add: \\.\pipe\vpcdebug

Step 2:  Edit boot.ini file on the virtual machine.

Right-click on My Computer
Properties
Settings
Edit start-up file manually:

Add: /DEBUG /DEBUGPORT = COM1 /BAUDRATE=115200
I like to add a second line here instead. Copy the last line, and append it with the above line:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
/DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200

This will give you two different boot options, one for debugging and the other for normal use.

Step 3: Set up WinDbg for remote debugging over COM1.
This can be done through the File -> Kernel Debug menu, but I prefer to make a shortcut so I can have multiple different types of debugging environments.

Create a shortcut that points to WinDbg.exe and add the the necessary command-line arguments. Your shortcut target should look something like this:
"C:\Program Files\Debugging Tools for Windows\windbg.exe" -k com:pipe,port=\\.\pipe\vpcdebug,resets=10

 This is all you need to do to set up kernel debugging.  Be sure to start the VM before WinDbg so that it has a chance to create the named pipe.  Also, make sure you download the correct symbols for your environment.  For example:

SRV*c:\websymbols* http://msdl.microsoft.com/download/symbols

Debugging Tools for Windows
Virtual PC 2007

Scripting on Windows – PowerShell 1.0

For years Windows users and administrators have had to live without an inadequate scripting shell environment.  Sure, there is Perl, Python, and CMD.exe, but those never really could keep up with the all-in-one Swiss army knife of a shell Unix administrators gets to use.

Enter stage left:  Windows PowerShell.

Described as both a shell and a scripting language and designed for IT professionals and administrators, PowerShell provides all of the functionality expected from a scripting shell plus some more.  There is a free book available online that serves as a nice introduction to the program.  The download requires you to log into your .NET passport account.  If that’s a problem for anyone, let me know.

It is important to note how PowerShell is fundamentally different from all other shells.  Unlike most shells, PowerShell uses an object-oriented model based on the .NET framework for input and output.  Here is an excerpt from Frank Koch’s free text, “Windows Powershell” explaining what that means:

PowerShell’s object-oriented concept makes the standard parsers for Unix shells (analyze/evaluate) and text-based information with all its problems and error proneness completely superfluous. To make this clearer we provide the following example: Assume that you would like to have a list of all processes that consume more than 100 handles. With a traditional Linux shell you would call up the command for displaying processes (ps -A). The command then returns a text list. Each line would contain information about a process, separated by spaces. You would parse these lines with a tool, filter out the process ID and then query this with another program to find the handle number. You would then parse these text-based results, filter out the relevant lines and then finally display the relevant text.

Depending on how well cutting and filtering of information from the text lists functions, this approach is more or less reliable. But, for example, if the title of a column in the output changes and the process names are then too long, you will certainly have problems.

PowerShell uses a fundamentally different approach. You also start with the command get-process, which returns all running processes in the operating system. Only here they are returned as an object list made of process objects. These objects can then be investigated for their attributes and directly queried – therefore you do not have to examine any text lines and split them into columns.

There is another good explanation that can be found by following this link.

I haven’t spent a lot of time exploring the uses or getting comfortable with the syntax, but it quickly becomes apparent how powerful and useful this application is.  Consider the following script:
(from “Windows Powershell” by Frank Koch”)

$a = new-object -comobject excel.application
$a.Visible = $True
$b = $a.Workbooks.Add()
$c = $b.Worksheets.Item(1)
$c.Cells.Item(1,1) = “Service Name”
$c.Cells.Item(1,2) = “Service Status”
$i = 2 get-service | foreach-object{ $c.cells.item($i,1) = $_.name;
$c.cells.item($i,2) = $_.status; $i=$i+1}
$b.SaveAs(“C:\Users\Public\Documents\Test.xls”)
$a.Quit()

Can you guess what that does?  Here’s the neatest part, because of line 2 ($a.Visible=$True) I was able to watch all of this happening in an instance of Excel that was opened in the background.  The scope and capability of this application leads to my next point, security.

It appears that Microsoft has learned some lessons from JavaScript and ActiveX scripting in regards to security.  Scripting is disabled by default, meaning any local or remote scripting file (*.ps1) cannot be run.  Built into PowerShell are four different security settings, in regards to signed scripting.

Restricted (Default) - No scripts are run
Allsigned - Only signed scripts are run
Remote - All remote scripts must be signed.  Unsigned local scripts will run
Unrestricted - All scripts are run

Beware, this setting can be changed by any user that can run the application, even if they aren’t an Administrator.  It’s very nice to see Microsoft implementing some security by default considering this will be included into Windows Server 2008 (Longhorn).

Windows Powershell
Powershell Team Blog
Windows PowerShell Script Repository

Easy Blogging – Windows Only

Windows Live Writer is easy to use application that allows you to publish rich content to any web blog.  Designed specifically for Windows Spaces blogs, it works flawlessly with almost any other blogger service.  It provides WYSIWYG formatting, images uploading, Live Maps, and an open SDK.  Its design allows for plug-ins and there are already three available.

Of course, it is not without it’s problems.  Currently, the program is still in beta, so you will encounter some strange errors from time to time.  That being said, I have never lost a post, or encountered an error that had an sort of adverse affect on my blog.  Also, the program allows for images to be uploaded directly your blog of choice, provided they support the newMediaObject API.  Apparently, Blogger.com does not support this, which is unfortunate.  Thankfully the writers of this application have included FTP image uploading. 

I’ve giving this a test run, and so far it’s been good.  Simple, strait forward, and no horrific bugs.

Windows Live Writer – Beta