full-disclosure - Question for the Windows pros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20B667D6E4C910ABFC6DC569@utd59514.utdallas.edu>
Date: Thu Jan 19 16:23:48 2006
From: pauls at utdallas.edu (Paul Schmehl)
Subject: Question for the Windows pros

--On Thursday, January 19, 2006 08:20:37 +0100 Bernhard Mueller 
<research@...-consult.com> wrote:

> 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.
>
When you say "manages to make a process with admin rights connect", you are 
referring to the Local Administrator account on the machine in question, 
correct?

So far, from what I understand, granting this privilege to a User means 
that *if* a process with higher privileges can connect to the computer in 
question, the User's privileges will be elevated through impersonation.  If 
this is the case, then the security risk is minimal, I would think.

I would welcome suggestions regarding scenarios where this could be used to 
exploit a box.  ISTM if the connecting process already has the admin 
rights, elevating the User's rights through impersonation merely elevates 
the User to the same level of privilege that the process already has.

Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/