Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why did I say that the Date&Time control panel applet was a security hole waiting to happen?

Why did I say that the Date&Time control panel applet was a security hole waiting to happen?

  • Comments 23

In response to a comment I'd made on Raymond's post about the Date/Time CPL:

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).

 

  • The speed bump can even be a roadblock if the vulnerability requires the privilege in order to be effective. For example, consider:

    VulnerableFunction()
    {
    EnableBackupPrivilege();
    BadValidationResultsInWrongFileBeingOverwritten();
    BackUpTheFile();
    UpdateLogFile();
    RevertBackupPrivilege();
    }

    Moving the backup privilege calls to just around BackUpTheFile() would have stopped this attack. The attempt to overwrite the wrong file would have failed due to lack of privilege.

    Remember, code injection is not the only type of attack.
  • Thanks Raymond, sometimes I forget the forest in favor of the trees.
  • Ah, yes, Backup and Restore -- someone else actually pointed this out to me later in the day after I asked you.

    I suppose it's a special case in that it actually changes the default behavior of the system (rather than just letting you do something instead of not being able to do something).
  • Ah, yes, Backup and Restore -- someone else actually pointed this out to me later in the day after I asked you.

    I suppose it's a special case in that it actually changes the default behavior of the system (rather than just letting you do something instead of not being able to do something).
  • It's interesting that Windows Server 2003's ACL editor takes the Restore privilege in order to allow you to set the owner of a file (or other object) to someone else. Earlier versions do not permit this - you can only take ownership, you cannot grant it, and of course only if the object's ACL permits you to.

    My problem with OS X-style password prompts is that they're a) easy to fake and b) get the user inured to entering the administrator password, so they may not be careful about when they do so. This, after all, is why Windows has single sign-on - in the hope that if a password prompt doesn't happen that regularly, users will think about whether they should be entering a password.
  • Consider also that you do make the job of the exploit code more difficult - it's entirely possible that a worm wouldn't call to adjust its privs, causing it to fail. If you're worried about injected code, where space is at a premium, the extra API call (not to mention finding the entry point) might be just enough to make the attack infeasible.
  • Running with a privelege disabled is not defense in depth because the depth you are adding is so razor thin that it does not contribute to the defense at all. In fact you are opening yourself to more security issues if you believe you are defending yourself by running with priveleges disabled. Thats why I still agree with Skywing and I dont agree with this entry at all.

    By the way, FIRST POST!
  • G, actually 7th comment (but who's commenting). And check Raymond's first comment - it describes another way that PlP can be a DiD.

    Yeah, the blog software sucks. But I didn't chose it. Hopefully some of this gets better soon.
  • FWIW, I was mostly trying to argue that simply leaving a privilege disabled doesn't really do much from a principle of least privilege standpoint, because it's so trivially easy to re-enable the privilege (and doing so doesn't require crossing any additional security barriers because you've already been granted the privilege).
  • Skywing, you're right. It's nothing more than a barrier. If the bad guy can get code running, then they can enable the privilege. But it's a speedbump.
  • I love the content on blogs.msdn.com but someone should hit the Community Server team with a clue-by-four. The site times out several times a day, and the subjects over-HTMLEncode themselves.
  • Hehe, I like how the & in the title of the post becomes & in the input box for the title of the comment, which then becomes & when you actually post it...

    Anyway, while I don't think the "set date&time" privilege is the most destructive in the world, it's always a good idea to just follow the PLP all the time, rather than trying to think about when a good time to do it is, and when it's probably not a big risk.
  • Dean, SetDate&Time is an astonishingly dangerous privilege.

    Think about it for a while.

    Here's a hint: http://blogs.msdn.com/larryosterman/archive/2004/09/29/235898.aspx
  • It seems there are lots of problems with ampersands on Microsoft websites. I've reported a similar issue with the Knowledge-base RSS feeds which has yet to be fixed. But in that case, it makes the feed unusable (am I the only one who uses the XmlTextWriter to output their RSS?!).

    And I'm aware that this blog uses Community Server and it's out of your control, but I still think that it's funny that it is such a common problem.

    To be fair, it's a problem with a lot of sites, and it's even worse with a lot of RSS feeds.
  • Regarding the "speedbump": I've seen several security guys who see security as a binary value. This leads to think that a feature which makes an attack harder (but not impossible) is worthless, and even gives a false sense of security.

    Well, security is not binary. My car alarm doesn't have to be burglar-proof; it just needs to be more difficult to break in that most burglars will give up (or, more difficult than the car parked next to me).
Page 1 of 2 (23 items) 12