Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-24 Thread Hannes Gredler
On Wed, Jan 21, 2004 at 08:05:27AM +0200, Pekka Savola wrote:

[ ... ]

| Well, speaking as the one who made the patch in the first place, maybe
| 2-3 years ago, I did send it to this list a LONG time ago, but didn't
| bother re-sending too many times because there appeared to be very
| little interest in the patches.
| 
| As for why I went for "pcap" instead of nobody in the first place..  
| Red Hat bundles tcpdump with arpwatch, which I also coded to drop root
| privileges.  Picking a specific user name for these two purposes
| seemed only logical. (Arpwatch has to maintain a couple of files owned

valued tcpdump workers,

as you may have seem i have commited two patches from pekka that
provides the generic infrastructure for dropping root privileges as well
as a compile time option for specifying a user;

pls check out if the patches do what the majority of us needs
- if not pls let us know your suggested changes;

/hannes

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-23 Thread Andrew Pimlott
There is a new attempt at the end of this message.  I referred to
Wietse Venema's chrootuid as suggested.

One question with doing a chroot is what directory to chroot into.
sshd with privilege separation uses /var/run/sshd (on my Debian
system).  I considered assuming a /var/run/tcpdump directory or even
a generic /var/run/empty, but instead decided to create a new
temporary directory, since this requires less setup.  If others
would prefer a pre-determined directory, that's fine.

I observed that on Linux 2.4, I could mkdir, chdir, rmdir, chroot to
end up rooted in a non-existent directory.  This saves leaking
temporary directories (since we have no way of cleaning them up
after we chroot and setuid).  I suspect this is fairly portable.

There doesn't seem to be a good, portable C function for creating
temporary directories.  I try to honor TMPDIR then use /tmp, but
perhaps there are other conventions I should follow.  I used
mkdtemp, but I'm not sure how portable that is; it can be replaced
if needed.

I threw in a bunch of error checking.  I don't think the calls I
checked should ever fail on a normal unix system, so it's sort of a
judgement call whether to fail on that odd system where they do.  I
decided to err on the side of reporting errors for now.

I also took into account some of the comments in Jefferson's
message:

On Wed, Jan 21, 2004 at 10:45:31PM -0500, Jefferson Ogata wrote:
> Andrew Pimlott wrote:
> >I agree that a dedicated user is better.  However, I still think
> >that defaulting to nobody will protect people (to some degree) on
> >most systems, and I think the risk of nobody being a bad choice is
> >low (certainly it can't be worse than remaining root).  If nobody
> >doesn't exist, oh well.
> 
> You could also just pick an arbitrary numeric uid if nobody fails. So maybe 
> try getpwnam("pcap") first, then getpwnam("nobody"), then find a uid > 1024 
> that is unused for your last-ditch default.

This is going too far IMO.  If nobody doesn't exist, then the system
is sufficiently unusual that I don't think we should make any
guesses.  I also didn't try pcap first, because it seems to be
Redhat-specific.  If others think a pcap user should be generally
encouraged, I'm fine with adding it.

> >>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.
> >
> >This is important so that a setuid tcpdump (I can't imagine why
> >anyone would do that, but it seems to be supported in the code)
> >can't open root trace files, as mentioned in the existing comments.
> >I didn't change this from the old behavior.
> 
> But then how can root read his own trace file when it's mode 0600? I think 
> if ruid == euid you want to open the trace file before dropping privileges.

Duh, obviously right.  I separated drop_euid for opening the trace
file, from drop_privileges for dropping "all" privileges (for some
value of "all").

Andrew

--- tcpdump.c.orig  2003-12-17 20:22:57.0 -0500
+++ tcpdump.c   2004-01-23 20:04:01.0 -0500
@@ -57,6 +57,7 @@
 #endif /* WIN32 */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,12 @@
 
 int32_t thiszone;  /* seconds offset from gmt to local time */
 
+static uid_t euid;  /* for drop_euid, restore_euid */
+
 /* Forwards */
+static void drop_euid();
+static void restore_euid();
+static void drop_privileges();
 static RETSIGTYPE cleanup(int);
 static void usage(void) __attribute__((noreturn));
 static void show_dlts_and_exit(pcap_t *pd) __attribute__((noreturn));
@@ -617,20 +623,22 @@
if (RFileName != NULL) {
int dlt;
const char *dlt_name;
+   uid_t euid;
 
-#ifndef WIN32
/*
-* We don't need network access, so relinquish any set-UID
-* or set-GID privileges we have (if any).
-*
 * We do *not* want set-UID privileges when opening a
 * trace file, as that might let the user read other
 * people's trace files (especially if we're set-UID
 * root).
+*
+* Restore euid afterwards so that drop_privileges works.
 */
-   setuid(getuid());
-#endif /* WIN32 */
+   drop_euid();
pd = pcap_open_offline(RFileName, ebuf);
+   seteuid(euid);
+
+   drop_privileges();
+
if (pd == NULL)
error("%s", ebuf);
dlt = pcap_datalink(pd);
@@ -712,12 +720,8 @@
netmask = 0;
warning("%s", ebuf);
}
-   /*
-* Let user own process after socket has been

Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-21 Thread Jefferson Ogata
Ryan Mooney wrote:
Not really comments on the specific patch, or its applicability to the issue 
at hand.  

I'm a strong believer in defense in depth.
So then I assume you did "chmod -x /usr/bin/tcpdump"? :^)

Does a trench outside the wall 
stop all the attackers?  No, but it does slow them down, and gives you a 
chance to regroup.  
The problem with your metaphor is that there is no wall. Also, the trench is 
only 8 centimeters deep.

Anyway, if you're truly a believer in defense-in-depth, like me, you're not 
running protocol dissectors as root anyway, are you?

I've already agreed that dropping uid 0 helps. It just doesn't help very much, 
and I'm not sure it's worth the trouble if it's not done correctly. In our 
last episode we saw that the patch has yet to drop groups. On Red Hat, root's 
native groups include, for example, write access (as group disk) to all disk 
devices. Andrew said he's working to make it better, so, great.

I also advocated combining the uid drop with a chroot to an empty, unwritable 
directory. This would actually make a difference in that it would become 
significantly harder for an intruder to modify the system.

Dropping privileges from root stops a wide range of script kiddy type 
attacks from causing much much more damage than they would otherwise.  If 
you really don't believe in this, tell us where you run your web server 
and justify why its running it as root :)  I agree that this does not stop 
a determined and resourceful hacker, it will however slow them down and 
possibly encourage them to seak a softer target.  The primary source of most 
attacks I've seen lately are script kiddies, and if tcpdump was running as 
an unprivileged user it would limit the spread of damage on many systems 
(they would at least have to try a little).
The typical intrusion scenario these days has the intruder start by running 
"id". If this runs, the intruder will get a shell, and then try to get root 
with a local privilege escalation exploit. If this doesn't work, the intruder 
goes about his business as the regular user and waits for an opportunity to 
arise. So how much better off are you? How long is this guy going to run 
around on your system before you even know about it?

One more thing: the script kiddies won't typically target this vulnerability, 
since it only exists when someone is running tcpdump with a vulnerable 
protocol dissector. Script kiddies are much more interested in always-on 
vulnerabilities such as last year's apache chunked encoding vulnerability... 
and let's talk about that for a minute: how many thousands or tens of 
thousands of apache servers got nailed on that one? How about mod_ssl? This 
was a lot of damage, and the script kiddies weren't in the least disinclined 
to attack by the fact that apache wasn't running as root.

You want defense in depth? Start digging into the protocol dissectors and fix 
the buffer overflows. Now *that's* digging trenches.

--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-21 Thread Jefferson Ogata
Andrew Pimlott wrote:
On Tue, Jan 20, 2004 at 11:57:42PM -0500, Jefferson Ogata wrote:
But the unix
security model is based upon userids, so if you think access to an
unprivileged userid is "almost" the same as root, it seems
tantamount to calling unix security "useless".
Not useless, just runs a distant second to keeping the bozo off your system in 
the first place.

Anyway, can we at least agree that giving the attacker nobody is
a little better than giving him root?  :-)
Sure. That's perhaps a nicer way of saying what I said before: almost as bad. 
Half-empty/half-full, etc.

I agree that a dedicated user is better.  However, I still think
that defaulting to nobody will protect people (to some degree) on
most systems, and I think the risk of nobody being a bad choice is
low (certainly it can't be worse than remaining root).  If nobody
doesn't exist, oh well.
You could also just pick an arbitrary numeric uid if nobody fails. So maybe 
try getpwnam("pcap") first, then getpwnam("nobody"), then find a uid > 1024 
that is unused for your last-ditch default.

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.
This is important so that a setuid tcpdump (I can't imagine why
anyone would do that, but it seems to be supported in the code)
can't open root trace files, as mentioned in the existing comments.
I didn't change this from the old behavior.
But then how can root read his own trace file when it's mode 0600? I think if 
ruid == euid you want to open the trace file before dropping privileges.

--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-21 Thread Ryan Mooney

Not really comments on the specific patch, or its applicability to the issue 
at hand.  

I'm a strong believer in defense in depth.  Does a trench outside the wall 
stop all the attackers?  No, but it does slow them down, and gives you a 
chance to regroup.  

Dropping privileges from root stops a wide range of script kiddy type 
attacks from causing much much more damage than they would otherwise.  If 
you really don't believe in this, tell us where you run your web server 
and justify why its running it as root :)  I agree that this does not stop 
a determined and resourceful hacker, it will however slow them down and 
possibly encourage them to seak a softer target.  The primary source of most 
attacks I've seen lately are script kiddies, and if tcpdump was running as 
an unprivileged user it would limit the spread of damage on many systems 
(they would at least have to try a little).

Just my $0.02.

> 
> 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.
> 

-- 
>-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-<
Ryan Mooney  [EMAIL PROTECTED] 
<-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=-> 
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-21 Thread Pekka Savola
On Wed, 21 Jan 2004, Andrew Pimlott wrote:
> On Wed, Jan 21, 2004 at 08:05:27AM +0200, Pekka Savola wrote:
> > As for why I went for "pcap" instead of nobody in the first place..  
> > Red Hat bundles tcpdump with arpwatch, which I also coded to drop root
> > privileges.  Picking a specific user name for these two purposes
> > seemed only logical. (Arpwatch has to maintain a couple of files owned
> > by 'pcap' as well.)
> 
> I agree that picking a new user for this purpose is a sound choice.
> However, if this user owns files (especially ones that might be run
> or otherwise used by root), it seems to defeat the purpose.

The file (arp.dat) required to be writable by arpwatch is not 
executable, so this is not a big worry.

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-21 Thread Andrew Pimlott
On Wed, Jan 21, 2004 at 08:05:27AM +0200, Pekka Savola wrote:
> As for why I went for "pcap" instead of nobody in the first place..  
> Red Hat bundles tcpdump with arpwatch, which I also coded to drop root
> privileges.  Picking a specific user name for these two purposes
> seemed only logical. (Arpwatch has to maintain a couple of files owned
> by 'pcap' as well.)

I agree that picking a new user for this purpose is a sound choice.
However, if this user owns files (especially ones that might be run
or otherwise used by root), it seems to defeat the purpose.

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-21 Thread Andrew Pimlott
On Tue, Jan 20, 2004 at 11:57:42PM -0500, Jefferson Ogata wrote:
> 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.

Sorry, I interpreted that in the wrong direction.  But the unix
security model is based upon userids, so if you think access to an
unprivileged userid is "almost" the same as root, it seems
tantamount to calling unix security "useless".

Anyway, can we at least agree that giving the attacker nobody is
a little better than giving him root?  :-)

> Oh yeah, sorry, I got the semantics of setuid mixed up -- that came from 
> some of the older brain cells.

I don't blame you: there are so many variants of the call, and the
interaction between all the ids is hard to keep track of.  Which is
why I double check the man pages every time I use them.  :-)

> But you really need to handle groups. 

Yup, I realized this later.

> >>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.

I agree that a dedicated user is better.  However, I still think
that defaulting to nobody will protect people (to some degree) on
most systems, and I think the risk of nobody being a bad choice is
low (certainly it can't be worse than remaining root).  If nobody
doesn't exist, oh well.

> 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.

This is important so that a setuid tcpdump (I can't imagine why
anyone would do that, but it seems to be supported in the code)
can't open root trace files, as mentioned in the existing comments.
I didn't change this from the old behavior.

> 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.

I can't so I don't.  But at least if root uses -r, it will drop
privs.  I agree that the situation is imperfect, but I think the
change I'm suggesting can be done a long time before all tcpdump
protocol analyzers are redesigned to be robust.

> 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.

I'll look at Wietse Venema's code for this (thanks).  Of course, we
need to drop root as well, in which case we may as well still switch
to nobody.

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Pekka Savola
On Tue, 20 Jan 2004, Andrew Pimlott wrote:
> On Tue, Jan 20, 2004 at 06:31:08PM -0600, Earl Hood wrote:
> > I think so.  I just a posted a patch for dropping priviledges in a
> > similiar style that the RedHat port of tcpdump does.
> 
> This must be the RedHat that never sends their patches back
> upstream.  :-/

Well, speaking as the one who made the patch in the first place, maybe
2-3 years ago, I did send it to this list a LONG time ago, but didn't
bother re-sending too many times because there appeared to be very
little interest in the patches.

As for why I went for "pcap" instead of nobody in the first place..  
Red Hat bundles tcpdump with arpwatch, which I also coded to drop root
privileges.  Picking a specific user name for these two purposes
seemed only logical. (Arpwatch has to maintain a couple of files owned
by 'pcap' as well.)

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Jefferson Ogata
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 doe

Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Andrew Pimlott
On Tue, Jan 20, 2004 at 06:31:08PM -0600, Earl Hood wrote:
> I think so.  I just a posted a patch for dropping priviledges in a
> similiar style that the RedHat port of tcpdump does.

This must be the RedHat that never sends their patches back
upstream.  :-/

(I didn't see your patch because I just subscribed.)

> By default,
> it fallsback to the pcap userid, but you can also explicitly specify
> which user via a command-line option.

I don't know what the pcap user is for on RedHat, but I don't see
why you would change to pcap instead of nobody.  nobody is
essentially by definition the least empowered user on the system, so
isn't that the natural choice?

> The default user to fallback on should probably be a configure
> setting, but I did not mess with the autoconf stuff.

Me neither.  ;-)  But the advantage of defaulting to nobody is that
it will "just work" on most systems, and thus make more people safe
than any scheme that requires explicit activation by a user or
administrator.  I don't mind a configure setting or command-line
option to override the default, of course.

I also agree (as I said in my other message) with supporting
security mechanisms other than unix userid on systems that have
them.  Changing userid is just an easy first step.

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Andrew Pimlott
On Tue, Jan 20, 2004 at 07:20:13PM -0500, Jefferson Ogata wrote:
> Andrew Pimlott wrote:
> >Every once in a while there is a security alert about tcpdump being
> >hackable through one of the many protocol analyzers.  Couldn't these
> >be prevented simply by unconditionally dropping privileges as soon
> >as the interface is opened?
> 
> 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."

> >+/* Attempt to drop back to nobody.  This is safest. */
> >+nobody = getpwnam("nobody");
> >+if (nobody && nobody->pw_uid)
> >+setuid(nobody->pw_uid);
> >+/* If there is no nobody (?!), at least drop back to original uid */
> >+else
> >+setuid(getuid());
> 
> Your patch does not set euid.

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.

> Why do you think "nobody" is "safest"?

Because nobody is conventionally defined to be a user who owns no
files.

> Capabilities are a better approach 
> to this particular problem, since they make no assumption about what uid to 
> setuid to, and instead can grant the capture capability to a regular user.

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.

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.

> The real solution to the periodic dissector vulnerabilities is to devise an 
> abstract language and virtual machine which is provably safe for doing 
> protocol dissection. If this were done correctly, the virtual machine would 
> be BPF (or something better) and the same VM, compiler, and optimizer would 
> be used for protocol analysis as for filtering. And with a tiny bit more 
> cleverness, the dissector could work in reverse to construct the protocol 
> as well. The existing BPF bytecode would be able to do the vast majority of 
> protocol dissection, if only the compiler were a bit more generic. A 
> successor to BPF with a lot more registers and a mechanism for storing into 
> a non-register data structure would be ideal.

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

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Andrew Pimlott
On Tue, Jan 20, 2004 at 09:42:28PM -0500, Andrew Pimlott wrote:
> On Tue, Jan 20, 2004 at 06:31:08PM -0600, Earl Hood wrote:
> > By default,
> > it fallsback to the pcap userid, but you can also explicitly specify
> > which user via a command-line option.
> 
> I don't know what the pcap user is for on RedHat, but I don't see
> why you would change to pcap instead of nobody.

Well, I take that back, assuming that this is the only thing that
user pcap is for.  In that case, hijacked tcpdumps can't interfere
with daemons running as nobody.

Andrew
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Jefferson Ogata
Andrew Pimlott wrote:
Every once in a while there is a security alert about tcpdump being
hackable through one of the many protocol analyzers.  Couldn't these
be prevented simply by unconditionally dropping privileges as soon
as the interface is opened?
No, they couldn't. You'll still end up executing arbitrary code, and a user 
shell is almost as bad as a root shell.

+   /* Attempt to drop back to nobody.  This is safest. */
+   nobody = getpwnam("nobody");
+   if (nobody && nobody->pw_uid)
+   setuid(nobody->pw_uid);
+   /* If there is no nobody (?!), at least drop back to original uid */
+   else
+   setuid(getuid());
Your patch does not set euid. The user can trivially setuid back to superuser. 
You also aren't setting gid or egid.

Why do you think "nobody" is "safest"? Capabilities are a better approach to 
this particular problem, since they make no assumption about what uid to 
setuid to, and instead can grant the capture capability to a regular user.

The real solution to the periodic dissector vulnerabilities is to devise an 
abstract language and virtual machine which is provably safe for doing 
protocol dissection. If this were done correctly, the virtual machine would be 
BPF (or something better) and the same VM, compiler, and optimizer would be 
used for protocol analysis as for filtering. And with a tiny bit more 
cleverness, the dissector could work in reverse to construct the protocol as 
well. The existing BPF bytecode would be able to do the vast majority of 
protocol dissection, if only the compiler were a bit more generic. A successor 
to BPF with a lot more registers and a mechanism for storing into a 
non-register data structure would be ideal.

--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


Re: [tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Earl Hood
On January 20, 2004 at 17:40, Andrew Pimlott wrote:

> Every once in a while there is a security alert about tcpdump being
> hackable through one of the many protocol analyzers.  Couldn't these
> be prevented simply by unconditionally dropping privileges as soon
> as the interface is opened?
  [snip]

I think so.  I just a posted a patch for dropping priviledges in a
similiar style that the RedHat port of tcpdump does.  By default,
it fallsback to the pcap userid, but you can also explicitly specify
which user via a command-line option.

The default user to fallback on should probably be a configure
setting, but I did not mess with the autoconf stuff.

--ewh
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]


[tcpdump-workers] why doesn't tcpdump drop privileges?

2004-01-20 Thread Andrew Pimlott
Every once in a while there is a security alert about tcpdump being
hackable through one of the many protocol analyzers.  Couldn't these
be prevented simply by unconditionally dropping privileges as soon
as the interface is opened?

The following is a simple and briefly tested (on a Debian GNU/Linux
system) patch I wrote to do this.  I decided to try dropping back to
nobody (whether we were originally run by root or another user),
since this should give an attacker the least capacity for damage (at
least on a standard unix system).

Obviously, this could break anything that assumes we are running as
the original user later, but I can't imagine why anything would do
that.  If it is a problem, there can be a flag to disable this
patch, but I think the safest behavior should be the default.

Andrew

--- tcpdump.c.orig  2003-12-17 20:22:57.0 -0500
+++ tcpdump.c   2004-01-20 12:50:12.0 -0500
@@ -57,6 +57,7 @@
 #endif /* WIN32 */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -105,6 +106,7 @@
 int32_t thiszone;  /* seconds offset from gmt to local time */
 
 /* Forwards */
+static void drop_privileges();
 static RETSIGTYPE cleanup(int);
 static void usage(void) __attribute__((noreturn));
 static void show_dlts_and_exit(pcap_t *pd) __attribute__((noreturn));
@@ -618,7 +620,6 @@
int dlt;
const char *dlt_name;
 
-#ifndef WIN32
/*
 * We don't need network access, so relinquish any set-UID
 * or set-GID privileges we have (if any).
@@ -628,8 +629,8 @@
 * people's trace files (especially if we're set-UID
 * root).
 */
-   setuid(getuid());
-#endif /* WIN32 */
+drop_privileges();
+
pd = pcap_open_offline(RFileName, ebuf);
if (pd == NULL)
error("%s", ebuf);
@@ -712,12 +713,8 @@
netmask = 0;
warning("%s", ebuf);
}
-   /*
-* Let user own process after socket has been opened.
-*/
-#ifndef WIN32
-   setuid(getuid());
-#endif /* WIN32 */
+
+drop_privileges();
}
if (infile)
cmdbuf = read_infile(infile);
@@ -834,6 +831,26 @@
exit(status == -1 ? 1 : 0);
 }
 
+/*
+ * Since we are processing untrusted data, drop privileges to mitigate the
+ * risk due to bugs in analysis code.
+ */
+static void
+drop_privileges()
+{
+#ifndef WIN32
+   struct passwd *nobody;
+
+   /* Attempt to drop back to nobody.  This is safest. */
+   nobody = getpwnam("nobody");
+   if (nobody && nobody->pw_uid)
+   setuid(nobody->pw_uid);
+   /* If there is no nobody (?!), at least drop back to original uid */
+   else
+   setuid(getuid());
+#endif /* WIN32 */
+}
+
 /* make a clean exit on interrupts */
 static RETSIGTYPE
 cleanup(int signo _U_)
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]