On Thu, Jul 24, 2008 at 9:37 AM, Alexander Dupuy <[EMAIL PROTECTED]> wrote: > Andrew Edgecombe wrote: > >> > Why not set the suid bit on the tcpreplay executable? >> > eg. >> > sudo chmod a+s /usr/local/bin/tcpreplay >> > >> > or am I missing something? >> > > Aaron Turner replied: >> Uh. Nope, you're not missing anything. Better solution actually. > > Given that tcpreplay doesn't drop setuid after opening the replay > interface(s), making tcpreplay setuid root is rather a poor idea, I > would say (although still better than some of the alternatives). While > I haven't seen any direct way that the arguments to tcpreplay could be > used to overwrite /etc/passwd, it certainly would be possible to tell > tcpreplay to read packets from /etc/shadow or other files that are > supposed to be read only by root. Of course, reading such packets isn't > likely to work very well, but it might work well enough for somebody to > get access to the contents.
Theoretically possible I suppose, but you'd have to install tcpreplay using shared libs, and write your own libpcap which won't immediately abort when opening a non-pcap formatted file. suid root binaries that aren't statically linked is really REALLY stupid. Anyways, running tcpreplay suid is better then creating extra userid = 0 accounts on the box IMHO. YMMV and all the standard disclaimers apply. Using sudo is better still since you can have more control. > Given that this sort of thing is likely to come up again on different > systems, it's probably not a bad idea to have tcpreplay call > seteuid(getuid()) after it opens the output interfaces (and before it > opens the input files) to minimize the possible harm if somebody does > make it setuid root. It definitely should not be installed setuid root > by default, but there will surely be some who want to do this. (Note > that this protection is useful even with sudo as well, since sudo may > not protect against passing /etc/shadow or other read-only-by-root > files, depending on how it is set up). I wrote this w/ a buddy a long time ago: http://synfin.net/papers/nmap-suid.txt explaining why not to suid nmap, since you actually could use it to edit /etc/passwd to create a valid user account with userid = 0 and a password of your choice. So yeah, stuff like this is possible with all sorts of tools. :) Anyways, tcpreplay does not ship suid and I don't recommend anyone do that. I make no promises of tcpreplay's security since I haven't audited the code for that. That being said, I'm pretty careful about making common security mistakes (double free()'s, always checking the error code of malloc(), avoiding buffer overflows, integer overflows, etc) and I'm not aware of any bugs which might possibly lead to any security risk. Frankly, I wouldn't recommend giving anyone you don't trust enough to give the root password access to run tcpreplay on your box. Allowing untrusted persons/scripts to inject random packets onto your network is just asking for trouble. I probably won't ever drop privs in tcpreplay just because that means I'd have to audit all the argument processing code which is in GNU Autogen to make sure I wasn't creating a false sense of security. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
