OpenSSH - forced command - no-pty issue

[Kumaresh]

Hello,

Thanks for the pointers.

Unfortunately, we do not have options such as "shopt ..." in Ksh or sh and
we are using these shells on HP-UX. From our point of view, this is a
security issue. A malicious user could cause a denial of service on the
server by establishing many connections and breaking them, which would leave
many shell processes/sub-processes running on the server and thus might
eventually exhaust the kernel resources on the server.

We have done some changes to the openssh source to fix this issue. The patch
is attached with this mail and the diff is taken with OpenSSH-3.7.1p2
version. The basic change is, sending the HUP to the process group when the
session is closed. There are two issues in this, the forced command may be a
foreground process or a background process. So, the modification in
session_close() function is such that,

1. If the child process has exited, no need to send any signal.
2. If the child process has not exited, then kill the process group using
kill(-pid, SIGHUP).

While the changes in session_close( ) works for HP-UX ssh clients, it is not
working for the windows PuTTY ssh clients. So, that is corrected by calling
session_destroy_all(NULL) in the process_input( ) function in serverloop.c,
where the server gets terminated when the PuTTY client session is closed.

BTW, rshd works in this way. The HUP signal is passed to the process group
when we execute the remote commands.

Please review the patch and let us know if this will be added to the next
version.

ViSolve OpenSSH Support
support at visolve.com
www.visolve.com


----- Original Message -----
From: "Darren Tucker" <dtucker at zip.com.au>
To: "Kumaresh" <kumaresh_ind at gmx.net>
Cc: <madhav_vaidy at yahoo.com>; "OpenSSH Devel List"
<openssh-unix-dev at mindrot.org>
Sent: Tuesday, January 20, 2004 6:41 AM
Subject: Re: OpenSSH - forced command - no-pty issue


> Kumaresh wrote:
> > The major problem we are running into is that the shell (both sh and
ksh)
> > does not kill its child processes when there is no pty. The SSH patch
> > mentioned previously at
> > http://bugzilla.mindrot.org/show_bug.cgi?id=396
> >
> > is not sufficient to kill the forced command completely.It will only
kill
> > the shell script, but not any child processes the shell script runs. The
> > shell assumes the child is in the background (because there is no pty)
and
> > therefore does not kill the child.
>
> The script should catch the SIGHUP and clean up after itself.
>
> > Consider a shell script /tmp/test.sh that in turn calls "sleep 1000". If
we
> > run a forced command
> > command="/tmp/test.sh",no-pty,no-port-forwarding ssh-rsa
> > it gives the following processes:
> >
> >    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
> >    root 13309 12724 10 05:24:20 ?   0:00 sshd: root at notty
> >    root 13313 13309  4 05:24:21 ?   0:00 /tmp/test.sh
> >    root 13314 13313  2 05:24:21 ?   0:00 sleep 1000
> >
> > When we disconnect the client, the sshd process is killed and the shell
> > script keeps running:
> >
> >    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
> >    root 13313     1  0 05:24:21 ?   0:00 /tmp/test.sh
> >    root 13314 13313  0 05:24:21 ?   0:00 sleep 1000
> >
> > When we apply the patch to sshd, the sshd process sends a SIGHUP
(hangup)
> > signal to /tmp/test.sh before exiting. The shell script (/tmp/test.sh)
is
> > killed, but the shell
> > script does NOT kill its child sleep process. Here is the process list
after
> > the client disconnects:
> >
> >    root 12724     1  0 04:46:13 ?   0:00 /opt/ssh/sbin/sshd
> >    root 13314     1  0 05:24:21 ?   0:00 sleep 1000
> >
> > You can test this by manually running the command:
> >   # PID=`ps -ef | grep /tmp/test.sh | awk '{print $2}'`
> >   # kill -HUP $PID
> >
> > The shell script will be killed but the child process (sleep 1000) will
keep
> > running.
>
> The shell (script) needs to deal with its own children, there's not much
> sshd can do (except possibly sending the HUP to the process group rather
> than the shell?)
>
> It seems similar to this bug:
> http://bugzilla.mindrot.org/show_bug.cgi?id=52
>
> "Known-good workarounds:
> * bash: shopt huponexit on
> * tcsh: none
> * zsh: setopt HUP (usually the default setting)
>    (taken from email from Jason Stone to openssh-unix-dev, 5
>    May 2001)
> * pdksh: ?"
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>      Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.561 / Virus Database: 353 - Release Date: 1/13/2004