File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / mtr / SECURITY
Revision 1.1.1.2 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Nov 1 09:33:48 2016 UTC (7 years, 7 months ago) by misho
Branches: mtr, elwix, MAIN
CVS tags: v0_86, HEAD
mtr 0.86

    1: SECURITY ISSUES RELATED TO MTR
    2: 
    3: You can limit mtr usage to the root user by not putting a setuid bit
    4: on the mtr binary. In that case, the security implications are
    5: minimal. 
    6: 
    7: Or you can make mtr setuid-root, and the following applies to you....
    8: 
    9: Since mtr is installed as suid-root, some concern over security is
   10: justified.  Since version 0.21, mtr does the following two things
   11: after it is launched:
   12: 
   13: *  mtr requests a pair of raw sockets from the kernel.  
   14: *  mtr drops root privileges by setting the effective uid to match
   15:    uid or the user calling mtr.
   16: 
   17: See main() in mtr.c and net_preopen() in net.c for the details of this
   18: process.  Note that no code from GTK+ or curses is executed before
   19: dropping root privileges.
   20: 
   21: This should severely limit the possibilities of using mtr to breach
   22: system security.  This means the worst case scenerio is as follows:
   23: 
   24: Due to some oversight in the mtr code, a malicious user is able to
   25: overrun one of mtr's internal buffers with binary code that is
   26: eventually executed.  The malicious user is still not able to read
   27: from or write to any system files which they wouldn't normally have
   28: permission to read or write to, repectively.  The only privilege
   29: gained is access to the raw socket descriptors, which would allow
   30: the malicious user to listen to all ICMP packets arriving at the
   31: system, and to send forged packets with arbitrary contents.
   32: 
   33: The mtr-code does its best to prevent calling of external library
   34: code before dropping privileges. It seems that C++ library code has 
   35: the ability to issue a "please execute me before calling main" to the
   36: loader/linker.  That would mean that we're still vulnerable to 
   37: errors in that code. This is why I would prefer to drop the backends, 
   38: have mtr-core always run in "raw" mode, and have the backends interpret
   39: the output from the mtr-core. Maybe a nice project for a college-level
   40: student.
   41: 
   42: If you have further questions or comments about security issues,
   43: please direct them to the mtr mailing list.  See README for details.

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>