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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- ------SupplyEdge------- Greg Hunt 800-733-3380 x 107 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
