full-disclosure - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu Jan 19 15:20:43 2006
From: davek_throwaway at hotmail.com (Dave Korn)
Subject: Re: Question for the Windows pros

Paul Schmehl wrote in news:88FAB09D4B4C0A80874E16A4@...59514.utdallas.edu

> This is how I understand the process:
>
> 1) Joe, who is a User, launches the custom installer (through a login
> script)
> 2) The install process begins running under Joe's credentials (User)
> 3) At some point in the install process, elevated privileges are required
> to continue
> 4) Joe doesn't have them, but he has the Impersonate privilege.
> 5) Joe's process requests the credentials embedded in the custom installer

  No.  They aren't embedded in the installer.  They are the credentials 
belonging to another process, to which the impersonator is connected, via a 
pipe or LPC port, that the impersonator holds the server end of.

> 6) Joe's process uses those credentials to complete the install, then
> relinquishes them
>
> 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***

  It is indeed the case that a process that is impersonating cannot pass on 
the impersonated credentials to a child process.  However, credentials are 
not "embedded" in processes, or in executables; ultimately, they come from 
the SAM or AD.

>> From a hacker standpoint, this means that you would already need elevated
> privileges in order to take advantage of the user's right to impersonate.
> This is a fairly low risk.
>
> So, why did M$ decide to remove this right from the user?  Because it
> prevents them from installing software on the box.

  It could in theory be abused to escalate privileges.

> OK, shoot holes in my theory.

  As I said in another post in this thread, I'm writing a fuller explanation 
that I'll post later when I get time to finish it up.

  cheers,
      DaveK
-- 
Can't think of a witty .sigline today....