From owner-cvs-src Fri Feb 21 11:15:37 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D442C37B401; Fri, 21 Feb 2003 11:15:32 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56C8E43FE1; Fri, 21 Feb 2003 11:15:31 -0800 (PST) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-89-252.client.attbi.com[12.234.89.252]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003022119153000300nf4r4e>; Fri, 21 Feb 2003 19:15:30 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.6/8.12.3) with ESMTP id h1LJFTeq090612; Fri, 21 Feb 2003 11:15:29 -0800 (PST) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.6/8.12.6/Submit) id h1LJFSPV090611; Fri, 21 Feb 2003 11:15:28 -0800 (PST) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 21 Feb 2003 11:15:28 -0800 From: "Crist J. Clark" To: "M. Warner Losh" Cc: ru@FreeBSD.org, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet in_pcb.c Message-ID: <20030221191528.GC90209@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <200302210528.h1L5SS0H092948@repoman.freebsd.org> <20030221131205.GE30966@sunbay.com> <20030221.062059.34122968.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030221.062059.34122968.imp@bsdimp.com> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Feb 21, 2003 at 06:20:59AM -0700, M. Warner Losh wrote: > One implication of this is that if you have a server running on a > used-to-be priviledged port and now run it on a no-privs port your > machine has more potential for compromise. If an attacker can make > that server die, and has an accaount on your machine, that attacker > can replace the daemon with his own by winning the restart race. With > priviledged ports, root was the only one that mattered. I purposely just went ahead and made the change this time rather than slog through the theological discussion about the concepts of privileged ports one more time, but I'll just go through the motivation one more time. First, we all know the history of privileged ports and UNIX, the r-commands, clusters of trusted root machines, yada-yada. Obviously, if you are using r-commands, you wouldn't want to make the ports unpirivieged. If you are using the old security model (whether it is actually appropriate for your network environment, that's your call), you can continue to do so. Like Warner's quote above, one can think of new vulnerabilities this opens up dealing with "stealing" ports from privileged daemons. However, there are important, "trusted" services that run on unprivileged ports all of the time. NFS lives at 2049, AFS lives on high ports too. All of the cvsupd servers that distribute our source code to the world send it from 5999/tcp. People "stealing" these or other unprivileged ports has really never come up as much of a problem (but yes, that doesn't mean it never will). As DES already pointed out, the most pervasive OSes on the Internet, those ones from that company in Redmond, WA, don't have a concept of privileged ports at all. Now many versions of and applications for that OS-type have some rather serious security issues, but the lack of privileged ports is pretty much never mentioned as one of them. I would go as far as to say that the biggest vulnerability this change opens is the fact that many people may have to change their mode of thinking when evaluating security risks; one assumption they've always made, (< 1023) = root, is not necessarily true. But I counter that in many, many cases, the remote user doesn't really care if root is the owner or not. The Internet is not the kind of network that the r-commands were developed for. If I don't really trust root on a remote machine, why do I care whether a service is running on a root-only port or not? So for the remote user connecting to an untrusted service on an untrusted machine, reserved ports are pretty much meaningless already. So what are the gains? As I think was clear in my commit message, privileged ports can also make you less secure. Things that don't really need root for their main functions, may need root privileges to open ports. Let me tell you why I did this when I did. In my day job I work mostly with proprietary OSes and software, and I was doing a security review of a particular piece of proprietary software on a proprietary OS. Like most software, it's crap. It's poorly designed, loaded with bugs, and poorly documented. From a security point of view it is a nightmare. It runs as root, and the only reason I could see that it does so is to be able to open reserved ports. Being poorly designed, it doesn't drop privileges once it is done. Now, if I could convince the OS to let non-root users to open that port, I might be able to get away with running it as non-root, but my proprietary OS does not have such an option. Result: I get very frustrated that I can't do anything about it there, so I redirect my frustration to try to do some good where I can. The poster child for this kind of thing is ftpd. ftpd needs to run as root throughout its runtime so it can service active data connections and bind port 20/tcp. How many root compromises have we seen in various ftpd implementations because of this? Some blame the protocol, (as a firewall administrator, I know that FTP is evil), but FTP is not changing now and is not going away any time soon. If we let non-root users at port 20/tcp, viola! ftpd can drop privileges to those of the logged in user. Or even, just think, an annonymous-only server can run as the annonymous user _without ever needing root at all._ In either case, security bugs in the ftpd implementation, after the privilege drop, become non-privileged users executing arbitrary commands. For a server where users have a shell anyway, this is meaningless. It's not a good thing for ftp-only servers, but much better than getting root right off. For a system that is exclusively an FTP server, I think turning off privileged ports and running ftpd at lower privileges is pretty much a no-brainer. If someone can get execute code through ftpd to try to steal port 21/tcp, they would have already owned root if we hadn't lowered privileges. We're better off. On a shell server that has ftp enabled... you need to carefully evaluate the situation. If someone can impersonate the ftpd, it'd be a great way to steal passwords, no? I'm pleased with the response. Many enthusiastic ones, and the non-enthusiastic crowd seems content with the fact the default is to the classic behavior. I'd get cocky if it weren't for the fact there were maybe seven lines of code in the commit. Any committer who got so motivated coulda done it in a second. BTW: Coming soon, unless someone beats me to it, an option for ftpd that has it drop privs, for real, once the user logs in. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message