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

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


Comments (23)

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









    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.

  2. Thanks Raymond, sometimes I forget the forest in favor of the trees.

  3. Skywing says:

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

  4. Skywing says:

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

  5. Mike Dimmick says:

    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.

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

  7. G Dog says:

    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!

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

  9. Skywing says:

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

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

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

  12. Dean Harding says:

    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.

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

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

  15. Jonathan says:

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

  16. mihailik says:

    Hey, guys, what are you speaking?

    I am running WinXP SP2 as non-admin. DateTime dialog just doesn’t work on double-click. There is nothing to say about privileges and defency in depth: it just does not work at all.

    Double-click pops up such dialog:


    Date and Time Properties


    You do not have the proper privilege level to change the System Time.




    I am very unsatisfied having no calendar around, but it is Windows.

  17. Jonathan,

    I agree with those security people – in these days of script kiddies where any fool can put together a pre-packaged string of exploits together and create a worm, speedbumps aren’t a real mitigation.

    But only against code related exploits (exploits that get code running on the local box). Consider Raymond’s example above – a piece of code that’s vulnerable to an information disclosure attack that would fail if it didn’t run with the backup privilege.

    And even for code execution vulnerabilities – often you have an extremely limited amount of room for your payload – forcing more code to be run in the payload makes the payload larger. Which makes it harder to exploit.

  18. Yesterday’s post on the principal of least privilege engendered some discussion about how important the…

  19. & bug half fixed (post title works, comments still broken [this post is a test of that theory])

  20. rickbrew says:

    The "protection from accident" argument is very useful in convincing users, especially non-techy users, to run with lower and more restricting accounts, and / or higher security in general.

    "Why do we need to set up this file system security?! I trust my friends!" … "What if they *accidentally* delete all your files?" … "Oh ok."

    People I’ve worked with before are generally unwilling to assert mistrust (or "not allowed to trust") of other people, especially if it’s someone they know or are friends with. But they are always willing to admit they’ve made simple mistakes in the past and that it’s not difficult for others to make mistakes as well.

    I had a friend one time who accidentally deleted his entire music directory because he had disabled the Recycle Bin *and* the "Do you really want to delete this?" dialog box. "Those are only for computer illiterate newbies!" And then he pressed Delete at the wrong place and the wrong time. I got a phone call, "Rick how do I get all my music back!?!?!" After that it was not difficult to convince him to re-enable those two safeguards.

  21. Joku says:

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

    That’s a big Maybe. If there’s "casual hackers" then it’d be reasonable to think so. However recent news seem to suggest more that there are people who write the exploits and tools for money. And even if they didn’t, the plain ol hacker would take any speed bumps as a challenge.

    While not exactly the same, did you know there were a copy protection that some thought of impossible to break, news just weeks ago were that while it took, get this, estimated 1500 man hours to develop dongle emulating driver code etc, they finally broke that.

    So while I agree with the auditing point etc, I very much doubt the speed bump argument holds when it comes to anything but casual script kiddies.. And even they may be using publicly available tools that get past these speed bumps.

  22. Dewi Morgan says:

    PLP does not protect you from privilege escalation by people who’ve already got you to run code as yourself. That’s not what it’s there for. That kindof stuff is the domain of firewalls, virus scanners, IDS, spyware scanners, passwords, and an electrified keyboard and mouse.

    But people running programs as you are not the only crackers. And crackers are not the only things that can make Bad Stuff happen. In fact, they are one of the least common.

    1) PLP protects you from cases where non-code-based attacks can cause problems.

    For example, take a fictional example: a calendar program could have a cool "what happenned on this date?" feature. It would load in a list of events, and you’d click a date, see what happenned on that date. Cool, right? But what if Mr Black Hat distributed a list-of-events file that exploited a buffer overflow to overwrite the program’s variables for the date and time, and hence could actually SET the date and time, for whatever nefarious purpose? Perhaps to 2040, so that all 32-bit-time-stamp dependant stuff on your system would break?

    Mr Black Hat wouldn’t be able to exploit that overflow, if the permissions weren’t granted whenever the program was open, rather than only when they were deliberately being set.

    2) PLP protects you from your own mistakes and the mistakes of others.

    For example, the original problem described meant that in the "set date & time" applet, pasting something from the clipboard or accidentally hitting any key on the keyboard could cause a large systemwide change to the date and time, without even needing to hit enter or click "apply" or "OK".

    This would then cause all scheduled system events between the real time and the incorrectly set date/time to trigger or expire, and they would then NOT trigger when they were meant to, once the system date was reverted (since they would be considered "already triggered").

    This would not have been an issue if the permission were only granted when the "OK" or "Apply" button was clicked.

    3) PLP protects you against bugs in the software.

    What if the software is incorrectly granting, say, admin level privilege instead? What if it increments the year rather than the minute if you increment the seconds past 60?

    Or what if an application is so badly designed that, despite having an "Apply" button, all changes are applied immediately they are input, without warning?

    I know that nobody would really design such a bad program. Certainly no large software house. Certainly not with any code that normal users would ever see, anyway. But what if, by the tiniest chance, they did? Then PLP would protect the user, by ensuring that at least the protected parts of the changes would only be made when the "Apply" button was pressed.

    4) Most importantly, PLP is Good Programming Practice.

    If you haev a file that your program will be making changes to, you don’t open the filehandle when the program starts up, write to it once the user has input their settings, then close the handle when the user closes the program. You wait until the user submits the changes, then open, write, and close, as closely as possible together, to reduce the window for things to go wrong. This is obvious to any experienced programmer: anyone who codes it differently is clearly a neophyte in need of lengthy mentoring.

    Same with any resource handles, whether those resources are database queries, network connections, or permissions: you grant, use, revoke. As close together as possible, to reduce the window for things to go wrong.

    Anything else is just Bad Style.

Skip to main content