How To Get a Privileged Command Window with WinDbg
davyb
session. I can attach to any privileged process, but the command
window that persists from ".shell -x cmd" only has my normal
privileges. Being able to do this would greatly simplify my
development work without having to grant me access to the administrator
account or grant my account full administrator privileges (just debug
privilege).
This ability is alluded to in various commentaries on the debug
privilege, but I haven't found an explicit description. Somehow, by
attaching to an existing privileged process, WinDbg can do the deed.
How?
DavyB
![Pavel Lebedinsky [MSFT]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Pavel Lebedinsky [MSFT]
will always run the specified command using the debugger's token.
One workaround is to start the privileged process itself under
debugger, using the Image File Execution Options key. In this
case debugger will run under the same identity as the process,
so .shell will use the same identity as well.
If the process is already running and you can't use IFEO you could
use .call to invoke CreateProcess (or some simple wrapper like
msvcrt!system) from the target process. The problem with this is
that .call requires full symbols, and for system dlls only public
symbols are available on the symbol server. You could however
create your own equivalent of system() and call that. Or you
could manually emulate what .call does.
In theory this looks simple, at least on x86. In practice there are
lots of things that could go wrong. After some experiments, I was
able to attach to msdtc.exe (as an example) then successfully
invoke system() to get a remote.exe session running as
NetworkService but it required some really ugly stuff.
If you just need a cmd prompt running as some service account
then there are easier ways of doing this. For example, you can
hijack the IFEO Debugger value for an existing service that uses
this account. Here's how to get cmd running as NetworkService
(use at your own risk, etc. etc), assuming you have debuggers
installed in c:\debuggers:
1. First set this reg value:
===
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File
Execution Options\msdtc.exe]
"Debugger"="cmd.exe /c start c:\\debuggers\\remote.exe /s cmd.exe
cmd_as_network_service"
===
2. Then do this:
C:\Debuggers>net stop msdtc
C:\Debuggers>net start msdtc
C:\Debuggers>remote /c . cmd_as_network_service
3. Remove the value created in step 1.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Chris Doré
.shell -x runas /user:your_domain\your_account cmd
runas will prompt you for a password since there is no way to enter it as a
command-line option.
For example, if your machine is M1 and you want to run cmd as admin:
.shell -x runas /user:M1\administrator cmd
...Chris
"davyb" <david....@gmail.com> wrote in message
news:1122809435.0...@g49g2000cwa.googlegroups.com...
davyb
get money". How can an unprivileged user stop/start services?
(I tried attaching to the virus scanner, but this seemed to hang
even with noninvasive attachment. And adding the image file
execution options for mcshield.exe in the registry was messy
and required privileged access and didn't seem to work, even for
the adminstrator account.)
The idea is to be able to do all development related tasks
with only debug privilege by "impersonating" system via a
windbg spawned command window that is running in system
context. Logging in as administrator can be done more
easily via "runas" than from WinDbg. no?
This is topic is probably more appropriate for a developer
group dealing with security and the minimal privilege
principle since there doesn't seem to a simple solution
via WinDbg. However, I'm still hopeful that someone
can show how to turn the rumor of the enormous power of
the debug privilege into a simple, elegant way to
impersonate a fully privileged member of the administrator
group.
Thanks, again!
DavyB
Pavel Lebedinsky [MSFT]
> The idea is to be able to do all development related tasks with only debug
> privilege by "impersonating" system via a windbg spawned command window
> that is running in system context. Logging in as administrator can be
> done more easily via "runas" than from WinDbg. no?
Yes, but runas doesn't work for NetworkService for example.
My assumption was that you were trying to get an interactive
cmd running as some service account (which can often be useful
during debugging) but now I see that it was not the case.
> However, I'm still hopeful that someone can show how to turn the rumor of
> the enormous power of the debug privilege into a simple, elegant way to
> impersonate a fully privileged member of the administrator group.
There isn't an elegant way to do this. It's possible but requires some
hacking.
On the other hand, if you are going to give your developers
SeDebugPrivilege, you might as well give them local administrator rights.
Skywing
It allows you to bypass access checks for NtOpenProcess/NtOpenThread and get
any access you want. This is regardless of the process or thread security
descriptor.
Now, the thing is you could do something like call OpenProcess on a
privileged process (e.g. csrss) and create a thread in it, or open a thread
and modify its context, or write to the process address space to poke in
some code to run, etc. Because of SeDebugPrivilege, you don't have to pass
the DACL to actually get such rights the handle. This is why
SeDebugPrivilege basically allows you to gain complete control over the
system.
"Dave Boyd" <david....@gmail.com> wrote in message
news:ObXOFmBm...@TK2MSFTNGP10.phx.gbl...
> Thanks for the replies. It looks to me like "you need money to get
> money". How can an unprivileged user stop/start services? (I tried
> attaching to the virus scanner, but this seemed to hang even with
> noninvasive attachment. And adding the image file execution options for
> mcshield.exe in the registry was messy and required privileged access and
> didn't seem to work, even for the adminstrator account.)
>
> The idea is to be able to do all development related tasks with only debug
> privilege by "impersonating" system via a windbg spawned command window
> that is running in system context. Logging in as administrator can be
> done more easily via "runas" than from WinDbg. no?
>
> This is topic is probably more appropriate for a developer group dealing
> with security and the minimal privilege principle since there doesn't seem
> to a simple solution via WinDbg. However, I'm still hopeful that someone
> can show how to turn the rumor of the enormous power of the debug
> privilege into a simple, elegant way to impersonate a fully privileged
> member of the administrator group.
>
> Thanks, again!
>
> DavyB
>
> "davyb" <david....@gmail.com> wrote in message
> news:1122809435.0...@g49g2000cwa.googlegroups.com...
davyb
rights very closely. The developer faction can scream that VS won't
work without debugger rights. All I know, as a fairly new developer,
is that the debugger right doesn't directly allow me to register an
assembly in the global assembly cache. In theory, as Skywing says,
(and as you say "with some hacking") it can be done. In fact, I was
hoping that a clever hacker could show me some simple magic. Maybe MS
should fix it once and for all. There is a VSDEVELOPER group, but it
doesn't seem do all that is needed (and also seems to have disappeared
with VS 2005--or am I wrong?).
Chris Doré
> Yes, but political reality is that the IT faction holds administrator
> rights very closely. The developer faction can scream that VS won't
> work without debugger rights. All I know, as a fairly new developer,
> is that the debugger right doesn't directly allow me to register an
> assembly in the global assembly cache.
You could always get yourself another machine of which you have complete
control over; then use the remote debugging tools. If you don't want to use
the remote debugging tools, then get your code development tools moved to
the new machine as well.
Running development code on your primary machine can be dangerous anyways.
...Chris
Pavel Lebedinsky [MSFT]
use Visual Studio. It allows you to open any process or thread
for full access. As a side effect it also allows you to gain
administrator rights by controlling a privileged process but that's
not its intended usage.
You have two options. You can try to tweak permissions on
the GAC, HKCR etc. so that all Visual Studio features
that you need are working. I don't know how much work it will
require but it should be doable. Note that by doing this you
effectively allow developers to become admins if they really
want to.
Another option is to have developers log on using their limited
domain accounts, but allow them to use the local Administrator
account as well. You can then use group policy to restrict
membership in the local Administrators group (so that they can't
permanently add themselves to local admins). This way developers
will be able to use MakeMeAdmin.cmd (google for it) or just
plain runas.exe to launch Visual Studio with administrator rights:
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToDevelopCodeAsANonAdmin.html
I don't know if your IT department will like this idea, but it might
be a reasonable compromise. At least this way your devs will not
be reading email and browsing internet as admins.
FWIW, this is also the configuration that I use at work (although
I don't do a lot of COM or .NET related stuff so for me Visual
Studio works just fine even without admin rights).
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
davyb
great! Sorry this is all somewhat off-topic, but it is related to
security and what doorway SeDebugPrivilege provides. Setting GAC
access is interesting since it is read-only and doesn't seem to have
overt ACL controls. I'm happy to leave that access problem to gacutil!
However, where is a clear discussion of privilege, ACL and process
interactions to be found?? WinDbg seems to trump these concerns by
going around them and WinDbg experts know the ins-and-outs by doing it.
By the way I ordered and just received the book by the author of the
article you reference (maybe the answer to my question is in this book
-- I haven't had time to read it yet.) And here's a similar reference
to the minimal privilege problem
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/tchDevelopingSoftwareInVisualStudioNETWithNon-AdministrativePrivileges.asp)
for those who stumble on this thread. Runas is everywhere, but
finding it is frequently magic unless you have this guide.
Cheers!
Pavel Lebedinsky [MSFT]
> great! Sorry this is all somewhat off-topic, but it is related to
> security and what doorway SeDebugPrivilege provides. Setting GAC
> access is interesting since it is read-only and doesn't seem to have
> overt ACL controls.
At least on current versions of Windows, GAC is still just a collection
of files under %WINDIR%\assembly\GAC (it has a shell extension that
prevents you from seeing the actual files in explorer, but you can navigate
there using cmd.exe). I haven't tried it but you should be able to change
permissions on this directory with cacls.exe or a similar tool. The
downside of course is that this opens up a permanent security
hole so I don't think this is any safer than simply running VS as
administrator.
> However, where is a clear discussion of privilege, ACL and process
> interactions to be found?? WinDbg seems to trump these concerns by
> going around them and WinDbg experts know the ins-and-outs by doing it.
>
>
> By the way I ordered and just received the book by the author of the
> article you reference (maybe the answer to my question is in this book
> -- I haven't had time to read it yet.)
Programming Windows Security is a great book. I haven't read Keith's
latest .NET book but I'm sure it's good as well.
Pavel A.
Open Local security policy -> User rights assignment -> Debug programs.
Whom do you see there? (besides of administrators)
--PA
davyb
Yeah, this isn't an issue for me...I have three machines on my desktop
and a non-development machine is my "primary" (email, office apps,
etc). IT / Security has even closer control over the other two
machines, one of which I develop on.
Microsoft needs to fix the lazy separation of IT/security concerns
(passwords -- i.e. authentication and intrusion dectection -- i.e. the
security log) and development concerns (access to GAC, registry areas
and developer related rights such as SeDebugPrivilege) lumped under the
generic group administrators and the generic account administrator.
(By the way, if I do this manually, isn't there still some built in
significance to the administrator account? -- ie suppose I delete all
generic groups and accounts and put in unique replacements and change
all ACLs (see Pavel's remarks "...tweak permissions...")--doesn't the
adminstrator account still survive like a zombie somewhere in bowels of
the OS? Certainly there are some unique privileges allocated to user
SYSTEM, no?)
Dave
Skywing
purpose development -- only if you're writing something like a service, or
something else that has a larger scope than the current user. Such things
by definition are privileged and require special privileges to debug or
modify.
"davyb" <david....@gmail.com> wrote in message
news:1124363614.9...@g43g2000cwa.googlegroups.com...
davyb
you give a developer membership in the generic administrators group,
for example, all these unnecessary privileges come along -- access to
the security log, etc. Non-lazy separation of concerns would have a
role based model -not just you're administrator or not. I guess
VSDevelopers group is an attempt at this, but the overlap of
authentication (password control) and powerful privileges like debugger
rights cause this attempted separation of concerns to break (the only
way to protect things in the admin/security role can be broken by the
developer role).
Dave
Skywing
need administrator privileges to build, test, and debug programs. For
instance, if I'm writing a text editor, I can write it and debug it without
having any special privileges (indeed as a regular user).
However, system level programs need administrator-like privileges to be
debugged.
I don't see how you could possibly do this some other way. The problem is
that for things that run as SYSTEM, or drivers, simply by virtue of being
able to attach to and manipulate those in a debugger would allow you to take
complete control over the system. There isn't a "safe" way to manipulate
such things with something like a debugger that wouldn't allow you to take
control over the system. Maybe you could do this with managed code and a
managed debugger that doesn't have direct control over the actual hardware
state, but not with real machine code on x86.
Given this problem I think it's reasonable to just say that you need
administrator-like access to be able to debug such things.
"davyb" <david....@gmail.com> wrote in message
news:1124449388.3...@f14g2000cwb.googlegroups.com...