OpenSSh 3.4p1 PrivilegeSerparation experiment

From: HAYDEN AARON N. (Aaron.Haydenat_private)
Date: Fri Jun 28 2002 - 10:47:27 PDT

  • Next message: Vilmos Soti: "Re: Possible flaw in XFree?"

    Issue:  Killing sshd produces behavior you may not expect.
    
    Greetings,
            I submit for your evaluation the results of playing with (open)sshd
    	and PrivilegeSeparation.  
    
    My platform: OpenSSh 3.4p1 server with 'UsePrivilegeSeparation yes' on a 
                 non-distrobution GNU/Lunix 2.4, etc. 
    Notice that:
        o   sshd is written to re-parse sshd_config and launch and new process
            on receiving SIGHUP.  
        o   you expect disconnection from an ssh'd tty when root sends sshd the
            signal to hangup.
    
    In action:
            Theo wasn't kidding when he said (of the recent OpenSSh 
    	vulnerabilities): 
               'A part containing about 2500 lines of code remains'
               'as root, and the rest of the code is shoved into a'
               'chroot-jail without any privs.                    '
    
       o    Here's what processes run when I log in from a foreign machine:
    	(edited for 80cols)
               $ `ps aux |grep sshd`
               root  344  0.0  0.5  2720 1384 ? S 17:40 0:00 /usr/sbin/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
    	
       o   That last beastie (1160) is the privilege dropped chunk.
    
       o   Now see which process are on which port:
              $ `lsof -i :ssh`
              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
    
       o   Of course, to those processes, nothing did happen.
    
    A bug?:
           No, I do not think so.   
           But is this the behavior you would expect?
    
    Possibilities:
           Maybe someone silly designed their own init scripts to kill by pid.
           Maybe someone is still connected when you think they're not.
    
    Thanks:   
           Hats off to OpenSSh devel.
    Sorry:
           If you get this message more than once (list problems).
    



    This archive was generated by hypermail 2b30 : Fri Jun 28 2002 - 16:16:52 PDT