4 ms·

If the parent process were deliberately sharing memory pages with the child it might be possible to get those pages (or, if the child process executes code from

If the parent process were deliberately sharing memory pages with the child it might be possible to get those pages (or, if the child process executes code from them, to do pretty much anything with it). These seem like pretty novice mistakes for the openssh team to make, though. A more important issue is that the window in which your connection is actually being managed by the parent process of all sshd instances must be vanishingly small. More likely you'd be looking to access memory while the ssh process was still privileged. I'm still not sure what that'd get you, though.

djmdjm 13y ago
So, there are usually four sshd processes involved in handling a connection: 1 - master sshd, listens for incoming connections. When it accepts one it forks and executes a new sshd to handle it. It executes a new sshd to ensure that each one gets different runtime randomisations (ASLR mappings, PRNG state, etc.) 2 - privileged sshd. This is the result of the fork+exec of (1) above. It does absolutely no packet processing and exists only to perform options that require privilege or access to sensitive data (e.g. the host keys). As soon as it starts, it forks an unprivileged process. 3 - pre-auth sshd. This is the first unprivileged process forked by #2. It is responsible for packet processing and most crypto (except that which touches sensitive data). This process runs in chroot, In recent OpenSSH versions, this process is sandboxed using systrace, seccomp-bpf, OS X seatbelt or (if none of these are supported) restrictive rlimits. It exits as soon as the user is authenticated. 4 - post-auth sshd. This is forked from the #2 process after authentication completes. It runs with the privileges of the user and handles network packets and crypto much like #3. Most of this (except the re-exec and sandboxing) is described in Niels Provos' original privsep paper: http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.citi.umich.edu/u/provos/ssh/privsep.html
- stormbrew 13y ago
  Thanks. I knew openssh had a pretty complex system for this, this is a good summary.

djmdjm 13y ago

So, there are usually four sshd processes involved in handling a connection: 1 - master sshd, listens for incoming connections. When it accepts one it forks and executes a new sshd to handle it. It executes a new sshd to ensure that each one gets different runtime randomisations (ASLR mappings, PRNG state, etc.) 2 - privileged sshd. This is the result of the fork+exec of (1) above. It does absolutely no packet processing and exists only to perform options that require privilege or access to sensitive data (e.g. the host keys). As soon as it starts, it forks an unprivileged process. 3 - pre-auth sshd. This is the first unprivileged process forked by #2. It is responsible for packet processing and most crypto (except that which touches sensitive data). This process runs in chroot, In recent OpenSSH versions, this process is sandboxed using systrace, seccomp-bpf, OS X seatbelt or (if none of these are supported) restrictive rlimits. It exits as soon as the user is authenticated. 4 - post-auth sshd. This is forked from the #2 process after authentication completes. It runs with the privileges of the user and handles network packets and crypto much like #3. Most of this (except the re-exec and sandboxing) is described in Niels Provos' original privsep paper: http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.citi.umich.edu/u/provos/ssh/privsep.html

stormbrew 13y ago
Thanks. I knew openssh had a pretty complex system for this, this is a good summary.