Re: [tcpdump-workers] why doesn't tcpdump drop privileges?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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]