How about not granting debug privileges to users?


Commenter Yuhong Bao suggests, "How about not granting debug privileges on the user? This will make bypassing the protection impossible."

This is such a great idea that Windows has worked that way for years.

Normal non-administrative users do not have debug privilege. They can only debug processes that they already have PROCESS_ALL_ACCESS to. In other words, non-administrative users can only pwn processes that they already pwn. No protection is being bypassed since you had full access in the first place.

The SeDebugPrivilege allows you to debug any process, even those to which you do not have full access. This is clearly dangerous, which is why it's not granted to non-administrative users by default.

Yuhong Bao also suggests, "How about separating the dangerous activities from the non-dangerous activities, or better, only allowing approved programs to do the dangerous activities?" (Where dangerous activities are defined as things that modify the program behavior.) I'm assuming this is discussing limiting the capabilities of SeDebugPrivilege, since in the absence of SeDebugPrivilege, the scope of your abilities is limited to things you already had the ability to do anyway; debugging didn't add anything new.

But even if you limited SeDebugPrivilege to nondestructive actions, you can still lose the farm. This imaginary SeLimitedDebugPrivilege would still let you read a target process's memory, which means you can do things like steal passwords and snoop on the activities of other users.

The last suggestion is to "only allow approved programs to do the dangerous activities." Again, I'm assuming this is discussing limiting the capabilities of SeDebugPrivilege, because without SeDebugPrivilege there is no new danger. But even in that limited context, what is an "approved program"? Approved by whom?

Must the program be digitally signed by Microsoft? I suspect people who write debuggers which compete with, say, Microsoft Visual Studio, would be upset if they had to submit their debugger to Microsoft for approval. And what are the requirements for receiving this approval? Does the debugger have to pass some battery of tests like WHQL? There are already plenty of readers of this Web site who reject WHQL as useless. Would this "debugger certification" also be useless?

Or maybe approval consists of merely being digitally signed at all? There are plenty of readers of this Web site who object to the high cost of obtaining a digital certificate (US$399; I don't think the $99 discounted version works for code signing.) And there are also plenty of readers who consider code signing to be payola and designed to maximize profit rather than effectiveness.

Or do you mean that the program needs to be listed in some new registry key called something like Approved Debuggers? Then what's to stop a rogue program from just auto-approving itself by writing to the Approved Debuggers registry key on its own?

But then again, all this is a pointless discussion once you realize that SeDebugPrivilege is granted by default only to administrators. And since administrators already pwn the machine, there's no protection that SeDebugPrivilege bypasses: You already bypassed it when you became an administrator.

Comments (33)
  1. Marquess says:

    This looks familiar. Indeed: http://blogs.msdn.com/oldnewthing/archive/2006/05/10/594537.aspx

    [Unintentional but somehow fitting that a factually correct but otherwise unhelpful article was generated in response to a question from Yuhong Bao. -Raymond]
  2. Yuhong Bao says:

    "Must the program be digitally signed by Microsoft? …"

    I agree that it would be going too far, and I did not intend to suggest this.

  3. Frank says:

    You need the discounted ($99) certificate from Verisign to create your Winqual account.

    For code signing, the best buy is a Comodo signing certificate purchased through Tucows. It is $75 for one year, $140 for 2 years and $195 for 3 years. Visit https://author.tucows.com/index.php?action=auth&redirect=certs.php

  4. Marquess says:

    “[Unintentional but somehow fitting that a factually correct but otherwise unhelpful article was generated in response to a question from Yuhong Bao. -Raymond]”

    In this day and age, it can’t be bad to repeat important information. As any parent can probably attest. It’s also helpful to repeat information.

  5. jon says:

    Microsoft has a history now of granting its own signed software special privileges, so it’s not that great a leap of imagination to think that this could be done as well.

  6. Marquess says:

    @jon:

    [citation needed]

  7. jon says:

    @Marquess: (from the above link)

    "it must be digitally signed by the Windows publisher, which is the certificate used to sign all code included with Windows"

  8. KenW says:

    @jon: That article doesn’t say what you think it says. It says that "applications" (not MS applications, but applications in general) took advantage of by default having admin access, which MS started restricting in XP/Vista and above. This is explained in the opening 3 paragraphs of the page you linked.

    Please read it again. It doesn’t support your post at all.

  9. Leo Davidson says:

    @KenW: The article, specifically the part Jon quoted in his follow-up just before your post, does support Jon’s claims. Maybe you didn’t read it to the end?

    (It also says what you say it says. Articles can say more than one thing! :))

    As the article says, binaries signed by the Windows publisher (i.e. a subset of apps signed by Microsoft, and no-one else), and stored in particular directories, get special powers.

  10. Marquess says:

    Binaries, signed by Microsoft, and stored in particular directories get special powers without user interaction (but only if this user is already running as admin). Every other application gets these powers with a UAC prompt. Sounds fair to me. Especially considering this sentence:

    "We understand the aggravation, and there might be a legitimate reason that those applications can’t run without administrative rights, but the risk is too high that developers will avoid fixing their code to work with standard user rights."

  11. WndSks says:

    @Marquess: The problem is, the default UAC level in 7 allows the signed whitelisted MS apps to be used by any program to elevate without prompt (Check Leo Davidson’s site, no need to go over this again; in 7, UAC != security)

  12. John says:

    On one hand jon is technically correct, but at the same time it was done to ease the pain of managing a system with UAC enabled.  Just look at the small list of files given the special treatment (http://www.withinwindows.com/2009/05/02/short-windows-7-release-candidate-auto-elevate-white-list/) – all of them are management-related utilities.  On the other hand, I definitely understand the pain other developers are going through in order to rework their applications to be UAC compliant.  The bottom line is that providing a mechanism to auto-elevate 3rd party applications would ultimately result in people abusing it.  In this case I think the exception is for the greater good.

  13. jon says:

    @John: "On the other hand, I definitely understand the pain other developers are going through in order to rework their applications to be UAC compliant."

    In our own particular case, the pain comes from already having done the work (long ago) to be fully UAC compliant, and still being done over by the changes in Windows 7. We did the right thing, but because Microsoft can’t be bothered doing it themselves, they give themselves a free pass.

  14. Stefan Kanthak says:

    There are indeed (and since LOOONG time) several settings which allow only "administrator approved" code to run:

    1. see MSKB 182569 and %windir%INFINETRES.ADM:

        [HKLMSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones*]

        "1200"=dword:010000

        "2000"=dword:010000

    2. see MSKB 216384:

        [HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer]

        "EnforceShellExtensionSecurity"=dword:01

    3. see MSKB 555235 & 883256:

        [HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExt]

        "RestrictToList"=dword:01

        [HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExtCLSID]

        "{GUIDGUID-GUID-GUID-GUID-GUIDGUIDGUID}"="1"

    4. see MSKB 267930.

  15. John says:

    jon: What changed with regard to UAC from Vista to 7?  I haven’t kept up with Windows 7 yet.

  16. jon says:

    @John: Basically, because Microsoft got scared by the complaints of too many UAC prompts in Vista, Microsoft software no longer needs to show a UAC prompt to elevate under the default configuration.

    Third party software doesn’t have this privilege and still must show a prompt to elevate. Therefore third party file software (e.g. file managers) are disadvantaged compared to the Microsoft software (e.g. Explorer).

    There are several security implications as well which have been well covered; e.g. see http://www.pretentiousname.com/misc/win7_uac_whitelist2.html for lots of detail.

  17. jon says:

    @Marquess: You’re completely wrong, sorry. For example, Explorer runs quite happily without admin privileges. You’re doing it right now.

    I agree that the UAC selector shouldn’t be at a lower setting – but unfortunately, that’s the default setting that Microsoft has imposed on people.

  18. A regular viewer says:

    I don’t see why Microsoft cannot understand a very simple request. All these blog posts and comments and more that 95% of all tech articles every written and will continue to be written, point out to that basic inability of Microsoft to comprehend a simple statement made by millions of developers and users for over 25 years. It is shameful and damning.

    "I goof up. You pay."

  19. ender says:

    @Frank: do those Tucows/Comodo certificates allow driver (kernel mode) signing?

  20. Joe says:

    How about ‘approved debuggers’ being a list  that can only be added to by Administrators via UAC?

    [I covered this in the article. “Then what’s to stop a rogue program from just auto-approving itself by writing to the Approved Debuggers registry key on its own?” You run the Application X installer. The installer asks for elevation. You grant it. It adds itself as an ‘approved debugger’ even though it’s really just a music player. -Raymond]
  21. Marquess says:

    The whitelisted programs are all applications that *cannot be run without admin privileges*. Microsoft trusts these programs (as they should, having developed them). However, MS has no reason to trust other application, and as readers of this blog should know, if you give people an easy way out, they *will* abuse it.

    Now, about the code injection: Don’t run Windows as admin and with the UAC selector at a lower setting. You’re just asking for trouble. Exploits that require admin privileges are *not* exploits.

  22. Frank says:

    To ender: yes, the Tucows/Comodo certificates allow driver signing.

  23. Ricardo Costa says:

    I believe the concern here is about keyloggers and code injection. What if the program could use an API to disable debugging on itself? Or, at least, protect regions of memory from being read/written by other user-level processes. Debuggers wouldn’t be able to fully debug the process but it would be more beneficial than harmful.

    [All I have to do to defeat you is to launch you suspended, connect as a debugger, and then when you call the imaginary PreventDebuggingThisProcess function, trick you into thinking the call succeeded. -Raymond]
  24. Aram Hăvărneanu says:

    To posts regarding UAC:

    I think Mark Russinovich summarized it just right in his PDC talk. (Free to watch on the web). UAC has nothing to do with security. UAC has nothing to do in regard to regular users. UAC is only for developers that can use it to make sure the software they are developing can run without Admin priviledges. If their software does not trigger UAC prompts, then the software can be run by a regular user, which in turn will not see any suspicious prompts. UAC is a developer tool, not a security tool.

  25. Cheong says:

    [All I have to do to defeat you is to launch you suspended, connect as a debugger, and then when you call the imaginary PreventDebuggingThisProcess  function, trick you into thinking the call succeeded. -Raymond]

    Or rather, invent some compiler directive that after compilation, generates some kind of .securetext and .securedata section (kind of like .data section that disallows execution in NX context) that disallow debuggers to step in. (When you use VS to debug, of course the generated debug assembly should run in normal .text/.data sections only so you can debug these codes/data.)

    [I guess you could do that, but it means that users don’t have full access to their own processes. This looks like a solution in search of a problem. -Raymond]
  26. Mike Dimmick says:

    On the discussion of the change between Vista and 7 UAC: Windows Vista already distinguished between various different forms of signed code for the presentation of UAC confirmation dialogs. Windows code (i.e. signed with the Windows publisher certificate) gets a different colour banner and slightly different wording, in elevation and over-the-shoulder prompts. The four levels are:

    1. Windows executables (blue, IIRC – writing this on XP)

    2. Other signed executables (grey)

    3. Unsigned executables from unknown locations (yellow, task buttons rather than regular buttons)

    4. Unsigned executables with mark of the Web (red with ‘X’ shield icon, strongly discouraged from running)

    Windows 7 allows you to select a threshold below which the prompts will not show. The default is to not show prompts for level 1, Windows-supplied applications, but you can turn it up to show prompts for those as well, or down, to not show prompts for all signed applications. This is different from Windows Vista’s all-or-nothing approach.

    As a quick reminder for everyone, the prompts occur when you start a new process via ShellExecuteEx. (CreateProcess inherits the parent security state as it should not be interactive.) For regular EXEs, a prompt is generated if there is a manifest, and it specifies requireAdministrator or, if the user is an admin, highestAvailable. Or, if it has been marked as requiring administrator rights in the shim database or on the shortcut. If there is no manifest, it may still invoke a prompt if the executable matches certain heuristics intended to detect legacy setup programs.

    Once an elevated application is running, the *way* it was elevated has no significance. They all get the same elevated token. Windows components don’t get any extra special privileges over other software, whether signed or unsigned.

    Microsoft have been careful to distinguish updates to Windows – normally packaged as .msu files anyway, to appear in the Turn On/Off Windows Features dialog – from other Microsoft-supplied software. Even Windows Live Essentials is signed as Microsoft, not as Windows.

  27. Marquess says:

    Ok, I finally got around to testing that injection tool. Pressed inject, got UAC prompt, was unimpressed.

    Tested on Windows Server 2008 R2, limited user. *yawn*

  28. Me says:

    @Marquess

    "Tested on Windows Server 2008 R2, _limited user_. *yawn*"

    You’re deliberately missing the point.

    The Window 7 (and W2K8R2? who knows) default UAC model is broken because it can be silently bypassed. Bypassing UAC is not the same as privilege escalation.

    "The whitelisted programs are all applications that *cannot be run without admin privileges*."

    Calc.exe? Notepad? Maybe it’s not so deliberate.

    FWIW I think Aram (and Mark) got it right.

  29. MarkKB says:

    "The Window 7 (and W2K8R2? who knows) default UAC model is broken because it can be silently bypassed. Bypassing UAC is not the same as privilege escalation."

    Not true with a limited user account. It would show a UAC prompt, just like Vista.

    Obviously, the solution is to make the limited user account the default, and to educate the user as to what the admin account is for (administration). However, I’m not quite sure of an easy way to do this.

  30. 640k says:

    Vista did it right. w7 is back to "perceived security" only with some lesser nagging than vista – worst of 2 worlds.

  31. Random832 says:

    “Then what’s to stop a rogue program from just auto-approving itself by writing to the Approved Debuggers registry key on its own?”

    I think the idea is that administrators take some responsibility for the programs they install. But, since you asked, what about an “Approved Registry Editors” key? [which to begin with only includes Regedit and maybe some hypothetical control panel for adding programs to approved lists [both of which will in the initial configuration only write to keys requiring it in interactive mode]]

    [The underlying problem is still there. In order to install (almost) any program, you have to grant its installer “Approved Registry Editors” status so it can update the registry as part of its installation, at which point you implicitly gave it permission to add the program to the “Approved Registry Editors” key. -Raymond]
  32. Stefan Kanthak says:

    [The underlying problem is still there. In order to install (almost) any program, you have to grant its installer "Approved Registry Editors" status so it can update the registry as part of its installation, at which point you implicitly gave it permission to add the program to the "Approved Registry Editors" key. -Raymond]

    Cf. Ken Thompson famous article "Reflections on Trusting Trust" <http://cm.bell-labs.com/who/ken/trust.html&gt;

Comments are closed.

Skip to main content