From: Jonathan de Boyne Pollard on
<!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.&nbsp; Let's start with "Nope.".&nbsp; It
is possible.&nbsp; 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.&nbsp; 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.&nbsp; That is, after all, what enables Fast User
Switching, for starters.&nbsp; This isn't just an attribute of FUS, though.&nbsp;
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.&nbsp;
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.&nbsp; The "Window manager" actually deals in <em>desktops</em>, <em>window
stations</em>, and <em>sessions</em>.&nbsp; The relationship between each
of all three of those and user accounts is not necessarily one-to-one.&nbsp;
Desktops can have multiple processes with multiple user accounts
accessing them.&nbsp; That is what shatter attacks are all about.&nbsp; Window
stations can have multiple processes with multiple user accounts.&nbsp; Fast
User Switching switches a single window station amongest multiple
users,
after all.&nbsp; <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
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
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
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
"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