At 17:16 Uhr +0200 25.06.2002, Ralf Dreibrodt wrote:
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.)
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com