Re: why doesn't tcpdump drop privileges?

[Jefferson Ogata <Jefferson.Ogata () noaa gov>]

Andrew Pimlott wrote:
> On Tue, Jan 20, 2004 at 07:20:13PM -0500, Jefferson Ogata wrote:
> > Andrew Pimlott wrote:
> > No, they couldn't. You'll still end up executing arbitrary code, and a user 
> > shell is almost as bad as a root shell.
>
> *boggle*
>
> No offense, but you seem to have a very academic view of security.
> "The unix security model is ugly, therefore it is useless."

No offense taken, but my view is extremely practical, as I handle compromises 
all the time. Also, I don't find the UNIX security model ugly or useless; I'm 
not sure where you got that. I do know that privilege escalation vulnerabilities 
continue to be discovered in pretty much all UNIX and UNIX-like systems.

Let me put it a different way, by stating two cases where someone compromises 
your box by transmitting packets past your tcpdump that exercise a bug in a 
protocol dissector:

1. user not on my system -> user running arbitrary code on my system as regular 
user.

2. user not on my system -> user running arbitrary code on my system as root.

The big difference here was between "user not on my system" and "user running 
arbitrary code on my system". What user the code is running as once you get to 
that point is relatively unimportant, and on most systems it won't take the user 
long to get root. Yes, if you have a well configured and patched system, and 
practice good sysadmin hygiene, the separation will be strong, but I'm talking 
about the majority of systems. And even if you keep the user from getting root, 
most intruders are quite happy to get a user shell -- they don't need root to 
set up an IRC bot or use your box as a springboard to attack someone else. 
That's why, *practically* speaking, the difference between root and joe user is 
not that big when it comes to intrusions: what we want is to keep the potential 
intruder *off* the system, period.

> I coded according to the documentation on my system:
>
>     setuid  sets  the  effective  user  ID  of the current process.  If the
>     effective userid of the caller is root, the real and  saved  user  ID's
>     are also set.
>
> Are you saying this is wrong?  If so, the old code is just as
> broken.

Oh yeah, sorry, I got the semantics of setuid mixed up -- that came from some of 
the older brain cells. But you really need to handle groups. There's not much 
point in giving up uid 0 if you still have all of root's groups. The bottom line 
is: it's not good to play with setuid() and its kin if don't really know what 
you're doing; it's like knowing a little bit about plumbing. I believe Wietse 
Venema has a little C program for doing combined chroot/setuid which should 
cover all the bases properly. Track that down and work from there.

> > Why do you think "nobody" is "safest"?
>
> Because nobody is conventionally defined to be a user who owns no
> files.

Better not to assume that. Files often end up belonging to nobody, especially in 
NFS environments. Furthermore, there might not be a nobody, especially if you 
chroot.

Where I was going was that if you're going to do it this way, make the user 
specify what uid to run as. Don't assume nobody is okay. As suggested by others, 
if you have a dedicated user you're in better shape.

> First, capabilities are potentially a much better approach, but I
> didn't want to think of coding that portably, especially in a trial
> patch.  Second, even if my userid can be given a capture capability,
> I still don't want to give an attacker access to my personal data if
> there is a bug in tcpdump.

There's a big problem domain you're not fully treating, which is what happens 
when one process captures and writes to a pcap file, and someone else comes 
along and runs a protocol dissector on the saved file later. First, your patch 
is dropping privileges before opening the pcap file, which looks out of order to 
me. Second, you can't protect an ordinary user from compromising himself and 
exposing his "personal data" using "tcpdump -r" on a bogus pcap file because 
that user can't setuid to the "safe" user.

> This is about running with the lowest lever of privilege possible.
> One part of that is dropping access to all files.  "nobody" is the
> best way to do this that will work on a wide range of systems.  I'd
> love to go further (deny the ability to create sockets, etc), but
> there's no portable way.

If you want to drop access to all files, chroot to an empty directory, then 
setuid to a user that can't write to the directory. Then, for good measure, 
rmdir the directory.

> You can go do a PhD thesis on this if you want, but I'm interested
> in making simple but useful changes.  :-)

I'm back to my original point, which is that the hard part of a compromise is 
getting some of your code to run on the system. After that, getting root is 
typically not that hard. The recurring problems in protocol dissectors keep 
solving the hard problem -- run arbitrary code on the system -- and there's not 
much you can do to prevent that. What you're trying to do helps mitigate the 
easy part, but that doesn't do anything to make tcpdump actually safe to run.

Going practical again: I don't use the protocol dissectors in tcpdump as root, 
anyway, because I can't trust them. I usually capture as root with "-w" and use 
tcpdump or ethereal as a regular user to examine the data. I don't need tcpdump 
to setuid for me -- I do it myself as a matter of hygiene -- and even then I'm 
quite uncomfortable if I'm dissecting anything unusual.

What needs to happen to address the problem is that either the authors of the 
bogus protocol dissectors get their heads out of their butts and start writing 
correct code, or the model for protocol dissectors change to protect us from bad 
coders. I advocate the latter, and I think libpcap in general could become a 
much better piece of code if that direction were followed in earnest.

--
Jefferson Ogata <Jefferson.Ogata () noaa gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt () noaa gov>

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe