Running sshd with Privilege Seperation drops connection on password change

[Damien Miller]

Hi,

We'll need to see a full debug log from the server - it's not possible to
see what is going one from the abridged ones you sent.

-d

On Fri, 4 Dec 2015, Nasim, Kam wrote:

> Hi folks,
> 
> I came across this issue on both stock CentOS(v6.4) and Ubuntu(14.04 LTS) and was wondering if any of you have seen it.
> As far as I can tell this seems like a day-1 bug to me.
> 
> PROBLEM:
> If I expire a linux user's password (passwd -e <user>) and then log in via ssh, it will prompt you for a password change.
> On changing the password successfully, sshd will drop the connection and client has to reconnect.
> 
> 
> ANALYSIS:
> 
> Looking at sshd debug logs, it would appear that the child process that runs passwd SIGCHLD's to the parent which appears to be treating that signal as a SIGTERM:
> 
> Dec 3 18:36:17 knasim-ubuntu1 passwd[3152]: pam_unix(passwd:chauthtok): password changed for wrs <<<<<<<
> Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: Received SIGCHLD. <<<<<<<<<<<<<<<<<<
> Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_by_pid: pid 3152
> Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_exit_message: session 0 channel 0 pid 3152
> Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug2: channel 0: request exit-status confirm 0 <<<<<<<<<<<
> 
> 
> By default, in  sshd "Privilege Separation"  is enabled.  What does this mean?
> 
> It means that sshd spawns an unprivileged process that does basic authentication and that guy spawns a child process running as root to run passwd (in this case).
> 
> After password change, the child SIGCHLD's the parent which instead of handling it properly treats it like a SIGTERM and closes the socket.
> 
> The following process tree should give a better idea of the process nestings:
> 
> With Privilege Separation:
> ubuntu at knasim-ubuntu1:~$ pstree
> init─┬─acpid
>      ├─atd
>      ├─cron
>      ├─dbus-daemon
>      ├─dhclient
>      ├─7*[getty]
>      ├─rsyslogd───3*[{rsyslogd}]
>      ├─sshd───bash───ssh
>      ├─sshd───bash───pstree
>      ├─sshd───sshd───sshd───passwd
>      ├─systemd-logind
>      ├─systemd-udevd
>      ├─upstart-file-br
>      ├─upstart-socket-
>      └─upstart-udev-br
> 
> Without Privilege Separation:
> init─┬─acpid
>      ├─atd
>      ├─cron
>      ├─dbus-daemon
>      ├─dhclient
>      ├─7*[getty]
>      ├─rsyslogd───3*[{rsyslogd}]
>      ├─sshd─┬─sshd───bash───ssh
>      │      ├─sshd───bash───pstree
>      │      └─sshd───sshd
>      ├─systemd-logind
>      ├─systemd-udevd
>      ├─upstart-file-br
>      ├─upstart-socket-
>      └─upstart-udev-br
> 
> If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication.
> 
> 
> What do you guys think? Have others come across this? Is there a patch available for this?
> 
> Thanks,
> Kam
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>