And what’s even neater is that it’s a security hole waiting to happen – the reason the dialog pops up when you’re a LUA user is that they’re enabling the set date&time privilege on startup (rather than when they set the date&time).
That means that the applet runs with a privilege enabled, which violates the principle of least privilege (don’t enable a privilege until you absolutely need it).
Now since most users are admins, this isn’t a problem (they already have the set date&time privilege) but when users are LUA…
I received a private email from Skywing asking:
I was wondering why exactly you think that leaving a privilege enabled in a token is a security hole.
Any program (or conceivably exploit code delivered via a buffer overflow or similar mechanism) could call AdjustTokenPrivileges to re-enable a disabled privilege. Thus, I don’t see how enabling a privilege by default as opposed to disabling it by default increases system security at all.
In fact, I really don’t understand the reason behind there being the concept of disabled or enabled privileges, given that any program that is running under a user can change a privilege from disabled to enabled in their token.
Of course, this is completely different from adding or removing a privilege from a token. Clearly, adding additional privileges to a token can cause security problems, and as such requires special permissions. However, if a token has a privilege disabled, that privilege can still be used (after an AdjustTokenPrivileges call), so it doesn’t really prevent misuse.
Instead of writing a private answer, I figured it was worth a public one. The three word answer to why this is important is “Defense in Depth”. But it begs a more thorough explanation.
The principle of least privilege says that you run with the minimum set of privileges to accomplish your task. But the Date&Time CPL applet runs with the date&time privilege enabled all the time (not just when it attempts to change the date&time), thus violating the PLP.
You can think of a privilege as being a trump card over the normal security – privileges can allow the user to bypass the normal security mechanisms to perform their job. For example, the backup privilege lets you bypass the ACLs on the files on your hard disk. The restore privilege lets you set an arbitrary SD, including the owner field (normally the owner field in an SD is set to the user who set the owner (that’s why it’s called “take ownership”).
Another way of thinking about privileges is by having them disabled, it makes the application take another step before it can cause harm. A backup operator can see all the files on the hard disk – but they have to enable a privilege (which can be audited) in order to do it – normally, when running from the console, backup operators can’t bypass security.
The thing about privileges is that they provide sort-of an “alternative ACL” mechanism – there are operations that need to bypass the normal ACL mechanism (like restoring the ACL on a file that’s being restored from tape). You can’t have an ACL that protects the restore process, because the restore process has to have an ACL. Similarly, since there’s no clock object in the system (and no, I don’t know why there’s no clock object), there’s no way of having ACLs to protect the ability to change the system time. So you need a mechanism to perform these operations WITHOUT using ACLs. Privileges provide that mechanism.
The other thing to remember is that not all users have all privileges. When running as a local administrator, I have most of the privileges, but not all of them – for example, I don’t have the TCB privilege (that’s the “Act as a part of the operating system” privilege). The TCB privilege is the holy grail of hackers – if you have the TCB privilege, you own the system (and if you’re an administrator, the escalation path to gaining the TCB privilege isn’t particularly hard).
Privileges that a user has that aren’t enabled are a speedbump – putting the “trump cards” in a privilege reduces the potential for someone who has that privilege from accidentally causing harm.
Running with a privilege enabled is like running with sharp pointed sticks in your hand. Most of the time you’re just fine. But what happens if you trip?
Now consider the Date&Time control panel applet. It runs all of it’s UI with the privilege enabled. This means that if there’s an exploitable buffer overflow in the UI, then a bad guy who wants to change the machine’s time just has to find the exploitable buffer overflow to work his will with the system. If, on the other hand, they had only enabled the change time privilege around the call to set the date&time, then there’s a huge amount of code that isn’t vulnerable to attacks. By applying the principle of least privilege, and only enabling the privilege when it’s needed, the attack surface of the product is reduced. It’s not eliminated – Skywing’s totally right, the exploit could simply chose to enable the privilege and move on.
Further, let’s consider a hypothetical system where the user DOESN’T have the date&time privilege. And the attempt to enable the date&time privilege causes an authentication dialog to come up (sort-of like what OS X does today). In that case, the privilege would only be enableable after the user was prompted. If the prompting happened before the UI came up, the attacker would have a large viable target, if the prompting happened only when the change was happening, the target would be WAY smaller.
In general, even if you have a privilege, you don’t want to have it enabled all the time. Because enabling the privilege is a speed bump.
And defense-in-depth is all about putting as many speed bumps in the system as possible. If you make the hackers job hard, then maybe they’ll leave you alone (or rather, they’ll go find someone with fewer speed bumps).