Sunday, September 7, 2008

It's New & Shiny

This week I did an initial analysis of the security architecture of Google's new Chrome browser from an operating system standpoint, i.e. how Chrome leveraged Windows to apply the principle of least privilege. This immediately came to mind when I saw page 26 of Google's online presentation of their new Chrome browser.

It also turns out the software architecture in Google's new browser uses an approach that is much more common when writing back end network services. A technique known as privilege separation which page 26 also eluded to.

Privilege separation is merely a technique where the principle of least privilege is applied.

The crux of privilege separation is to create copies of yourself (an .EXE) and strip administrative rights as you do so. It is then those copies then handle inbound requests. So in the case of a web server, the initial instance of the executable (master copy) creates copies and it is those copies that do the actual work of handling inbound HTTP requests. The master copy (the parent of all the children) is simply an orchestrator and never directly interfaces with the outside world where HTTP requests originate. Other network services that follow this model include the venerable OpenSSH server (see image).

The advantage of privilege separation is that if malicious input is fed into a copy handling a request, it becomes much harder to compromise a system since copies have had their administrative privileges stripped. Malicious input's goal is to proxy through whatever is handling a request (copy of an .EXE) to in many cases modify operating system files and directories to nefarious ends. If a copy does in fact serve that end, that would constitute a system breach and what you now have is a serious flaw in the software system. Over the years many buffer overflow exploits in sundry network services have been significantly more severe simply because the technique of privilege separation was not employed. The difference can easily be a system that is compromised and falls into someone else's remote control vs. a much more likely denial of service scenario. Given the choice, I'll take the latter.

Not to say that privilege separation is a panacea. It is not. The technique simply makes a system much harder to breach. And being a technique, nothing says it can't be used on the client side of the equation (a web browser). So while all other web browsers have a single process (.EXE) that manages all browser windows and the tabs within them, Google's Chrome browser creates one copy of itself for each tab where HTML will be rendered and JavaScript executed. As those copies are made, their administrative rights are stripped making it much harder for malicious web content to compromise the computer system where Chrome is executing. Thus Google's Chrome browser applies the technique of privilege separation and immediately affords a level of insulation and resiliency to malware that heretofore hadn't existed in any other browser under Windows XP with its default security settings.

The principle of least privilege in action. Hallelujah.

This is not as big a deal for Windows Vista users but it is a very big deal for Windows XP users. That's because Windows Vista by default does not give users administrative privileges. Under Vista, when you want to do something like install a new application, you're prompted for an administrative password.

Windows XP on the other hand gives full reign (administrative rights) to users out of the box and this is precisely *why* malware has been such a large problem there (much to the delight of anti-virus vendors). Namely, people's browsers acting as proxies for the installation of malware as they promiscuously connect to foreign computer systems on the Internet with administrative privileges. Unfortunately, very few people understand the ramifications of operating in this manner and this extends to most people who make their living with technology.

Google's Chrome browser takes advantage of the Win32 security programmatic interfaces and strips administrative rights as it launches each copy of itself to handle each tab. The magic that allows this under Windows XP is the CreateRestrictedToken system call. The net result is that Chrome under Windows XP makes it much harder for your computer system to be compromised, irrespective of stop gaps measures like anti-virus software.

The level of mitigation is big. How big? Well, the reason Mac OS X has such little malware written for it is because Macintosh users do not run with administrative privileges making the economics of writing malware for Mac OS X a completely different propostion. Malware authors go for the low hanging fruit that are Windows XP users of which there are still plenty. Naysayers often claim, "Mac OS X doesn't have the same market" but that is simply not true. In August of 2007 Apple's market share of laptops hit 17.6% (20% is likely not far off). Apple is now the third biggest seller of laptops behind HP and Dell.

By applying the principle of least privilege Google with its Chrome browser severely mitigates the chances you will contract something like a keyboard logger while innocently visiting your favorite site. Therein lies the danger, increasingly sophisticated and organized criminal groups are breaching the web servers of legitimate businesses to serve up malicious content to unsuspecting users. In many of these cases, malware often comes in the form of keyboard loggers where once installed, absolutely everything you type is transmitted elsewhere in the hope you'll eventually use an online financial account. At which time you unwittingly divulge your username and password despite connecting to a legitimate financial institution (no, this is not phishing). Eventually Electronic Fund Transfers ensue. It's akin to poisoning the water well since as people visit their favorite watering hole (a legitimate web site) they are served up far more than water. As a play on phishing, the term pharming was coined to describe these types of scenarios.

In closing, kudos to Google for leveraging a programmatic mechanism (CreateRestrictedToken) that has been in place for many years. To this day I still do not understand why Microsoft never exposed the power of CreateRestrictedToken with a mass market end user tool or simply embellishing the way desktop shortcuts are created by providing end users with the ability to strip administrative rights in the form of a simple check box. That's because CreateRestrictedToken has been in every copy of Windows since Windows 2000 was released. As I said, many years.

Why 9 > 10

So I've been resistant to upgrade to Microsoft's Windows Vista for a number of reasons but probably the biggest is consistently observing Windows XP yielding higher Frames Per Second (FPS) with many DirectX titles. Windows Vista introduced DirectX 10 to the world and Windows XP users have had to be content with the older DirectX 9. I had read that Microsoft changed the video driver model for Vista to mitigate the infamous Blue Screen Of Death (BSOD) that has been the butt of jokes for many years but did not investigate further since my plans are to stay on Windows XP for quite some more time.

Here is a shining example of Microsoft being canon fodder on account of BSOD issues, it's a very old Sun Microsystems commercial from yesteryear (before Windows 2000) and pays homage to the late Jacques-Yves Cousteau (the narration). It's quite good!

It's also testimony to a long standing problem on Microsoft's operating systems based on the Windows NT kernel introduced in the early 90's. In Microsoft's defense, it can't control how video drivers are written by third parties, but nevertheless, less than perfect video drivers have been one of the leading causes of the infamous BSOD.

So curiosity finally got the best of me as I was talking about DirectX performance with a friend and I decided to investigate why seemingly Vista always loses to XP in sundry benchmarks I've seen in online articles and the printed word. I started with the following Wikipedia article about the Windows Display Drive Model introduced in Windows Vista:

When the Wikipedia article mentioned that part of a Vista display driver lives in userland the light bulb went on.

User space (aka userland) is where applications live, e.g., your web browser, your email client, your IM client, etc., etc. Kernel space is where the code that makes up the OS lives. Both of these terms are commonly used in systems programming.

So the question that beckons, when an application asks the OS (operating system) to do something on its behalf and execution transitions from your application to the OS, how does the operating system protect the stability of the system? After all, you as an application programmer might have just passed some errant arguments that could potentially bring down the system… or on the more sinister side, malicious code could have slipped in through your browser and is making system calls under the hood.

The answer is… with hardware!

The Intel architecture has a notion of “rings” when it comes to executing code (other processor architectures I’m sure have the same semantics, the nomenclature may vary). More on this in a second.

It turns out when executing code, more bits are at play than the usual 32 bits you sometimes hear about, i.e., I’m running 32 bit code versus I’m running 64 bit code. On the x86 architecture memory access is implicitly qualified with additional registers. These registers are called selectors and they happen to be 16 bits. The first 13 bits of a selector are an index into what’s called a Descriptor Table. 2 to the 32nd power is roughly 4 billion so it would seem a 32 bit Intel processor is incapable of seeing more. Such a statement is not accurate of what really is going on. You see, 32 bits refers to the context of a single application, the limits of its addressibility, not that of the processor's.

This means by varying the first 13 bits in a x86 selector register you jump from only having 4 billion memory addresses to:

2^13 (8192) * 2^32 (4 billion)

Which calculates to:


But wait, there’s more. The next bit (just one) says whether to go to the Local Descriptor Table or the Global Descriptor Table. So that means you can now double this figure. So you see, the “32 bits” people speak of does not really reflect the mount of memory x86 processors are really capable of managing.

Back to those rings. The last 2 bits in a selector register has to do with rings.

Applications (your browser) run in ring 3 a.k.a. user space. When an application asks the OS to do something, the OS changes last two bits of a selector register and transitions from a higher privileged ring to a lower privileged ring, e.g., from ring 0 (kernel space) to ring 3 (user space). Code running in a lower privileged ring cannot manipulate a selector register to transition back to a higher privileged ring. That’s by design since the OS cannot trust arguments passed to it. From a security standpoint this is sound. You maintain the integrity of the system continuing to provide basic services to other applications and you make malice hard at this particular layer. And there are so many layers… this is why the term computer security is such an overloaded term, has become hackneyed and means different things to different people.

But it turns out these ring transitions have an impact on performance! Any time you have boundary checks, whether they are metaphorical or literal (customs at the US border), things are slower than if you just let things through.

And with Vista’s display drivers partially living in ring 3 (user space), there are likely more ring transitions than the driver model found under Windows XP and its predecessors, hence the 10% to 15% drops (or worse) in performance under Vista.

So while Windows Vista is more stable and mitigates the blue screen of death problems of its predecessors, you get less bang for your buck as far as that screaming new video card goes (at least versus the guy who has Windows XP).