Bug 61198
Summary: | OpenSSH's sshd doesn't daemonize itself properly | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | James Ralston <ralston> | ||||
Component: | openssh | Assignee: | Tomas Mraz <tmraz> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | rawhide | CC: | bressers, k.georgiou, peak | ||||
Target Milestone: | --- | Keywords: | Security | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-09-24 18:57:11 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
James Ralston
2002-03-15 07:13:21 UTC
Created attachment 48564 [details]
patch to make sshd daemonize itself properly
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 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 environment.) Some additional info: http://marc.theaimsgroup.com/?l=bind9-workers&m=103112021703700&w=2 Is this issue still relevant? 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. 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). *** Bug 59382 has been marked as a duplicate of this bug. *** 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 exec'ers. 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. I will consider this for FC5. This should be fixed upstream. 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. |