3 ms·

> This vulnerability exploits a bad check on the network layer of the sshd server that we trigger to retrieve all children processes memory sections… That's no

> This vulnerability exploits a bad check on the network layer of the sshd server that we trigger to retrieve all children processes memory sections… That's not making sense to me. I really thought that, and correct me if I'm wrong here, parents never had access to child process memory and that you had to go out of your way to do even limited memory sharing between processes.

stormbrew 12y ago
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 12y 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 12y ago
    Thanks. I knew openssh had a pretty complex system for this, this is a good summary.
jacquesm 12y ago
Well, technically after a fork you have access to all the childs memory pages, they're identical to your own (that is, until any writes happen, usually that's when copies are made and each process ends up with a different version of that page). But then the 'exec' bit happens and it's a completely new process. Any access to memory of the child process thereafter would be through some deliberate mechanism unless there is a significant issue with the underlying operating systems ability to keep processes where they belong (separated). The whole idea is that processes have separate memory spaces, debuggers, shared memory applications and IPC implementation work hard to do this on purpose. If sshd really had unfettered access to its child processes then so would every other process that spawns some new process, init comes to mind as a nice candidate, cron as another (though neither exposes network sockets). Of course, a process running as 'root' has technically access to all the other processes memory through (on Linux) /dev/mem (phys) and /dev/kmem (virt) but you have to open it first and as far as I'm aware sshd does not do this.
- nitrogen 12y ago
  ...(though neither exposes network sockets). I'm not sure, but that may no longer be true with systemd.

stormbrew 12y ago

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 12y 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 12y ago
  Thanks. I knew openssh had a pretty complex system for this, this is a good summary.

jacquesm 12y ago

Well, technically after a fork you have access to all the childs memory pages, they're identical to your own (that is, until any writes happen, usually that's when copies are made and each process ends up with a different version of that page). But then the 'exec' bit happens and it's a completely new process. Any access to memory of the child process thereafter would be through some deliberate mechanism unless there is a significant issue with the underlying operating systems ability to keep processes where they belong (separated). The whole idea is that processes have separate memory spaces, debuggers, shared memory applications and IPC implementation work hard to do this on purpose. If sshd really had unfettered access to its child processes then so would every other process that spawns some new process, init comes to mind as a nice candidate, cron as another (though neither exposes network sockets). Of course, a process running as 'root' has technically access to all the other processes memory through (on Linux) /dev/mem (phys) and /dev/kmem (virt) but you have to open it first and as far as I'm aware sshd does not do this.

nitrogen 12y ago
...(though neither exposes network sockets). I'm not sure, but that may no longer be true with systemd.