Hello, The ImpersonateClient API does not require that credentials are embedded into the program. A call to ImpersonateClient allow a server to "impersonate" the client when it receives a local connection, e.g. via a named pipe. It is mostly used by servers to DROP their privileges to that of the connecting user if they are running with administrative privileges. A security issue with ImpersonateClient arises if there's no error checking on the ImpersonateClient call and the process runs without realizing that it is still SYSTEM. Another issue would be an unprivileged client with the ImpersonateClient privilege, if an attacker manages to make a process with admin rights connect to that client. This is why normal users do not have this right by default.
Regards, Bernhard Paul Schmehl wrote: > --On Wednesday, January 18, 2006 17:07:23 -0600 Frank Knobbe > <[EMAIL PROTECTED]> wrote: > >> On Wed, 2006-01-18 at 16:16 -0600, Paul Schmehl wrote: >> >>> This means that the exposure, when granting the privilege, is as >>> follows: >>> 1) If you can launch a process on the local machine AND >>> 2) The process has embedded credentials that are different from the user >>> launching the process THEN >>> 3) The user gains those credentials' privileges ***for the length of >>> that process*** >> >> >> Yup. So if your use has that right, any spyware the user downloads via >> IE can use that user right to elevate credentials **for the length of >> the malware installation**. Does that sound right? And does that sound >> like something you'd want to happen? >> > The spyware has to bring the credentials with it. The user doesn't > *have* the credentials. It *gets* them from the process in question. > That's a bit different. The user has the right to impersonate within > the context of a process. The process must already have the credentials > to elevate, or the user gets nothing (if I'm understanding impersonation > correctly.) > >> >> If you give that right, or admin privs, why don't you limit that only to >> the duration of the software install? It sounded like you were planning >> on granting that user right and leaving it in place. If you only grant >> it temporarily, the exposure is not great, imho. (Remember, I've been >> liberated from Windows for a couple years now ;) >> > Do you know a way to programmatically grant rights, on the fly, and then > take them away? I know you can do this with RunAs, but that would > require having an admin password, in the clear, and readable by > Authenticated Users. That ain't gonna happen. > > As far as granting the privilege goes, *if* we do it, it will only be in > place long enough to distribute the agents. Then it will be removed. > But I'm reluctant to even do *that* until I'm certain I fully understand > the ramifications. > > Paul Schmehl ([EMAIL PROTECTED]) > Adjunct Information Security Officer > University of Texas at Dallas > AVIEN Founding Member > http://www.utdallas.edu/ir/security/ > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
