Windows Access Control

I just found an interesting paper: “Windows Access Control Demystified,” by Sudhakar Govindavajhala and Andrew W. Appel. Basically, they show that companies like Adobe, Macromedia, etc., have mistakes in their Access Control Programming that open security holes in Windows XP.

Abstract

In the Secure Internet Programming laboratory at Princeton University, we have been investigating network security management by using logic programming. We developed a rule based framework—Multihost, Multistage, Vulnerability Analysis(MulVAL)—to perform end-to-end, automatic analysis of multi-host, multi-stage attacks on a large network where hosts run different operating systems. The tool finds attack paths where the adversary will have to use one or more than one weaknesses (buffer overflows) in multiple software to attack the network. The MulVAL framework has been demonstrated to be modular, flexible, scalable and efficient [20]. We applied these techniques to perform security analysis of a single host with commonly used software.

We have constructed a logical model of Windows XP access control, in a declarative but executable (Datalog) format. We have built a scanner that reads access-control conguration information from the Windows registry, file system, and service control manager database, and feeds raw conguration data to the model. Therefore we can reason about such things as the existence of privilege-escalation attacks, and indeed we have found several user-to-administrator vulnerabilities caused by misconfigurations of the access-control lists of commercial software from several major vendors. We propose tools such as ours as a vehicle for software developers and system administrators to model and debug the complex interactions of access control on installations under Windows.

EDITED TO ADD (2/13): Ed Felten has some good commentary about the paper on his blog.

Tags: academic papers, Adobe, Microsoft, operating systems, privilege escalation, vulnerabilities, Windows

Posted on February 13, 2006 at 12:11 PM • 19 Comments

Comments

katre • February 13, 2006 12:40 PM

Hmm, I’m much more interested in their “declarative but executable (Datalog) format” for modelling access control, and wonder what would happen if:
a) This was applied to other OSes, like Solaris or Linux, and
b) How difficult it would be to make this widely available to developers so they can check their own code for this type of vulnerability, before it’s released.

mpd • February 13, 2006 12:52 PM

Setting file permissions in code for Windows is overly complicated. There are three ways to do each thing, and none of them are documented well enough to anything other than the standard operations.

They also made it incredibly easy too… all you have to do is define a NULL DACL and everone has access to the object.

It’s no surprise that people (myself included) do it incorrectly.

joh • February 13, 2006 1:07 PM

@katre: “Datalog is directly executable in Prolog”, so it’s said in the article

Much more interesting: “We have a scanner that
reads relevant parts of the Windows registry, file system, and service control manager database on a given
host to provide input to our logical model”

I want those scanners 🙂

There’s a in some ways similar design being developed at the technical university of Munich (tum.de) called UMLSec, which allows security requirements to be described in UML diagrams. There seems to be a toolset that then allows you to reason if one component can endanger another.

Of course, Princeton’s model is kind of “more relevant right now”.

Andre LePlume • February 13, 2006 2:01 PM

I didn’t RTFA, but this sounds a bit like a super-charged version of COPS’ “Kuang” expert system.

Alun Jones • February 13, 2006 2:08 PM

I’ve done a little of my own summarisation of this paper at http://msmvps.com/blogs/alunj/archive/2006/02/08/82862.aspx – after I realised that it was the inspiration for a recent Microsoft Security Advisory http://www.microsoft.com/technet/security/advisory/914457.mspx

The use of Datalog / Prolog is not terribly important, and seems more a case of having a tool that the author knew to do the job – essentially, the author is building a graph, where links are specified from simple rules (“User of type X can write to file that is routinely executed by User of type Y => User of type X can become User of Type Y”) run against a database of access rights. He’s then taking two points (“User is of type Restricted User”, “User is of type Administrators”), and seeing if there is a route between the two points.

Graph theory, project management (Critical Path Analysis), AI theory, all have ways of solving this problem. Scanning for ACLs isn’t a huge task, either – you define a class of object, how to enumerate the object, and you have a means to build a list of ACLs. The skill is in building the set of rules that dictate the shape of the graph.

Too many rules (“Hey, I can write to an EXE in my temp folder, and an Administrator might run that”), and you get a statement that, while true, indicates almost nothing about the state of security on the system, because the number of false positives is huge.

Too few rules, and you’ll miss some very entertaining possibilities for exploits.

I imagine a future where this tool is available for system administrators to run against their installed base, to determine whether they accidentally created a chain of elevation.

Unfortunately, that’s a somewhat nebulous future, because if such a tool were released now, it could prove dangerous, as script kiddiez use it to pump up the power of their latest virus.

As for it being too easy or too difficult to create DACLs, I’d counter with the obvious note that it’s almost always safe to stick with the default DACL (a NULL Security Descriptor), and it’s almost never safe to create a NULL DACL (which is harder to do – more lines of code – than to use the default DACL).

Anonymous • February 13, 2006 2:34 PM

Edward Felton has some pretty good commentary on the report on his blog.

http://www.freedom-to-tinker.com/?p=970

joh • February 13, 2006 2:42 PM

Very well said, Alun. But NOT releasing the tool after the word is already spreading that there ARE vulnerabilities to be discovered it’s solely security through obscurity.

Also, if Script Kiddies today can make sense of a Prolog prompt, they must’ve become mighty intelligent.

Alun Jones • February 13, 2006 3:28 PM

@joh: The paper alludes to vulnerabilities discovered in four services, and two third-party applications. It does not say that these are the only such vulnerabilities, nor does it suggest that the testing was exhaustive, against every vendor’s product, or every Windows-default ACL.

So, if you release the tool, you provide people with the ability to scan their own systems, with their choice of third-party software.

You seem to be arguing from the point of view that the authors of the paper have completely discovered every possible escalation issue. I don’t think that’s the case.

AG • February 13, 2006 4:45 PM

I’m surprised you aren’t going on about the two Air Marshals arrested for smuggleing drugs.

AG • February 13, 2006 4:47 PM

On ACL’s;
Microsoft even got it wrong when they designed Exchange. The Send As Receive As rights were messed up for ages.

Ari Heikkinen • February 13, 2006 5:34 PM

I don’t think you can completely blame those companies. I think it’s more to do with the design of windows as such. Remember that windows wasn’t designed security in mind, and those companies still want their products to work without hassle. I mean, how many of us simply switched to admininistrator after fighting with the so called “access control” of windows which simply broke about everything we use?

nother example • February 13, 2006 6:09 PM

when win2k came out, the built-in outlook express couldn’t even run as a non-administrator user.

Soumik Sarkar • February 13, 2006 6:52 PM

As far as the scanner is concerned, Sysinternals’s AccessEnum does the same thing. It has been around for some time now (since 2002 I think).

joh • February 13, 2006 8:33 PM

@Alun: I’ll for the life of me never assume that anyone ever anywhere has a full list of bugs, security holes, potential loopholes. You can only optimize risk.

That said, the bad guys have to be right once, I have to be right every time. So not making the tool available is giving them a small nuisance, but for us “white hats” it could be a great asset.

I had some discussions with somebody working with UMLSec and we theoretically explored the concept of reasoning about security risks with mathematical tools.

Your argument boils down to “if I can’t see it, they can’t either”, which amounts to wrapping a towel around your head to avoid the Ravenous Bugblatter Beast of Traal. It only works against beasts that are daft as a hairbrush and as “The guide” states: The Beast WILL eventually realise its mistake and find you.

(sorry that I couldn’t resist the D.A. reference. Look it up: http://www.bbc.co.uk/dna/h2g2/A387029)

joh • February 13, 2006 8:35 PM

somehow the second and third paragraph got switched around while editing my post. I’m sorry, it’s the middle of the night over here. I’ll shut up now.

chase credit cards • February 13, 2006 10:25 PM

I find it amazing that windows has been around so long and still has so many security holes. I guess with more features comes more opportunities for security issues. Unfortunatly I seriously haven’t taken advantage of a new windows feature that I can remember since around 1999. Every time I get the next version of windows it seems to have some new things that are useful and many new things that just use my ram or are from paid advertisers.

alfredo • February 14, 2006 1:08 AM

This is a few days old. Microsoft has already published an advisory regarding this, and some PoC exploit code is already making the rounds…

Alfredo
http://www.areino.com

Woody • February 15, 2006 11:38 AM

In a previous life (job) I spent a lot of time writing code for server-ish apps on windows. The continually evolving namespace for shared objects (as terminal services and such came out), coupled with what appeared to be continually evolving requirements on how to properly lock down a box on the filesystem level was very, very, very frustrating.

Especially when the product was supposed to run either in a client-server mode and in a standalone mode.

We ended up writing a whole library just to deal with the naming of shared objects so that our subprocesses could communicate reliably. Depending on the version/service-pack level of the OS, we had to use different name prefixes to get cross-user access (for some client-server modes), and those prefixes were invalid to use in other versions of the OS.

Most people I know got so frustrated at the lack (or overabundence) of documentation that they’d throw up their hands, and go the null dacl route. It was either none, or multiple several hundred page documents on MSDN that tried to explain the API in excruciating detail.

Security shouldn’t be that hard to get setup. Not trivial, but not THAT hard.

Ari Heikkinen • February 15, 2006 7:32 PM

“Security shouldn’t be that hard to get setup.”

Exactly.

I think security, if anything, should be trivial to setup. The more trivial the better. Complexity is the worst enemy of security. Add even a little bit of complexity and the uncertainty of wether or not your system is secure will grow exponentially.

Windows Access Control

Comments

Leave a comment Cancel reply