Date: Fri, 21 Feb 2003 11:15:28 -0800 From: "Crist J. Clark" <crist.clark@attbi.com> To: "M. Warner Losh" <imp@bsdimp.com> 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> In-Reply-To: <20030221.062059.34122968.imp@bsdimp.com> References: <200302210528.h1L5SS0H092948@repoman.freebsd.org> <20030221131205.GE30966@sunbay.com> <20030221.062059.34122968.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030221191528.GC90209>