Does anybody know a way to impresonate a process which is running under the SYSTEM account to an other account for which the process doesn't know the password ?
(Sorry if it's not the right place to ask my question. If not, please tell me where I can do it :-)
> Does anybody know a way to impresonate a process which is running under > the SYSTEM account to an other account for which the process doesn't > know the password ?
> (Sorry if it's not the right place to ask my question. If not, please > tell me where I can do it :-)
Do you have a piece of code runing as LocalSystem, and this piece of code happens to have the server side of a named-pipe or LPC-port ? If yes, then you can call ImpersonateNamedPipeClient / NtImpersonateClientOfPort.
If you have an RPC / DCOM server, you can call RpcImpersonateClient/CoImpersonateClient.
If your client is wishing to partecipate to an authentication protocol, then you can use SSPI and get the client token via ImpersonateSecurityContext.
If you have code running as LocalSystem, you can always use NtCreateToken to generate a token for a given user, but that token will belong to practically no logon session, and it would not be much useful in real world.
What are you trying to accomplish ?
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Yoshiki" <yosh...@wanaROOdooDOO.fr> wrote in message
> Does anybody know a way to impresonate a process which is running under > the SYSTEM account to an other account for which the process doesn't > know the password ?
> (Sorry if it's not the right place to ask my question. If not, please > tell me where I can do it :-)
> Does anybody know a way to impresonate a process which is running under > the SYSTEM account to an other account for which the process doesn't > know the password ?
This is *not* possible, if it were, windows-hell broke... the idea of having passwords on a system would be voided.
This is an interesting answer, how would one then write a compliant RSH daemon on Windows without first knowing the password of every possible user who could run a rsh command against it? Remember that rsh its requests in a specific format and a password is not part of this data stream.
Just a thought...
-- Garfield A. Lewis DB2 UDB Development, IBM Canada Laboratory
> > Does anybody know a way to impresonate a process which is running under > > the SYSTEM account to an other account for which the process doesn't > > know the password ?
> This is *not* possible, if it were, windows-hell broke... the idea of having > passwords on a system would be voided.
> > (Sorry if it's not the right place to ask my question. If not, please > > tell me where I can do it :-)
You can write RSH if you have a "daemon" process with the SeCreatePrimaryToken privilege, but the created token would belong to the system logon session, and the token would have no chance to do much apart from the local machine.
The phylosophically correct approach would be to use SSPI to correclty create the identity of the remote account in the local machine. There would be no password transmission. The API to look at would be InitialzieSecurityContext on the client-side, followed by a chain of AcceptSecurityContext on the server side. When the negotiation has happened, the Server would call ImpersonateSecurityContext. If the SSPI is going to use Kerberos as the authentication package, then you can even delegate the credentials of the remote user.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Garfield Lewis" <gale...@ca.ibm.com> wrote in message
> This is an interesting answer, how would one then write a compliant RSH > daemon on Windows without first knowing the password of every possible user > who could run a rsh command against it? Remember that rsh its requests in a > specific format and a password is not part of this data stream.
> Just a thought...
> -- > Garfield A. Lewis > DB2 UDB Development, > IBM Canada Laboratory
> > > Does anybody know a way to impresonate a process which is running under > > > the SYSTEM account to an other account for which the process doesn't > > > know the password ?
> > This is *not* possible, if it were, windows-hell broke... the idea of > having > > passwords on a system would be voided.
> > > (Sorry if it's not the right place to ask my question. If not, please > > > tell me where I can do it :-)
The goal of RSH is to execute the command in the context of the client so unless the client can be impersonated (local or remote) then you will be running under the contest of the local system or whatever account you use to login your rshd service ("daemon").
SSPI is all well and good in a Windows only environment (even though I doubt that the rsh.exe that is shipped with Windows is written using SSPI, in fact I am pretty sure of it). But the reality is most companies/customers run multiple platforms (AIX, Windows, Linux, ... and on and on). So how would a non-Windows client accomplish a rsh request?
It would be nice if one had the ability to su on Windows as on UNIX. So that if you are running in the context of the system (root) you can login as (or get the context of) a user without a password and have full control. Then a rshd could be written that does the job without needing a password for the client requestor.
-- Garfield A. Lewis DB2 UDB Development, IBM Canada Laboratory
> You can write RSH if you have a "daemon" process with the > SeCreatePrimaryToken privilege, > but the created token would belong to the system logon session, and the > token would have > no chance to do much apart from the local machine.
> The phylosophically correct approach would be to use SSPI > to correclty create the identity of the remote account in the local machine. > There would be no password transmission. > The API to look at would be InitialzieSecurityContext on the client-side, > followed by a chain of AcceptSecurityContext on the server side. > When the negotiation has happened, the Server would call > ImpersonateSecurityContext. > If the SSPI is going to use Kerberos as the authentication package, > then you can even delegate the credentials of the remote user.
> -- > This posting is provided "As Is" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm
> "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > This is an interesting answer, how would one then write a compliant RSH > > daemon on Windows without first knowing the password of every possible > user > > who could run a rsh command against it? Remember that rsh its requests in > a > > specific format and a password is not part of this data stream.
> > Just a thought...
> > -- > > Garfield A. Lewis > > DB2 UDB Development, > > IBM Canada Laboratory
> > > > Does anybody know a way to impresonate a process which is running > under > > > > the SYSTEM account to an other account for which the process doesn't > > > > know the password ?
> > > This is *not* possible, if it were, windows-hell broke... the idea of > > having > > > passwords on a system would be voided.
> > > > (Sorry if it's not the right place to ask my question. If not, please > > > > tell me where I can do it :-)
NtCreateToken offers you the "su" capabilities, with no Logon Session. You can create a primary token just starting from a SID.
the SAMBA folks are able to authenticate to a Windows IPS$ "share", it means that they have an SSPI "implementation", because srv.sys uses SSPI-server side to authenticate your network logon credentials.
the official "su" for windows is runas.exe, that, as you pointed out, requires passwords.
You can always create a "secure channel" a-la-SSL to just transmit the password on the other side, so that the "daemon" can do a CreateProcessWithLogon/CreateProcessAsUser.
I will not even go to the topic of discussing the security ramifications of 'su', and all the exploits based on the 'suid' bit.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Garfield Lewis" <gale...@ca.ibm.com> wrote in message
> The goal of RSH is to execute the command in the context of the client so > unless the client can be impersonated (local or remote) then you will be > running under the contest of the local system or whatever account you use to > login your rshd service ("daemon").
> SSPI is all well and good in a Windows only environment (even though I doubt > that the rsh.exe that is shipped with Windows is written using SSPI, in fact > I am pretty sure of it). But the reality is most companies/customers run > multiple platforms (AIX, Windows, Linux, ... and on and on). So how would a > non-Windows client accomplish a rsh request?
> It would be nice if one had the ability to su on Windows as on UNIX. So that > if you are running in the context of the system (root) you can login as (or > get the context of) a user without a password and have full control. Then a > rshd could be written that does the job without needing a password for the > client requestor.
> -- > Garfield A. Lewis > DB2 UDB Development, > IBM Canada Laboratory
> "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > news:ODIhPWjoCHA.2292@tkmsftngp02... > > You can write RSH if you have a "daemon" process with the > > SeCreatePrimaryToken privilege, > > but the created token would belong to the system logon session, and the > > token would have > > no chance to do much apart from the local machine.
> > The phylosophically correct approach would be to use SSPI > > to correclty create the identity of the remote account in the local > machine. > > There would be no password transmission. > > The API to look at would be InitialzieSecurityContext on the client-side, > > followed by a chain of AcceptSecurityContext on the server side. > > When the negotiation has happened, the Server would call > > ImpersonateSecurityContext. > > If the SSPI is going to use Kerberos as the authentication package, > > then you can even delegate the credentials of the remote user.
> > -- > > This posting is provided "As Is" with no warranties, and confers no > rights. > > Use of included script samples are subject to the terms specified at > > http://www.microsoft.com/info/cpyright.htm
> > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > This is an interesting answer, how would one then write a compliant RSH > > > daemon on Windows without first knowing the password of every possible > > user > > > who could run a rsh command against it? Remember that rsh its requests > in > > a > > > specific format and a password is not part of this data stream.
> > > Just a thought...
> > > -- > > > Garfield A. Lewis > > > DB2 UDB Development, > > > IBM Canada Laboratory
> > > > > Does anybody know a way to impresonate a process which is running > > under > > > > > the SYSTEM account to an other account for which the process doesn't > > > > > know the password ?
> > > > This is *not* possible, if it were, windows-hell broke... the idea of > > > having > > > > passwords on a system would be voided.
> > > > > (Sorry if it's not the right place to ask my question. If not, > please > > > > > tell me where I can do it :-)
Are there any examples of NtCreateToken I cannot find any reference to it on the MSDN website?
All I want to be able to do is write an rsh daemon (I do not want/wish to rewrite the client side rsh command) that will accept the command stream that is sent to it and do the work in the context of the client. That means I do not have write any special rsh command that will open secure channels and send passwords. The rsh daemon should accept the stream in the recognized rsh format which I think still is:
After recieving this the rsh daemon would send a null string to client to acknowledge recieving the request. It then runs the command under the context of the user and returns the result (success or failure). The question is how (without a password) would I be able to get the user's context? If NtCreateToken can do this then great but how?
-- Garfield A. Lewis DB2 UDB Development, IBM Canada Laboratory
> NtCreateToken offers you the "su" capabilities, with no Logon Session. > You can create a primary token just starting from a SID.
> the SAMBA folks are able to authenticate to a Windows IPS$ "share", > it means that they have an SSPI "implementation", > because srv.sys uses SSPI-server side to authenticate your network logon > credentials.
> the official "su" for windows is runas.exe, > that, as you pointed out, requires passwords.
> You can always create a "secure channel" a-la-SSL to just transmit the > password on the other side, > so that the "daemon" can do a CreateProcessWithLogon/CreateProcessAsUser.
> I will not even go to the topic of discussing the security ramifications of > 'su', > and all the exploits based on the 'suid' bit.
> -- > This posting is provided "As Is" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm
> "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > news:u1wrNmkoCHA.2084@TK2MSFTNGP12... > > The goal of RSH is to execute the command in the context of the client so > > unless the client can be impersonated (local or remote) then you will be > > running under the contest of the local system or whatever account you use > to > > login your rshd service ("daemon").
> > SSPI is all well and good in a Windows only environment (even though I > doubt > > that the rsh.exe that is shipped with Windows is written using SSPI, in > fact > > I am pretty sure of it). But the reality is most companies/customers run > > multiple platforms (AIX, Windows, Linux, ... and on and on). So how would > a > > non-Windows client accomplish a rsh request?
> > It would be nice if one had the ability to su on Windows as on UNIX. So > that > > if you are running in the context of the system (root) you can login as > (or > > get the context of) a user without a password and have full control. Then > a > > rshd could be written that does the job without needing a password for the > > client requestor.
> > -- > > Garfield A. Lewis > > DB2 UDB Development, > > IBM Canada Laboratory
> > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > > news:ODIhPWjoCHA.2292@tkmsftngp02... > > > You can write RSH if you have a "daemon" process with the > > > SeCreatePrimaryToken privilege, > > > but the created token would belong to the system logon session, and the > > > token would have > > > no chance to do much apart from the local machine.
> > > The phylosophically correct approach would be to use SSPI > > > to correclty create the identity of the remote account in the local > > machine. > > > There would be no password transmission. > > > The API to look at would be InitialzieSecurityContext on the > client-side, > > > followed by a chain of AcceptSecurityContext on the server side. > > > When the negotiation has happened, the Server would call > > > ImpersonateSecurityContext. > > > If the SSPI is going to use Kerberos as the authentication package, > > > then you can even delegate the credentials of the remote user.
> > > -- > > > This posting is provided "As Is" with no warranties, and confers no > > rights. > > > Use of included script samples are subject to the terms specified at > > > http://www.microsoft.com/info/cpyright.htm
> > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > > This is an interesting answer, how would one then write a compliant > RSH > > > > daemon on Windows without first knowing the password of every possible > > > user > > > > who could run a rsh command against it? Remember that rsh its requests > > in > > > a > > > > specific format and a password is not part of this data stream.
> > > > Just a thought...
> > > > -- > > > > Garfield A. Lewis > > > > DB2 UDB Development, > > > > IBM Canada Laboratory
> > > > > > Does anybody know a way to impresonate a process which is running > > > under > > > > > > the SYSTEM account to an other account for which the process > doesn't > > > > > > know the password ?
> > > > > This is *not* possible, if it were, windows-hell broke... the idea > of > > > > having > > > > > passwords on a system would be voided.
> > > > > > (Sorry if it's not the right place to ask my question. If not, > > please > > > > > > tell me where I can do it :-)
the book "Windows NT/2000 Native API Reference" has a sample of NtCreateToken. All others are published APIs. -- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Garfield Lewis" <gale...@ca.ibm.com> wrote in message
> Are there any examples of NtCreateToken I cannot find any reference to it on > the MSDN website?
> All I want to be able to do is write an rsh daemon (I do not want/wish to > rewrite the client side rsh command) that will accept the command stream > that is sent to it and do the work in the context of the client. That means > I do not have write any special rsh command that will open secure channels > and send passwords. The rsh daemon should accept the stream in the > recognized rsh format which I think still is:
> After recieving this the rsh daemon would send a null string to client to > acknowledge recieving the request. It then runs the command under the > context of the user and returns the result (success or failure). The > question is how (without a password) would I be able to get the user's > context? If NtCreateToken can do this then great but how?
> -- > Garfield A. Lewis > DB2 UDB Development, > IBM Canada Laboratory
> "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > news:u0I2J2koCHA.1532@tkmsftngp02... > > NtCreateToken offers you the "su" capabilities, with no Logon Session. > > You can create a primary token just starting from a SID.
> > the SAMBA folks are able to authenticate to a Windows IPS$ "share", > > it means that they have an SSPI "implementation", > > because srv.sys uses SSPI-server side to authenticate your network logon > > credentials.
> > the official "su" for windows is runas.exe, > > that, as you pointed out, requires passwords.
> > You can always create a "secure channel" a-la-SSL to just transmit the > > password on the other side, > > so that the "daemon" can do a
> > I will not even go to the topic of discussing the security ramifications > of > > 'su', > > and all the exploits based on the 'suid' bit.
> > -- > > This posting is provided "As Is" with no warranties, and confers no > rights. > > Use of included script samples are subject to the terms specified at > > http://www.microsoft.com/info/cpyright.htm
> > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > news:u1wrNmkoCHA.2084@TK2MSFTNGP12... > > > The goal of RSH is to execute the command in the context of the client > so > > > unless the client can be impersonated (local or remote) then you will be > > > running under the contest of the local system or whatever account you > use > > to > > > login your rshd service ("daemon").
> > > SSPI is all well and good in a Windows only environment (even though I > > doubt > > > that the rsh.exe that is shipped with Windows is written using SSPI, in > > fact > > > I am pretty sure of it). But the reality is most companies/customers run > > > multiple platforms (AIX, Windows, Linux, ... and on and on). So how > would > > a > > > non-Windows client accomplish a rsh request?
> > > It would be nice if one had the ability to su on Windows as on UNIX. So > > that > > > if you are running in the context of the system (root) you can login as > > (or > > > get the context of) a user without a password and have full control. > Then > > a > > > rshd could be written that does the job without needing a password for > the > > > client requestor.
> > > -- > > > Garfield A. Lewis > > > DB2 UDB Development, > > > IBM Canada Laboratory
> > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > > > news:ODIhPWjoCHA.2292@tkmsftngp02... > > > > You can write RSH if you have a "daemon" process with the > > > > SeCreatePrimaryToken privilege, > > > > but the created token would belong to the system logon session, and > the > > > > token would have > > > > no chance to do much apart from the local machine.
> > > > The phylosophically correct approach would be to use SSPI > > > > to correclty create the identity of the remote account in the local > > > machine. > > > > There would be no password transmission. > > > > The API to look at would be InitialzieSecurityContext on the > > client-side, > > > > followed by a chain of AcceptSecurityContext on the server side. > > > > When the negotiation has happened, the Server would call > > > > ImpersonateSecurityContext. > > > > If the SSPI is going to use Kerberos as the authentication package, > > > > then you can even delegate the credentials of the remote user.
> > > > -- > > > > This posting is provided "As Is" with no warranties, and confers no > > > rights. > > > > Use of included script samples are subject to the terms specified at > > > > http://www.microsoft.com/info/cpyright.htm
> > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > > > This is an interesting answer, how would one then write a compliant > > RSH > > > > > daemon on Windows without first knowing the password of every > possible > > > > user > > > > > who could run a rsh command against it? Remember that rsh its > requests > > > in > > > > a > > > > > specific format and a password is not part of this data stream.
> > > > > Just a thought...
> > > > > -- > > > > > Garfield A. Lewis > > > > > DB2 UDB Development, > > > > > IBM Canada Laboratory
> > > > > > > Does anybody know a way to impresonate a process which is > running > > > > under > > > > > > > the SYSTEM account to an other account for which the process > > doesn't > > > > > > > know the password ?
> > > > > > This is *not* possible, if it were, windows-hell broke... the idea > > of > > > > > having > > > > > > passwords on a system would be voided.
> > > > > > > (Sorry if it's not the right place to ask my question. If not, > > > please > > > > > > > tell me where I can do it :-)
If the intent of this code is to start notepad as the user whose name was obtained from the socket, then it should be using CreateProcessWithTokenW or CreateProcessAsUser.
Creating a process while impersonating is almost always a bug. It creates a process with the same token as the parent process, but the security descriptor for the new process is copied from the impersonated user's token. Which results in all kinds of interesting security problems when the new process tries to use its own handle (GetCurrentProcess()).
> the book "Windows NT/2000 Native API Reference" has a sample of > NtCreateToken. > All others are published APIs. > -- > This posting is provided "As Is" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm
> "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > news:uQXRUXuoCHA.1644@TK2MSFTNGP10... > > Are there any examples of NtCreateToken I cannot find any reference to it > on > > the MSDN website?
> > All I want to be able to do is write an rsh daemon (I do not want/wish to > > rewrite the client side rsh command) that will accept the command stream > > that is sent to it and do the work in the context of the client. That > means > > I do not have write any special rsh command that will open secure channels > > and send passwords. The rsh daemon should accept the stream in the > > recognized rsh format which I think still is:
> > After recieving this the rsh daemon would send a null string to client to > > acknowledge recieving the request. It then runs the command under the > > context of the user and returns the result (success or failure). The > > question is how (without a password) would I be able to get the user's > > context? If NtCreateToken can do this then great but how?
> > -- > > Garfield A. Lewis > > DB2 UDB Development, > > IBM Canada Laboratory
> > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > > news:u0I2J2koCHA.1532@tkmsftngp02... > > > NtCreateToken offers you the "su" capabilities, with no Logon Session. > > > You can create a primary token just starting from a SID.
> > > the SAMBA folks are able to authenticate to a Windows IPS$ "share", > > > it means that they have an SSPI "implementation", > > > because srv.sys uses SSPI-server side to authenticate your network logon > > > credentials.
> > > the official "su" for windows is runas.exe, > > > that, as you pointed out, requires passwords.
> > > You can always create a "secure channel" a-la-SSL to just transmit the > > > password on the other side, > > > so that the "daemon" can do a > CreateProcessWithLogon/CreateProcessAsUser.
> > > I will not even go to the topic of discussing the security ramifications > > of > > > 'su', > > > and all the exploits based on the 'suid' bit.
> > > -- > > > This posting is provided "As Is" with no warranties, and confers no > > rights. > > > Use of included script samples are subject to the terms specified at > > > http://www.microsoft.com/info/cpyright.htm
> > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > news:u1wrNmkoCHA.2084@TK2MSFTNGP12... > > > > The goal of RSH is to execute the command in the context of the client > > so > > > > unless the client can be impersonated (local or remote) then you will > be > > > > running under the contest of the local system or whatever account you > > use > > > to > > > > login your rshd service ("daemon").
> > > > SSPI is all well and good in a Windows only environment (even though I > > > doubt > > > > that the rsh.exe that is shipped with Windows is written using SSPI, > in > > > fact > > > > I am pretty sure of it). But the reality is most companies/customers > run > > > > multiple platforms (AIX, Windows, Linux, ... and on and on). So how > > would > > > a > > > > non-Windows client accomplish a rsh request?
> > > > It would be nice if one had the ability to su on Windows as on UNIX. > So > > > that > > > > if you are running in the context of the system (root) you can login > as > > > (or > > > > get the context of) a user without a password and have full control. > > Then > > > a > > > > rshd could be written that does the job without needing a password for > > the > > > > client requestor.
> > > > -- > > > > Garfield A. Lewis > > > > DB2 UDB Development, > > > > IBM Canada Laboratory
> > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in > message > > > > news:ODIhPWjoCHA.2292@tkmsftngp02... > > > > > You can write RSH if you have a "daemon" process with the > > > > > SeCreatePrimaryToken privilege, > > > > > but the created token would belong to the system logon session, and > > the > > > > > token would have > > > > > no chance to do much apart from the local machine.
> > > > > The phylosophically correct approach would be to use SSPI > > > > > to correclty create the identity of the remote account in the local > > > > machine. > > > > > There would be no password transmission. > > > > > The API to look at would be InitialzieSecurityContext on the > > > client-side, > > > > > followed by a chain of AcceptSecurityContext on the server side. > > > > > When the negotiation has happened, the Server would call > > > > > ImpersonateSecurityContext. > > > > > If the SSPI is going to use Kerberos as the authentication package, > > > > > then you can even delegate the credentials of the remote user.
> > > > > -- > > > > > This posting is provided "As Is" with no warranties, and confers no > > > > rights. > > > > > Use of included script samples are subject to the terms specified at > > > > > http://www.microsoft.com/info/cpyright.htm
> > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > > > > This is an interesting answer, how would one then write a > compliant > > > RSH > > > > > > daemon on Windows without first knowing the password of every > > possible > > > > > user > > > > > > who could run a rsh command against it? Remember that rsh its > > requests > > > > in > > > > > a > > > > > > specific format and a password is not part of this data stream.
> > > > > > > > Does anybody know a way to impresonate a process which is > > running > > > > > under > > > > > > > > the SYSTEM account to an other account for which the process > > > doesn't > > > > > > > > know the password ?
> > > > > > > This is *not* possible, if it were, windows-hell broke... the > idea > > > of > > > > > > having > > > > > > > passwords on a system would be voided.
> > > > > > > > (Sorry if it's not the right place to ask my question. If not, > > > > please > > > > > > > > tell me where I can do it :-)
Good remarks. The purpose of the conversation was about how to obtain the Token, and not about the ramifications of creating a process with a given token. Sorry about that.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
> If the intent of this code is to start notepad as the user > whose name was obtained from the socket, then it should > be using CreateProcessWithTokenW or CreateProcessAsUser.
> Creating a process while impersonating is almost always > a bug. It creates a process with the same token as the > parent process, but the security descriptor for the new process > is copied from the impersonated user's token. Which results > in all kinds of interesting security problems when the new > process tries to use its own handle (GetCurrentProcess()).
> > the book "Windows NT/2000 Native API Reference" has a sample of > > NtCreateToken. > > All others are published APIs. > > -- > > This posting is provided "As Is" with no warranties, and confers no > rights. > > Use of included script samples are subject to the terms specified at > > http://www.microsoft.com/info/cpyright.htm
> > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > news:uQXRUXuoCHA.1644@TK2MSFTNGP10... > > > Are there any examples of NtCreateToken I cannot find any reference to > it > > on > > > the MSDN website?
> > > All I want to be able to do is write an rsh daemon (I do not want/wish > to > > > rewrite the client side rsh command) that will accept the command stream > > > that is sent to it and do the work in the context of the client. That > > means > > > I do not have write any special rsh command that will open secure > channels > > > and send passwords. The rsh daemon should accept the stream in the > > > recognized rsh format which I think still is:
> > > After recieving this the rsh daemon would send a null string to client > to > > > acknowledge recieving the request. It then runs the command under the > > > context of the user and returns the result (success or failure). The > > > question is how (without a password) would I be able to get the user's > > > context? If NtCreateToken can do this then great but how?
> > > -- > > > Garfield A. Lewis > > > DB2 UDB Development, > > > IBM Canada Laboratory
> > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > > > news:u0I2J2koCHA.1532@tkmsftngp02... > > > > NtCreateToken offers you the "su" capabilities, with no Logon Session. > > > > You can create a primary token just starting from a SID.
> > > > the SAMBA folks are able to authenticate to a Windows IPS$ "share", > > > > it means that they have an SSPI "implementation", > > > > because srv.sys uses SSPI-server side to authenticate your network > logon > > > > credentials.
> > > > the official "su" for windows is runas.exe, > > > > that, as you pointed out, requires passwords.
> > > > You can always create a "secure channel" a-la-SSL to just transmit the > > > > password on the other side, > > > > so that the "daemon" can do a > > CreateProcessWithLogon/CreateProcessAsUser.
> > > > I will not even go to the topic of discussing the security > ramifications > > > of > > > > 'su', > > > > and all the exploits based on the 'suid' bit.
> > > > -- > > > > This posting is provided "As Is" with no warranties, and confers no > > > rights. > > > > Use of included script samples are subject to the terms specified at > > > > http://www.microsoft.com/info/cpyright.htm
> > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > news:u1wrNmkoCHA.2084@TK2MSFTNGP12... > > > > > The goal of RSH is to execute the command in the context of the > client > > > so > > > > > unless the client can be impersonated (local or remote) then you > will > > be > > > > > running under the contest of the local system or whatever account > you > > > use > > > > to > > > > > login your rshd service ("daemon").
> > > > > SSPI is all well and good in a Windows only environment (even though > I > > > > doubt > > > > > that the rsh.exe that is shipped with Windows is written using SSPI, > > in > > > > fact > > > > > I am pretty sure of it). But the reality is most companies/customers > > run > > > > > multiple platforms (AIX, Windows, Linux, ... and on and on). So how > > > would > > > > a > > > > > non-Windows client accomplish a rsh request?
> > > > > It would be nice if one had the ability to su on Windows as on UNIX. > > So > > > > that > > > > > if you are running in the context of the system (root) you can login > > as > > > > (or > > > > > get the context of) a user without a password and have full control. > > > Then > > > > a > > > > > rshd could be written that does the job without needing a password > for > > > the > > > > > client requestor.
> > > > > -- > > > > > Garfield A. Lewis > > > > > DB2 UDB Development, > > > > > IBM Canada Laboratory
> > > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in > > message > > > > > news:ODIhPWjoCHA.2292@tkmsftngp02... > > > > > > You can write RSH if you have a "daemon" process with the > > > > > > SeCreatePrimaryToken privilege, > > > > > > but the created token would belong to the system logon session, > and > > > the > > > > > > token would have > > > > > > no chance to do much apart from the local machine.
> > > > > > The phylosophically correct approach would be to use SSPI > > > > > > to correclty create the identity of the remote account in the > local > > > > > machine. > > > > > > There would be no password transmission. > > > > > > The API to look at would be InitialzieSecurityContext on the > > > > client-side, > > > > > > followed by a chain of AcceptSecurityContext on the server side. > > > > > > When the negotiation has happened, the Server would call > > > > > > ImpersonateSecurityContext. > > > > > > If the SSPI is going to use Kerberos as the authentication > package, > > > > > > then you can even delegate the credentials of the remote user.
> > > > > > -- > > > > > > This posting is provided "As Is" with no warranties, and confers > no > > > > > rights. > > > > > > Use of included script samples are subject to the terms specified > at > > > > > > http://www.microsoft.com/info/cpyright.htm
> > > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > > > > > This is an interesting answer, how would one then write a > > compliant > > > > RSH > > > > > > > daemon on Windows without first knowing the password of every > > > possible > > > > > > user > > > > > > > who could run a rsh command against it? Remember that rsh its > > > requests > > > > > in > > > > > > a > > > > > > > specific format and a password is not part of this data stream.
> > > > > > > > > Does anybody know a way to impresonate a process which is > > > running > > > > > > under > > > > > > > > > the SYSTEM account to an other account for which the process > > > > doesn't > > > > > > > > > know the password ?
> > > > > > > > This is *not* possible, if it were, windows-hell broke... the > > idea > > > > of > > > > > > > having > > > > > > > > passwords on a system would be voided.
> > > > > > > > > (Sorry if it's not the right place to ask my question. If > not, > > > > > please > > > > > > > > > tell me where I can do it :-)
I know this is not the "interesting" part of the code sample you gave; however, I think it needs stressing out that in most cases the client cannot be trusted (certainly in the rsh example that started this thread). If so, the server should not rely on the client telling the server its identity without some kind of validation. That's why your previous advice (establish a secure channel with the client and have it pass a username/password through it) is the one people should be using.
I known SSPI and/or SChannel is the only correct way of doing it, but the originator of the thread had a different opinion on the subject. He/She will have to deal with his/her security breaches, but he/she has been warned.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
"Ziv Caspi" <zi...@netvision.net.il> wrote in message
> I know this is not the "interesting" part of the code sample you gave; > however, I think it needs stressing out that in most cases the client > cannot be trusted (certainly in the rsh example that started this > thread). If so, the server should not rely on the client telling the > server its identity without some kind of validation. That's why your > previous advice (establish a secure channel with the client and have > it pass a username/password through it) is the one people should be > using.
I don't know if this subject is dead yet or not, but I have some comments and a new problem. It seems like you can create a primary token with zwCreateToken that can be used in CreateProcessAsUser(). This can be done without a password. The process seems to have the save security as the user used to create the token. I can share a code sample if you like, but it's pretty much the same as the code example from "Windows NT/2000 Native API Reference" by Gary Nebbett.
The new problem I have is that I would like to be able to call this from Java. So I need to do this all from a JNI DLL. Whenever I try to do this I get an access violation. I can get zwCreateToken to work in a standalone program just fine. If I try to use it in a regular DLL (not a Java JNI DLL) I get an access violation as well. The only thing I can figure is that the kernel might be getting screwed up by memory allocated within a DLL versus a stand alone program, but how can I fix it?
> Good remarks. > The purpose of the conversation was about how to obtain the Token, > and not about the ramifications of creating a process with a given token. > Sorry about that.
> -- > This posting is provided "As Is" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm
> "Pavel Lebedinsky" <m_pll at hotmail dot com> wrote in message > news:3dfe6b07$1@news.microsoft.com... > > If the intent of this code is to start notepad as the user > > whose name was obtained from the socket, then it should > > be using CreateProcessWithTokenW or CreateProcessAsUser.
> > Creating a process while impersonating is almost always > > a bug. It creates a process with the same token as the > > parent process, but the security descriptor for the new process > > is copied from the impersonated user's token. Which results > > in all kinds of interesting security problems when the new > > process tries to use its own handle (GetCurrentProcess()).
> > > the book "Windows NT/2000 Native API Reference" has a sample of > > > NtCreateToken. > > > All others are published APIs. > > > -- > > > This posting is provided "As Is" with no warranties, and confers no > > rights. > > > Use of included script samples are subject to the terms specified at > > > http://www.microsoft.com/info/cpyright.htm
> > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > news:uQXRUXuoCHA.1644@TK2MSFTNGP10... > > > > Are there any examples of NtCreateToken I cannot find any reference to > > it > > > on > > > > the MSDN website?
> > > > All I want to be able to do is write an rsh daemon (I do not want/wish > > to > > > > rewrite the client side rsh command) that will accept the command > stream > > > > that is sent to it and do the work in the context of the client. That > > > means > > > > I do not have write any special rsh command that will open secure > > channels > > > > and send passwords. The rsh daemon should accept the stream in the > > > > recognized rsh format which I think still is:
> > > > After recieving this the rsh daemon would send a null string to client > > to > > > > acknowledge recieving the request. It then runs the command under the > > > > context of the user and returns the result (success or failure). The > > > > question is how (without a password) would I be able to get the user's > > > > context? If NtCreateToken can do this then great but how?
> > > > -- > > > > Garfield A. Lewis > > > > DB2 UDB Development, > > > > IBM Canada Laboratory
> > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in > message > > > > news:u0I2J2koCHA.1532@tkmsftngp02... > > > > > NtCreateToken offers you the "su" capabilities, with no Logon > Session. > > > > > You can create a primary token just starting from a SID.
> > > > > the SAMBA folks are able to authenticate to a Windows IPS$ "share", > > > > > it means that they have an SSPI "implementation", > > > > > because srv.sys uses SSPI-server side to authenticate your network > > logon > > > > > credentials.
> > > > > the official "su" for windows is runas.exe, > > > > > that, as you pointed out, requires passwords.
> > > > > You can always create a "secure channel" a-la-SSL to just transmit > the > > > > > password on the other side, > > > > > so that the "daemon" can do a > > > CreateProcessWithLogon/CreateProcessAsUser.
> > > > > I will not even go to the topic of discussing the security > > ramifications > > > > of > > > > > 'su', > > > > > and all the exploits based on the 'suid' bit.
> > > > > -- > > > > > This posting is provided "As Is" with no warranties, and confers no > > > > rights. > > > > > Use of included script samples are subject to the terms specified at > > > > > http://www.microsoft.com/info/cpyright.htm
> > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > > news:u1wrNmkoCHA.2084@TK2MSFTNGP12... > > > > > > The goal of RSH is to execute the command in the context of the > > client > > > > so > > > > > > unless the client can be impersonated (local or remote) then you > > will > > > be > > > > > > running under the contest of the local system or whatever account > > you > > > > use > > > > > to > > > > > > login your rshd service ("daemon").
> > > > > > SSPI is all well and good in a Windows only environment (even > though > > I > > > > > doubt > > > > > > that the rsh.exe that is shipped with Windows is written using > SSPI, > > > in > > > > > fact > > > > > > I am pretty sure of it). But the reality is most > companies/customers > > > run > > > > > > multiple platforms (AIX, Windows, Linux, ... and on and on). So > how > > > > would > > > > > a > > > > > > non-Windows client accomplish a rsh request?
> > > > > > It would be nice if one had the ability to su on Windows as on > UNIX. > > > So > > > > > that > > > > > > if you are running in the context of the system (root) you can > login > > > as > > > > > (or > > > > > > get the context of) a user without a password and have full > control. > > > > Then > > > > > a > > > > > > rshd could be written that does the job without needing a password > > for > > > > the > > > > > > client requestor.
> > > > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in > > > message > > > > > > news:ODIhPWjoCHA.2292@tkmsftngp02... > > > > > > > You can write RSH if you have a "daemon" process with the > > > > > > > SeCreatePrimaryToken privilege, > > > > > > > but the created token would belong to the system logon session, > > and > > > > the > > > > > > > token would have > > > > > > > no chance to do much apart from the local machine.
> > > > > > > The phylosophically correct approach would be to use SSPI > > > > > > > to correclty create the identity of the remote account in the > > local > > > > > > machine. > > > > > > > There would be no password transmission. > > > > > > > The API to look at would be InitialzieSecurityContext on the > > > > > client-side, > > > > > > > followed by a chain of AcceptSecurityContext on the server side. > > > > > > > When the negotiation has happened, the Server would call > > > > > > > ImpersonateSecurityContext. > > > > > > > If the SSPI is going to use Kerberos as the authentication > > package, > > > > > > > then you can even delegate the credentials of the remote user.
> > > > > > > -- > > > > > > > This posting is provided "As Is" with no warranties, and confers > > no > > > > > > rights. > > > > > > > Use of included script samples are subject to the terms > specified > > at > > > > > > > http://www.microsoft.com/info/cpyright.htm
> > > > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > > > > > > This is an interesting answer, how would one then write a > > > compliant > > > > > RSH > > > > > > > > daemon on Windows without first knowing the password of every > > > > possible > > > > > > > user > > > > > > > > who could run a rsh command against it? Remember that rsh its > > > > requests > > > > > > in > > > > > > > a > > > > > > > > specific format and a password is not part of this data > stream.
> > > > > > > > > > Does anybody know a way to impresonate a process which is > > > > running > > > > > > > under > > > > > > > > > > the SYSTEM account to an other account for which the > process > > > > > doesn't > > > > > > > > > > know the password ?
The NtCreateToken API takes a non trivial ammount of hard-to-marshal params. Now, I'm at all familiar with the requirements of the IN/OUT param of a function for it to be called from JNI, but I would recomend making all the complex strutures of that function to be contiguous in memory (no constellation of allocations at all), and possibly making them to live on the stack.
-- This posting is provided "As Is" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
> I don't know if this subject is dead yet or not, but I have some comments > and a new problem. It seems like you can create a primary token with > zwCreateToken that can be used in CreateProcessAsUser(). This can be done > without a password. The process seems to have the save security as the user > used to create the token. I can share a code sample if you like, but it's > pretty much the same as the code example from "Windows NT/2000 Native API > Reference" by Gary Nebbett.
> The new problem I have is that I would like to be able to call this from > Java. So I need to do this all from a JNI DLL. Whenever I try to do this I > get an access violation. I can get zwCreateToken to work in a standalone > program just fine. If I try to use it in a regular DLL (not a Java JNI DLL) > I get an access violation as well. The only thing I can figure is that the > kernel might be getting screwed up by memory allocated within a DLL versus a > stand alone program, but how can I fix it?
> Thanks for any suggestions.
> Ben
> "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in message > news:#NKynnapCHA.2308@TK2MSFTNGP10... > > Good remarks. > > The purpose of the conversation was about how to obtain the Token, > > and not about the ramifications of creating a process with a given token. > > Sorry about that.
> > -- > > This posting is provided "As Is" with no warranties, and confers no > rights. > > Use of included script samples are subject to the terms specified at > > http://www.microsoft.com/info/cpyright.htm
> > "Pavel Lebedinsky" <m_pll at hotmail dot com> wrote in message > > news:3dfe6b07$1@news.microsoft.com... > > > If the intent of this code is to start notepad as the user > > > whose name was obtained from the socket, then it should > > > be using CreateProcessWithTokenW or CreateProcessAsUser.
> > > Creating a process while impersonating is almost always > > > a bug. It creates a process with the same token as the > > > parent process, but the security descriptor for the new process > > > is copied from the impersonated user's token. Which results > > > in all kinds of interesting security problems when the new > > > process tries to use its own handle (GetCurrentProcess()).
> > > > the book "Windows NT/2000 Native API Reference" has a sample of > > > > NtCreateToken. > > > > All others are published APIs. > > > > -- > > > > This posting is provided "As Is" with no warranties, and confers no > > > rights. > > > > Use of included script samples are subject to the terms specified at > > > > http://www.microsoft.com/info/cpyright.htm
> > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > news:uQXRUXuoCHA.1644@TK2MSFTNGP10... > > > > > Are there any examples of NtCreateToken I cannot find any reference > to > > > it > > > > on > > > > > the MSDN website?
> > > > > All I want to be able to do is write an rsh daemon (I do not > want/wish > > > to > > > > > rewrite the client side rsh command) that will accept the command > > stream > > > > > that is sent to it and do the work in the context of the client. > That > > > > means > > > > > I do not have write any special rsh command that will open secure > > > channels > > > > > and send passwords. The rsh daemon should accept the stream in the > > > > > recognized rsh format which I think still is:
> > > > > After recieving this the rsh daemon would send a null string to > client > > > to > > > > > acknowledge recieving the request. It then runs the command under > the > > > > > context of the user and returns the result (success or failure). The > > > > > question is how (without a password) would I be able to get the > user's > > > > > context? If NtCreateToken can do this then great but how?
> > > > > -- > > > > > Garfield A. Lewis > > > > > DB2 UDB Development, > > > > > IBM Canada Laboratory
> > > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in > > message > > > > > news:u0I2J2koCHA.1532@tkmsftngp02... > > > > > > NtCreateToken offers you the "su" capabilities, with no Logon > > Session. > > > > > > You can create a primary token just starting from a SID.
> > > > > > the SAMBA folks are able to authenticate to a Windows IPS$ > "share", > > > > > > it means that they have an SSPI "implementation", > > > > > > because srv.sys uses SSPI-server side to authenticate your network > > > logon > > > > > > credentials.
> > > > > > the official "su" for windows is runas.exe, > > > > > > that, as you pointed out, requires passwords.
> > > > > > You can always create a "secure channel" a-la-SSL to just transmit > > the > > > > > > password on the other side, > > > > > > so that the "daemon" can do a > > > > CreateProcessWithLogon/CreateProcessAsUser.
> > > > > > I will not even go to the topic of discussing the security > > > ramifications > > > > > of > > > > > > 'su', > > > > > > and all the exploits based on the 'suid' bit.
> > > > > > -- > > > > > > This posting is provided "As Is" with no warranties, and confers > no > > > > > rights. > > > > > > Use of included script samples are subject to the terms specified > at > > > > > > http://www.microsoft.com/info/cpyright.htm
> > > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > > > news:u1wrNmkoCHA.2084@TK2MSFTNGP12... > > > > > > > The goal of RSH is to execute the command in the context of the > > > client > > > > > so > > > > > > > unless the client can be impersonated (local or remote) then you > > > will > > > > be > > > > > > > running under the contest of the local system or whatever > account > > > you > > > > > use > > > > > > to > > > > > > > login your rshd service ("daemon").
> > > > > > > SSPI is all well and good in a Windows only environment (even > > though > > > I > > > > > > doubt > > > > > > > that the rsh.exe that is shipped with Windows is written using > > SSPI, > > > > in > > > > > > fact > > > > > > > I am pretty sure of it). But the reality is most > > companies/customers > > > > run > > > > > > > multiple platforms (AIX, Windows, Linux, ... and on and on). So > > how > > > > > would > > > > > > a > > > > > > > non-Windows client accomplish a rsh request?
> > > > > > > It would be nice if one had the ability to su on Windows as on > > UNIX. > > > > So > > > > > > that > > > > > > > if you are running in the context of the system (root) you can > > login > > > > as > > > > > > (or > > > > > > > get the context of) a user without a password and have full > > control. > > > > > Then > > > > > > a > > > > > > > rshd could be written that does the job without needing a > password > > > for > > > > > the > > > > > > > client requestor.
> > > > > > > "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote in > > > > message > > > > > > > news:ODIhPWjoCHA.2292@tkmsftngp02... > > > > > > > > You can write RSH if you have a "daemon" process with the > > > > > > > > SeCreatePrimaryToken privilege, > > > > > > > > but the created token would belong to the system logon > session, > > > and > > > > > the > > > > > > > > token would have > > > > > > > > no chance to do much apart from the local machine.
> > > > > > > > The phylosophically correct approach would be to use SSPI > > > > > > > > to correclty create the identity of the remote account in the > > > local > > > > > > > machine. > > > > > > > > There would be no password transmission. > > > > > > > > The API to look at would be InitialzieSecurityContext on the > > > > > > client-side, > > > > > > > > followed by a chain of AcceptSecurityContext on the server > side. > > > > > > > > When the negotiation has happened, the Server would call > > > > > > > > ImpersonateSecurityContext. > > > > > > > > If the SSPI is going to use Kerberos as the authentication > > > package, > > > > > > > > then you can even delegate the credentials of the remote user.
> > > > > > > > -- > > > > > > > > This posting is provided "As Is" with no warranties, and > confers > > > no > > > > > > > rights. > > > > > > > > Use of included script samples are subject to the terms > > specified > > > at > > > > > > > > http://www.microsoft.com/info/cpyright.htm
> > > > > > > > "Garfield Lewis" <gale...@ca.ibm.com> wrote in message > > > > > > > > news:e3M0u8hoCHA.2328@TK2MSFTNGP11... > > > > > > > > > This is an interesting answer, how would one then write a > > > > compliant > > > > > > RSH
