Re: DSA-134-1
Well I'm not an open-bsd developer nor have I looked through the privilege seperation code so I only know what I read at http://www.citi.umich.edu/u/provos/ssh/privsep.html but according to that site (linked to from openssh.com) the privileged process (process 1) forks the unprivileged child (process 2) when a connection is made, this child talks to the client and requests authentication from the parent. If the authentication is sucessfull the parent passes the child a PTY, if not there's not much the child process can do.
The child itself is never able to say "give me a root shell", or "give me a shell for user xyz" so the child becoming corrupted doesn't compromise the security of the whole system (that's the point of priv seperation).
-Greg
PS: the site linked to above does a much better job of explaining this
> >this shellcode is executed as user ralf, not as user root.
>
> I'm not worried about a shell spawned by the chrooted process.
>
> Chroot and su to some undangerous user helps if that's one-way only,
> i.e. the process doesn't have any connection to sensitive areas
> anymore. But in the case of sshd, it's not one-way: as far as I
> understand, the process running in the chroot as 'sshd' (say process
> 2) user does the communication with the client, but, and that's the
> problem, it does have a connection with a sister process running as
> root (say process 1) which it tells to launch a login shell for the
> user requested by the client. Normally, process 2 would of course
> only advise process 1 to do that if the remote client correctly
> identifies itself/gives the password. But if a malicious client
> submits data that corrupts process 2, he could make it to tell
> process 1 to launch a login shell for root. How should process 1 find
> out whether process 2 has been corrupted?
>
> (Well, it would be easy if logins are username/password only: if the
> check for correct username/password is done by process 1, process 2
> has to provide them which it can't if the cracker doesn't know them
> anyway. But since ssh also allows public-key based logins, and I
> would guess that the key check is done by process 2, it looks
> different. Sorry if this starts to be OT.)
>
> Christian.
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
------SupplyEdge-------
Greg Hunt
800-733-3380 x 107
greg@supplyedge.com
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: