If you grant somebody SeDebugPrivilege, you gave away the farm


By default, users can debug only processes that they own. In order to debug processes owned by other users, you have to possess the SeDebugPrivilege privilege. But don’t grant this privilege casually, because once you do, you gave away the farm.

If you let users debug processes owned by other users, then they can debug processes owned by System, at which point they can inject code into the process and perform the logical equivalent of net localgroup administrators anybody /add, thereby elevating themselves (or anybody else) to administrator.

If SeDebugPrivilege is equivalent to granting administrator privileges, why does it exist at all? It’s not so much to protect the system as it is to protect the user. It’s like the safety cover over the emergency power-off button. The purpose is merely to prevent you from pushing the button by mistake. If you’re a developer debugging a service, you can turn on SeDebugPrivilege so you can debug the service, without turning on all the other administrative privileges. That way, you can’t accidentally delete a critical file, for example.

The security investigations team have to deal with people who fail to understand that SeDebugPrivilege is (from a security perspective) equivalent to administrator. In one case, the finder contacted not the Microsoft Security Response Center but rather sent their “exploit” to high-level executives, who then had to transfer the issue to MSRC. And when informed of the misunderstanding, the finder just responded with a one-page rambling manifesto. As much as you are tempted to “just ignore the crazy guy”, every reported security vulnerability must still be taken seriously. There might be something in there buried inside all the craziness. After all, they said Galileo was crazy.

Comments (19)
  1. JamesNT says:

    Although I realize this is probably impossible, I would like to see the "one-page rambling manifesto" (with identifying information removed, of course).

    I have found people of such mindset to be endlessly humorous and I could really use a good laugh today.

    JamesNT

  2. Yuhong Bao says:

    I was going to argue that code injection would be impossible if you strip the debug privilege off the process in this article:

    http://blogs.msdn.com/oldnewthing/archive/2006/02/03/524071.aspx

    Except that don’t prevent hooks from doing hook injection, which don’t require debug privilege.

  3. Yuhong Bao says:

    BTW, some of the reasons why whistleblowing is so hard is that you can be easily called "crazy".

  4. Friday, March 14, 2008 3:30 PM by Friday, March 14, 2008 3:30 PM by... says:

    That is paranoid mindset. "If you let users debug processes owned by other users…"

    Restrict, restrict, restrict… With every new Windows release, more restrictions, and in the field – more security bloopers.

    No, I’m not Levicki. :)

  5. And MSVisual Studio 2003 requires the Debugprivilege to just debug your own app. We cannot use the installed compiler on our uni computers because they are restricted – of course. And the admins are to lazy to install the new version. BAH!

  6. "BTW, some of the reasons why whistleblowing is so hard is that you can be easily called "crazy"."

    Yes, and no number of qualifications, witnesses and evidence can ever tip the balance in such cases, as once someone is labelled as "crazy", they are never allowed to present a case.

    It is amazing how many "normal" people perpetuate this denial of reality out of some perverted sense of "loyalty" to their employers.

    I wish I could say this was uncommon, but I have witnessed it first hand so many times I suspect that it is more often the first recourse for any complaint of real significance than any legitimate process of investigation.

  7. GregM says:

    "And MSVisual Studio 2003 requires the Debugprivilege to just debug your own app."

    No it doesn’t.  It requires that the users be added to the "Debugger Users" group (or something like that).  This is a group made up by Visual Studio, and has no purpose other than allowing connection to the Machine Debug Manager.

    http://blogs.msdn.com/nigelwa/archive/2005/07/29/445155.aspx

    "So if you’re just hitting F5 in Visual Studio there shouldn’t be a problem. You will need to be in the “Debugger users” group for Visual Studio 2003 but this is a VS03 thing not a Windows thing. This group is created when VS is installed and allows access to the Visual Studio Machine Debug Manager component.

    Note things are a bit different in Visual Studio 2005 – there is no Debugger users group (nor the VS Developers group for creating web sites) and the whole LUA experience is much, much better."

  8. Cheong says:

    JamesNT: I second your idea. Also interested to know what is written.

  9. Myria says:

    Raymond, I’m so glad that you wrote this.  It’s sad how often things like this are misunderstood.

    Privileges like this are root-complete: if you have any root-complete privilege, you can acquire them all.  Granting only one or a few root-complete privileges can only be considered a safety feature, not a security feature.  Please consider them as such in your code.  The real security is to protect against these privileges being acquired maliciously, and not granting them when unnecessary.

    It’s not just SeDebugPrivilege, either.  Here are some other ones that are root-complete, but is probably not all of them:

    SeCreateTokenPrivilege – create LocalSystem token out of thin air then impersonate it

    SeTakeOwnershipPrivilege – overwrite any of a number of critical registry keys or system files

    SeLoadDriverPrivilege – load kernel driver

    SeRestorePrivilege – same idea as SeTakeOwnershipPrivilege

    Linux’s "capabilities" are essentially the same idea, and the same caveats apply.

  10. ""And MSVisual Studio 2003 requires the Debugprivilege to just debug your own app."

    No it doesn’t.  It requires that the users be added to the "Debugger Users" group (or something like that).  This is a group made up by Visual Studio, and has no purpose other than allowing connection to the Machine Debug Manager."

    Thanks, for your information. I was told that it needs Debugprivilege. However I did not challenge the statement. Today I tested it again, and now I am cured :)

    But I am a little bit curious about the description of the debugger group. Why does it say, that it only should be added to trusted users?? Is it safe to add the group to users in an university?

  11. Yuhong Bao says:

    "It is amazing how many "normal" people perpetuate this denial of reality out of some perverted sense of "loyalty" to their employers."

    And some of it is because of groupthink. Another reason why whistleblowing is so hard is that management is more powerful than you. They can fire you off, but you can’t go the other way.

  12. Yuhong Bao says:

    BTW, what is happening here is that people consider the status quo as "normal" and everything else as "crazy", espicially when their authority is threatened.

  13. Yuhong Bao says:

    Often retaining the authority is more important than admitting the truth.

  14. Yuhong Bao says:

    Another cause, BTW, is overconfident managers who refuse to admit that their product is not the best thing since sliced bread. Steve Jobs was once fired from Apple after the original Mac introduction because of this.

  15. dave says:

    >That is paranoid mindset. "If you let

    >users debug processes owned by other users…"

    … then you might as well not have bothered implementing a security system in the first place.

    Note that, on *your* Windows system, you’re perfectly free to give SeDebugPrivilege to all users, if you believe this is a pointless restriction.

    >Restrict, restrict, restrict… With every

    >new Windows release, more restrictions,

    I’m pretty sure this is no new restriction; it’s been that way since the first release of Windows NT, as far as I recall.

    Of course there was no such restriction in DOS-based Windows, since it had no security system to start with.

  16. Stoo says:

    And…the Galileo link doesn’t work.

  17. Ulric says:

    BTW, what is happening here is that

    people consider the status quo as

    "normal" and everything else as "crazy",

    not really.

    if you need to debug processes by other users, you need to be able to read and modify memory, and change order execution in those process.  

    So you can do everything, really, it’s not a security flaw, it’s not a time for security. You’re impersonating those other users at this point.

  18. Yuhong Bao says:

    Ulric: I was referring to the Galileo part.

Comments are closed.