I was wondering if the following attack would be feasible once I'm able to break into rlimit sandbox. Because sandboxed process that handles unauthenticated session is running as the 'sshd' user I was wondering if this could be used to jump between processes using ptrace(2). For example if I find a bug in the code executed before authentication I could use ptrace(2) to attach to another unprivileged processes running with the same credentials as I am. If I understand correctly this sandbox process is responsible for extracting credentials of the connecting user from the protocol, which means if I attach to a process handling root loggining in with a password I could obtain root's password. Can someone confirm or tell me what am I missing? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20131220/19b13c8f/attachment-0001.bin>
On Fri, 20 Dec 2013, Pawel Jakub Dawidek wrote:> I was wondering if the following attack would be feasible once I'm able > to break into rlimit sandbox. > > Because sandboxed process that handles unauthenticated session is > running as the 'sshd' user I was wondering if this could be used to jump > between processes using ptrace(2). For example if I find a bug in the > code executed before authentication I could use ptrace(2) to attach to > another unprivileged processes running with the same credentials as I > am. If I understand correctly this sandbox process is responsible for > extracting credentials of the connecting user from the protocol, which > means if I attach to a process handling root loggining in with a > password I could obtain root's password. > > Can someone confirm or tell me what am I missing?It shouldn't be possible because the child process has a setuid in its history and this should deny ptrace of the process by any user but root. -d