Re: OpenSSh 3.4p1 PrivilegeSerparation experiment

[Brian Hatch <vuln-dev () ifokr org>]

> Notice that:
>     o   sshd is written to re-parse sshd_config and launch and new process
>         on receiving SIGHUP.  

Yep.

>     o   you expect disconnection from an ssh'd tty when root sends sshd the
>         signal to hangup.

Ummm, no I don't.  That's never been the way ssh has worked.

...

>           COMMAND PID USER FD DEVICE NODE NAME
>           sshd    344 root 3u 479     TCP *:ssh (LISTEN)
>           sshd   1158 root 4u 13436   TCP localhost:ssh->remote:52589 (EST)
>           sshd   1160 user 4u 13436   TCP localhost:ssh->remote:52589 (EST)
>
>    o   We have the real daemon listening, and the spinoffs handling my
>        connection via a highport and interface:ssh.
>
>        This behavior is so far what I expect.
>
> Until:
>        You send SIGHUP to the original process; your connection remains.
>
>    o   The spunoff processes (not listening) continue like nothing
>        happened, a la:  
>            $ `ps aux |grep sshd`
>            root 1158  0.0  0.6  5628 1716 ? S 17:56 0:00 /usr/sbin/sshd
>            user 1160  0.0  0.6  5648 1772 ? S 17:56 0:00 /usr/sbin/sshd
>            root 1184  0.0  0.5  2720 1384 ? S 18:20 0:00 /usr/sbin/sshd

The server ssh process, #344, when it got the HUP forked off and
reread the sshd_config, resulting in process 1184 above.  Your
existng two processes, 1158 and 1160 stayed alive.  Which is what
should happen, and always has happened.  Killing the main ssh
process (the one that does the initial accept on the network socket)
has never killed off active user sessions.  Else how could you upgrade
ssh remotely?

This would seem to be expected behaviour.

--
Brian Hatch                  "Is there a Lawyer
   Systems and                  in the House?"
   Security Engineer          **BLAM!**
http://www.ifokr.org/bri/     "Any more?"

Every message PGP signed

Attachment: _bin
Description: