What Is “Privilege Escalation” on a CPU?

It’s a term you hear frequently of late, usually in the context of newly-discovered vulnerabilities in operating system software: “privilege escalation”. Recently we’ve even heard it in the context of a newly-discovered hardware issue.

On the surface, the term seems fairly simple, but as we know by now, when it comes to computers, it’s rare that anything is truly simple.

In this article, I’m going to look at one type of privilege: the privilege model used by your operating system to allow software to do useful things while simultaneously restricting what it can do, so as to keep you safe.

I will start with a caveat: in all modern operating systems, the nuts and bolts of what I’m about to cover are incredibly complex. Of necessity, then, I’ll over-simplify many concepts. This isn’t meant to be a treatise on operating system or CPU design, but rather a high-level overview of how some of that design impacts the average user. Pedants need not apply.

Days gone by

It might be easiest to start with past operating systems, specifically MS-DOS and Windows 9x (95, 98 and Me), which were based on MS-DOS.

All software running on an MS-DOS-based system was treated equally. Any program could, literally, do anything. Any program could play directly with the hardware, poke around in memory being used by other programs, or even modify the operating system itself on the fly.

It was not what we’d call “secure” in any way. I suppose the only thing that prevented it from being a security nightmare is that today’s ubiquitous connectivity didn’t exist. Compared to what we take for granted today, it was at least cumbersome, and often outright difficult, to get data from one computer to another.

There wasn’t a lot of point to malware, other than bragging rights.

Modern operating systems

On the PC platform, Windows NT was the first version of Windows to change all that. Beginning with NT, all software was not treated equally. Running software was placed into one of two buckets:

• Kernel – that portion of the operating system that can do anything, anywhere, at any time.
• User – that portion of the operating system, as well as all applications, that runs under some form of restriction with respect to what it’s allowed to see, do, or interact with.

Only the operating system is allowed to have software in the kernel1. The operating system must, by definition, be the most trustworthy piece of software on a PC. It has to be, so it can perform tasks including managing memory for all running programs, reading and writing files to disk, and controlling and coordinating access to all the hardware connected to the machine.

Everything else — from the applications you run to much of the rest of the operating system itself — run within the constraints of what’s generally referred to as “user-mode”2.

Security by restricted privilege

Since the kernel can do anything, we refer to it as having more privilege than software running in user-mode. There are a number of different things that can be restricted based on privilege, but memory access is one of the clearer examples.

A program running user-mode cannot read and write the memory of another program that happens to be running at the same time. Your web browser, for example, is not able to peek into the document you’re currently editing in a word processor.

Perhaps more notably, your word processor wouldn’t be able to peek into the memory being used by the password vault you happen to use within your browser.

And yet you want your word processor to be able to write to disk. That’s when privilege escalation happens.

Privilege escalation for good

When a program like a word processor wants to do something like access some hardware or write something to disk, it doesn’t do so directly. Instead, it asks the operating system to accomplish the task. Software running in user-mode transfers control to software running as part of the kernel, which has raised, or escalated, privileges so it can do its job.

Part of that job, of course, is to enforce security so user-mode software can’t make malicious requests of the kernel successfully. As long as the requests are valid, the kernel does its job, and when done, returns control to the software running in user-mode, at which point privilege is once again lowered to its more restrictive level.

Privilege escalation for evil

If kernel mode software can do anything, then you might imagine that having your software run in kernel mode might be a very desirable thing for hackers, and indeed it is. Many “privilege escalation vulnerabilities” are just that: opportunities for malicious software to run at a privilege level they’re not supposed to have. If successful, that software can then do anything.

Privilege escalation and hardware

The types of privilege I’m discussing here — the distinction between software running in user or kernel mode — is one that requires hardware assistance to enforce. Put more bluntly, the CPU must be capable of:

• Being told what’s allowed
• Doing something about it when someone tries to break the rules

It wasn’t really until the 80386 processor arrived that the PC world had the hardware necessary to handle all this. That’s why MS-DOS can run on any x86 compatible processor — it doesn’t need the support — but Windows and other modern operating systems require more modern CPUs with that more complete support.

Privilege escalation and performance

The software you run switches between user and kernel mode all the time. For example, as I discussed above, when you write a file to disk from your word processor, that request of the operating system causes elevation to kernel mode, and then a return to user mode. Since just about anything your software might do to interact with you or your computer requires privileged operation, it’s switching back and forth a lot.

Here’s the catch: compared to the other things a CPU does, switching is slow.

There’s a delicate balance in operating system design: on one hand, you’d like to reduce the number of escalations needed to do something, while on the other hand, you definitely want to securely restrict what arbitrary actions user-mode software might be able to take.

Security takes time.

Leaky boundaries

The most recent issue discovered with CPUs turns out not to be a privilege escalation issue, but more of an issue leaking privileged information across the privilege boundary.

Apparently, software crafted to exploit this vulnerability might, maybe, possibly, could perhaps gain access to data that should otherwise be restricted. The software continues to run in user-mode, but might be able to peek across the user/kernel barrier in some way.3

And all reports of the software fix for this hardware issue seem to indicate that performance might be impacted.

Now you know why.

The other type of privilege escalation

What I’ve been discussing to this point is a specific type of privilege assigned to software as it runs on your machine, as implemented by the operating system and CPU.

All software you use is generally flipping back and forth at incredibly high speed between user-mode, as the software does whatever it does, and kernel-mode, as it asks the operating system to interact with the computer’s hardware. Even just displaying something on screen or printing a document requires that some software — at a minimum, portions of Windows itself, as well as the device drivers — have escalated privileges to be able to interact with hardware.

That you may or may not have “administrator” privileges, for example, or that you might be able to write to this folder but not that folder, is a construct completely defined by the operating system, and has almost nothing to do with the CPU privileges I’ve been discussing above.

The rights assigned to the account you log in with are generally referred to as “user privileges”, but I’d clarify that term to “login user privileges”. While the terminology is similar, “login user” is your login account, and “user-mode”, as we’ve been discussing above, is a CPU operating mode.

The concepts are similar in some ways, and the CPU privilege model is key to implementing whatever user privilege model the operating system might want to support, but ultimately, they are two different things. One good way to think of it is that the CPU privilege model holds for Windows, Linux, and Mac OS running on Intel processors, but each of those operating systems have different ways of looking at user rights and privileges.

As I said, it’s rare that anything is truly simple, especially when the terminology for semi-related concepts overlaps in unrelated ways.

Bottom line: why should you care?

It’s important to understand that this concept of “privilege escalation” matters. Hopefully, understanding the concept — even at a high level and perhaps only partially — will give you some idea that it’s important, why it’s important, and how it relates to the security of your computer.

Knowing that it’s important, the single most important thing you can do to avoid issues and vulnerabilities that might be characterized as “privilege escalation” issues is to keep your system as up-to-date as possible. As with the recent CPU issue, operating system vendors are quickly putting out patches to avoid it, and it’ll be important for you to have those patches when they come up.

The best way to do that is to keep Windows — or whatever OS you run — set to update automatically.

Podcast audio

Download (right-click, Save-As) (Duration: 11:01 — 5.1MB)

Subscribe: RSS