Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 61198 - OpenSSH's sshd doesn't daemonize itself properly
OpenSSH's sshd doesn't daemonize itself properly
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
: Security
: 59382 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-03-15 02:13 EST by James Ralston
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-24 14:57:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to make sshd daemonize itself properly (2.87 KB, patch)
2002-03-15 02:15 EST, James Ralston
no flags Details | Diff

  None (edit)
Description James Ralston 2002-03-15 02:13:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311

When sshd starts, it closes file descriptors 0, 1, and 2, but doesn't bother to
close any addition file descriptors it may have inherited.  This is a bug; any
security conscious program should close *all* inherited fds upon starting.  (See
[Stevens] section 13.3.)

In the past, there have been several programs, including sendmail, that could be
exploited by opening all but a couple fds and then starting the program and
having it croak due to an unexpected shortage of descriptors.  In some cases, it
was possible to turn this into a root level exploit.

I don't know if OpenSSH can be exploited in this manner, but the bug should be
fixed before someone decides to see if it can.

I already tried to get the OpenSSH developers to fix this bug, but they refused;
see http://bugzilla.mindrot.org/show_bug.cgi?id=3 for the whole sad exchange.

The attached patch fixes this bug, as well as correcting a few other issues with
the way in which sshd daemonizes itself.  If you add it as Patch10 to the recent
openssh-3.1p1-2.src.rpm errata, it will apply cleanly.


[Stevens]: Advanced Programming in the UNIX Environment, W. Richard Stevens,
Addison-Wesley, 1992.
Comment 1 James Ralston 2002-03-15 02:15:10 EST
Created attachment 48564 [details]
patch to make sshd daemonize itself properly
Comment 2 Alan Cox 2002-12-18 15:48:11 EST
Still true with current sshd

It still doesn't seem to pose a problem in the Red Hat cases for two reasons: 
1. Our sshd is normally run from scripts at boot up
2. Our login does close fds so seems to avoid leaks

I still think this is a good idea and good practice
Comment 3 James Ralston 2003-01-20 02:26:11 EST
Actually, this *has* caused a problem before: rpm used to have a bug where
scripts (%post, %postun, etc.) inherited fds from rpm.  As a result, running
"rpm -Uvh openssh-server*.rpm" could hang, because the openssh-server package
contains a %post script to perform "/sbin/service sshd condrestart", and the new
sshd process wound wind up inheriting a bogus fd.

I agree with the OpenSSH guys, in that in the above situation, the true bug lies
with the program (rpm) that never bothered to close its extra fds before forking
a child.  But I disagree with the OpenSSH guys, in that I believe that *any*
program that is security-sensitive in any way absolutely needs to sanitize the
environment it inherits, regardless of whether that sanitizing winds up hiding a
bug in some other program.  (And the fd table definitely counts as an inherited
Comment 4 Mike A. Harris 2003-03-05 06:36:27 EST
Some additional info:

Comment 5 Josh Bressers 2004-06-18 16:55:15 EDT
Is this issue still relevant?
Comment 6 James Ralston 2004-06-25 20:15:59 EDT
Does OpenSSH still fail to properly daemonize itself?  Yes.

Will upstream accept a patch to fix it?  No.  Why?  Because they don't
view it as a potential security problem.  I do.  (There have been
cases in the past where programs could be exploited by filling or
mostly-filling the fd table before exec()ing them.)

Paul Vixie's point that _SC_OPEN_MAX can be a huge number (2**24-1) is
a valid one, but after some thought, I believe the best way to address
that is to first attempt to use /proc/self/fd to obtain the list of
open file descriptors.  If /proc/self/fd is unavailable, then fall
back to doing brute-force close() calls up to the value of _SC_OPEN_MAX.

I can supply a patch to implement the behavior in the previous
paragraph.  The issue for you is to choose what you feel is the lesser
of two evils: maintaining a patch that upstream will never accept, or
tolerating sloppy coding that could lead to a security vulnerability
in the future.
Comment 7 Tomas Mraz 2005-01-26 12:00:01 EST
I don't see how could the sshd be exploited by filling it's open fds
table - it's not a setuid binary. The different situation would be if
the sshd would be started from an buggy application as in the comment
#3 and the opened fd was exploited somehow by a connecting client. But
even then it would be the responsibility of the buggy exec'er. 

But I think I could accept a patch which would close the fds from
/proc/self/fd if available (without the brute force fallback).
Comment 8 Tomas Mraz 2005-02-03 05:44:39 EST
*** Bug 59382 has been marked as a duplicate of this bug. ***
Comment 9 James Ralston 2005-02-03 15:59:07 EST
The problem is that there might be situations in which an attacker could
contrive to have sshd [re]started from a buggy application.  In that case, the
risk isn't so much a buggy exec'er as it is a malicious exec'er.

I actually agree with the OpenSSH guys in that sshd shouldn't coddle buggy
exec'er.  But sshd is an extremely security-sensitive application.  It pays to
be paranoid, even if doing so has the undesired side-effect of coddling buggy

If you'll accept a patch to close open fds based on /proc information, then I'll
provide it.  But there's no way the OpenSSH guys will ever accept such a patch.
Comment 10 Tomas Mraz 2005-09-08 11:41:32 EDT
I will consider this for FC5.
Comment 11 Tomas Mraz 2007-09-24 14:57:11 EDT
This should be fixed upstream.
Comment 12 James Ralston 2007-09-25 14:40:13 EDT
It's not fixed in 4.7p1, as far as I can tell.  Per comment 9, I doubt the
OpenSSH developers will ever fix this, because they don't think it's a bug.

Note You need to log in before you can comment on or make changes to this bug.