"Windows Access Control Demystified" - demystified.
There's been a little fuss raised in security research circles about a paper by Sudhakar Govindavajhala and Andrew Appel, titled "Windows Access Control Demystified".
From looking at what it does, the paper quoted is actually surprisingly simple - but there is brilliance in the decision to attack the problem (who would guess it was a tractable problem?) and make it so simple in the first place.
Sudhakar & Appel use Prolog - an old, old, old AI language - to document simple logical predicates and conclusions, such as "if group G can access a resource R, and user U is a member of G, then U can access R", which is really easily expressed in Prolog. The real goodies are conditions like "if U is compromised, and U can write to R, and user V can execute R, then V is compromised". Then he just lets Prolog go off and do its thing.
Prolog's "thing" is to take such a list of conditions, and a few starting axioms (the two obvious ones Sudhakar uses are "user Guest is compromised", and "a Restricted User is compromised"), and infer conclusions such as "Local System account is compromised", or "Administrator account is compromised".
Embarrassing fact: that's nothing surprising - we're all well aware that there are likely to be numerous routes to compromise hanging around in most systems. These are called "privilege escalation attacks", and they are why good administrators pay attention to what their users do even after they have restricted them as to what they may do.
The joy of Prolog is that it tells you how it got to its answer. For instance, in the case of yesterday's Microsoft Security Advisory 914457, it'll tell you that if the Restricted User is compromised, the Local System is compromised because the SSDP service can be configured by any Restricted User to run any executable under any account.
Most of the task of creating the input to Prolog can be done automatically, by analysing the system's current configuration and generating lists of access privileges to system objects.
I hope that this tool - or something like it - will initially be used by Microsoft to help lock down their systems, and later be used by application developers to help lock down their own application installs; eventually, it would be nice to find it in place in businesses, where system administrators would use it (among others) to keep track of their security exposure as they change configurations.
Sadly, I predict that it will be used at greater speed by hackers and crackers in order to find and exploit vulnerabilities.
Expect a rash of security advisories from Microsoft and third-party software developers, and a number of viruses that use these privilege-escalation exploits along with standard social engineering to attempt to gain access to your systems.
However, it is important to note that this tool does not discover points of entry - it assumes that you already have some access to the system, either as Guest, or as a Restricted User.
The best way to keep these elevation of privilege attacks from being a bother to you is to not grant any privilege to people you can't in some way trust.
The information in this paper cannot be used to create a worm, because it does not document or examine the points of entry into a system. As with all security tools, even if you fixed all the problems it reported, you couldn't say that your system is secure, because the tool is only as good as the data it gets - and that data is going to be incomplete. Tools alone cannot secure a system.