[BACK]Return to SECURITY CVS log [TXT] [DIR] Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / mtr

Diff for /embedaddon/mtr/SECURITY between versions 1.1.1.1 and 1.1.1.3

version 1.1.1.1, 2013/07/21 23:43:42 version 1.1.1.3, 2019/10/21 14:25:31
Line 1 Line 1
 SECURITY ISSUES RELATED TO MTR  SECURITY ISSUES RELATED TO MTR
   
   mtr invokes a sub-process, mtr-packet, which requires extra privileges
   to send custom packets, and there are security implications from
   granting this.
   
   There are several different ways to provide the privileges:
   
   1. Add limited privileges on systems that support this. (Preferred.)
   2. Run mtr as the root user.
   3. Make mtr-packet a setuid-root binary.
   
   Details:
   
   1. Add limited privileges on systems that support this.
   
   Some operating systems allow binaries to be run with only the subset
   of security privileges that are actually needed.
   
   Linux:
   On Linux, privileges are known as capabilities. The only additional
   capability that mtr-packet needs is cap_net_raw. To give this
   capability to the mtr-packet binary, run the following command as root:
   
   # setcap cap_net_raw+ep mtr-packet
   
   
   2. Run mtr as the root user.
   
 You can limit mtr usage to the root user by not putting a setuid bit  You can limit mtr usage to the root user by not putting a setuid bit
on the mtr binary. In that case, the security implications areon the mtr-packet binary. In that case, the security implications are
minimal. minimal.
   
 Or you can make mtr setuid-root, and the following applies to you....  
   
Since mtr is installed as suid-root, some concern over security is3. Make mtr-packet a setuid-root binary.
justified.  Since version 0.21 of mtr, does the following two things 
after it is launched: 
   
*  mtr requests a pair of raw sockets from the kernel.  The mtr-packet binary can be made setuid-root, which is what "make install"
*  mtr sets the effective uid to match the real uid.does by default.
   
See main() in mtr.c and net_preopen() in net.c for the details of thisWhen mtr-packet is installed as suid-root, some concern over security is
process.  Note that no code from GTK+ or curses is executed before thejustified.  mtr-packet does the following two things after it is launched:
drop in permissions. 
   
This should severely limit the possibilities of using mtr to breach*  mtr-packet open sockets for sending raw packets and for receiving
system security.  This means the worst case scenerio is as follows:   ICMP packets.
 *  mtr-packet drops root privileges by setting the effective uid to
    match uid or the user calling mtr.
 *  If capabilities support is available, mtr-packet drops all privileged
    capabilities.
   
Due to some oversight in the mtr code, a malicious user is able toSee main() in packet.c and init_net_state_privileged() in probe_unix.c
overrun one of mtr's internal buffers with binary code that isfor the details of this process.
 
 This should limit the possibilities of using mtr to breach system security.
 The worst case scenario is as follows:
 
 Due to some oversight in the mtr-packet code, a malicious user is able to
 overrun one of mtr-packets's internal buffers with binary code that is
 eventually executed.  The malicious user is still not able to read  eventually executed.  The malicious user is still not able to read
from or write to any system files which they wouldn't normally havefrom or write to any system files other than those normally accessible
permission to write to.  The only priveledge gained is access to theby the user running mtr.  The only privileges gained are access to the raw
raw socket descriptors, which would allow the malicious user to listensocket, which would allow the malicious user to listen to all ICMP packets
to all ICMP packets arriving at the system, and send forged packetsarriving at the system, and to send forged packets with arbitrary contents.
with arbitrary contents. 
   
 The mtr-code does its best to prevent calling of external library  
 code before dropping privileges. It seems that C++ library code has   
 the ability to issue a "please execute me before calling main" to the  
 loader/linker.  That would mean that we're still vulnerable to   
 errors in that code. This is why I would prefer to drop the backends,   
 have mtr-core always run in "raw" mode, and have the backends interpret  
 the output from the mtr-core. Maybe a nice project for a college-level  
 student.   
   
 If you have further questions or comments about security issues,  If you have further questions or comments about security issues,
please direct them to the mtr mailing list.  See README for details.please see the README file for details on how to submit them.
Removed from v.1.1.1.1  
changed lines
  Added in v.1.1.1.3

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