ruas in the same console
in [Win32 API]
|
From: Jonathan de Boyne Pollard on 12 Jan 2010 13:45 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <blockquote cite="mid:%23GzDhAtkKHA.5820(a)TK2MSFTNGP06.phx.gbl" type="cite"> <blockquote type="cite"> <p>is it posible to run <code>runas</code> command <em>without</em> having started the new cmd instance, i mean, in the same console window, inheriting previous cmd history and env vars? something like <code>su</code> command in unix/linux </p> </blockquote> <p>Nope. Windows can only run under a single user context at a time. The shell itself doesn't understand user contexts, only the window manager. </p> </blockquote> <p>All three sentences there are wrong. Let's start with "Nope.". It is possible. In theory a utility could be written to obtain the necessary process token and invoke a new child process, inheriting the utility program's environment and console, using that token. And in practice, <a href="http://mkssoftware.com./docs/man1/su.1.asp">MKS seems to have written exactly such a utility</a>.<br> </p> <p>Windows most definitely <em>can</em> run under multiple user contexts at the same time. That is, after all, what enables Fast User Switching, for starters. This isn't just an attribute of FUS, though. The ability to have multiple processes associated with multiple users has been in Windows NT ab initio, and it has been used ab initio, too. Multiple processes with multiple user accounts is part of what prevents, say, an unprivileged account mucking around with the internals of the LSA server process.<br> </p> <p>The "Window manager" (which for the sake of exposition I'll assume is a vague reference to a combination of the CSRSS process, the WIN32K driver, and the DWM) really isn't involved in multiple user contexts. The "Window manager" actually deals in <em>desktops</em>, <em>window stations</em>, and <em>sessions</em>. The relationship between each of all three of those and user accounts is not necessarily one-to-one. Desktops can have multiple processes with multiple user accounts accessing them. That is what shatter attacks are all about. Window stations can have multiple processes with multiple user accounts. Fast User Switching switches a single window station amongest multiple users, after all. <a href="http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/windows-nt-session.html">And sessions are <em>not</em> login sessions</a>.<br> </p> </body> </html>
From: David Trimboli on 19 Jan 2010 09:12 On 1/12/2010 1:45 PM, Jonathan de Boyne Pollard wrote: >> >>> >>> is it posible to run |runas| command /without/ having started the new >>> cmd instance, i mean, in the same console window, inheriting previous >>> cmd history and env vars? something like |su| command in unix/linux >>> >> Nope. Windows can only run under a single user context at a time. The >> shell itself doesn't understand user contexts, only the window manager. >> > All three sentences there are wrong. Let's start with "Nope.". It is > possible. In theory a utility could be written to obtain the necessary > process token and invoke a new child process, inheriting the utility > program's environment and console, using that token. And in practice, > MKS seems to have written exactly such a utility > <http://mkssoftware.com./docs/man1/su.1.asp>. Yes, if you write a custom shell that uses a console-style window, you could write it to include access to multiple user contexts. But the original question asked about instances of cmd, not other shells. > Windows most definitely /can/ run under multiple user contexts at the > same time. That is, after all, what enables Fast User Switching, for > starters. Nonono, if that word hadn't been the first word of a sentence, it would have been lowercase. Not "Windows operating system," but "instance of a window on the screen." > The "Window manager" (which for the sake of exposition I'll assume is a > vague reference to a combination of the CSRSS process, the WIN32K > driver, and the DWM) really isn't involved in multiple user contexts. Let me rephrase. "The CMD shell doesn't deal with user contexts, so the window in which it runs is always assumed to be of a single context." The original poster wanted to know if you could force an instance of CMD to jump to a different user context, or a different instance of CMD under a different user context, in the same window. You can't. -- David Trimboli Windows Systems Analyst Cold Spring Harbor Laboratory
From: Michael Wojcik on 21 Jan 2010 13:12 David Trimboli wrote: > On 1/12/2010 1:45 PM, Jonathan de Boyne Pollard wrote: >>> >>>> is it posible to run |runas| command /without/ having started the new >>>> cmd instance, i mean, in the same console window, inheriting previous >>>> cmd history and env vars? something like |su| command in unix/linux That's not what the su command does, so the question as presented isn't meaningful. su exec's a new process. By default that's a shell process, and it's a child of su, which is a child of the shell in which the user ran su, so it inherits (most) of that shell's environment. It only inherits the parent shell's command history if the shell makes provisions for that - typically by keeping the command history in a file associated with the tty name, so the new child shell can find it. >>> Nope. Windows can only run under a single user context at a time. The >>> shell itself doesn't understand user contexts, only the window manager. Taking "Windows" above to be "cmd.exe console windows", that second sentence is true, though it's a property of cmd.exe and has nothing to do with the window itself (so introducing the term isn't particularly useful). But certainly many processes other than "the window manager" (whatever that's supposed to refer to) are written to deal with multiple tokens, so the second sentence is inaccurate and misleading, if not outright wrong. >> All three sentences there are wrong. Let's start with "Nope.". It is >> possible. In theory a utility could be written to obtain the necessary >> process token and invoke a new child process, inheriting the utility >> program's environment and console, using that token. And in practice, >> MKS seems to have written exactly such a utility >> <http://mkssoftware.com./docs/man1/su.1.asp>. It's just a matter of parameters to CreateProcessAsUser: set lpEnvironment to null to inherit the caller's environment, and set dwCreationFlags to 0 to inherit the caller's console. Use LogonUser first to get the primary token based on username and password, and then CreateProcessAsUser to create a new cmd.exe in the same console window. However, neither the MKS su nor any other such program would change the token of the current cmd.exe. They all start a new shell process. The environment can, of course, be inherited by setting the lpEnvironment parameter to null (though Unix su typically builds a new environment, removing "unsafe" environment settings such as dynamic-linker options). Since cmd.exe keeps its history in process private memory, though, there's no way for the child cmd.exe to inherit that. > Yes, if you write a custom shell that uses a console-style window, you > could write it to include access to multiple user contexts. But the > original question asked about instances of cmd, not other shells. There's nothing special about cmd.exe in this regard. It works just as any of the shells shipped with MKS do. >> Windows most definitely /can/ run under multiple user contexts at the >> same time. That is, after all, what enables Fast User Switching, for >> starters. > > Nonono, if that word hadn't been the first word of a sentence, it would > have been lowercase. Not "Windows operating system," but "instance of a > window on the screen." Nothing prevents a process with a visible window from switching tokens, if it's written to do so. cmd.exe isn't, but that has nothing to do with the fact that it owns a window on the desktop. > Let me rephrase. "The CMD shell doesn't deal with user contexts, so the > window in which it runs is always assumed to be of a single context." Again, nothing to do with windows. It's a question of the security token under which each thread in the process is running. cmd.exe always uses the token with which it was created, but that's only because it wasn't written to do something different. > The original poster wanted to know if you could force an instance of CMD > to jump to a different user context, or a different instance of CMD > under a different user context, in the same window. You can't. I'm not so sure about that, either. I haven't tried it, but with sufficient permissions I believe this ought to work: - Get process ID of a cmd.exe process (trivial if the current process is a child of that cmd.exe process) - Create primary token with LogonUser - Use DuplicateHandle to dup the token into the cmd.exe process - Use any suitable code injection technique to get cmd.exe to call ImpersonateLoggedOnUser(new-token) in its main thread For the injection, I'd probably use WriteProcessMemory to build a function A in cmd.exe that located the return address on the top of the main thread's stack, saved it, and changed it to point to a new block of code B (standard return-smashing technique). Block B would make the ImpersonateLoggedOnUser call and then jump to the saved old return address, letting the main thread continue with its business. Then invoke the function A using CreateRemoteThread. Of course, I haven't looked at how cmd.exe works. It may not create new processes from its main thread, or do something else that'd prevent that token from being inherited by new processes. Hmm... come to think of it, CreateProcess uses the process token, not the calling thread's impersonation token, doesn't it. So more radical violence to the running cmd.exe process would likely be necessary, or processes started by cmd.exe wouldn't run in the new security context. (Builtin commands and operations, such as opening files for redirection, should.) One possibility would be to suspend the main thread and have the injected code take over all cmd.exe processing, but substituting CreateProcessAsUser for CreateProcess; this would require knowing enough about cmd.exe's internals that it's not really worth doing (simpler to create a patched cmd.exe). At any rate, though, the point is it's not safe to simply declare that it's impossible to change the security context of a process. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: Tim Meddick on 21 Jan 2010 17:02 Michael, I find your comments to be overly critical and generally unhelpful. I believe that, in these groups, one should endeavour to tailor the answers to the general level of detail that was in the Original Poster's question. In that, you have totally over-complicated your answer to the extent that I think the OP will have not the slightest clue of what you are on about. We give advice according to the level of knowledge we possess and, with reference to this, it is obvious that David Trimboli knows what he is talking about. It is of little interest to the rest of us to witness an argument on obscure detail that becomes ever more in-depth until the relevance to anything useful becomes lost. In short, I think that you have lost the benefit of overview that could have made your contribution of any value to the most important person here - the one who asks for help in the first place. == Cheers, Tim Meddick, Peckham, London. :-) "Michael Wojcik" <mwojcik(a)newsguy.com> wrote in message news:hjac6301tm1(a)news4.newsguy.com... > > < clipped > > > That's not what the su command does, so the question as presented > isn't meaningful. su exec's a new process. By default that's a shell > process, and it's a child of su, which is a child of the shell in > which the user ran su, so it inherits (most) of that shell's environment. > > It only inherits the parent shell's command history if the shell makes > provisions for that - typically by keeping the command history in a > file associated with the tty name, so the new child shell can find it......... > > > < clipped > >
From: sali on 22 Jan 2010 03:41
"Tim Meddick" <timmeddick(a)gawab.com> je napisao u poruci interesnoj grupi:%239C9PYumKHA.4936(a)TK2MSFTNGP04.phx.gbl... > I believe that, in these groups, one should endeavour to tailor the > answers to the general level of detail that was in the Original Poster's > question. there are allways 'short' and 'long' answers. 'short' consisting of 'yes' or 'no', and 'long' ones with background explanations regarding the original question: "am i missing something to be able to run 'runas' in the same console inside 'cmd.exe'", it seems that it isn't possible [there are no hidden undocumented trick, or registry tweaking], but all infos presented here, i find usefull although i had not reposted for weeks, i monitor the thread |