mtr/SECURITY

SECURITY ISSUES RELATED TO MTR

mtr 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 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 needs is cap_net_raw. To give this capability
to the mtr binary, run the following command as root:

# setcap cap_net_raw+ep mtr


2. Run mtr as the root user.

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


3. Make mtr a setuid-root binary.

The mtr binary can be made setuid-root, which is what "make install"
does by default.

When mtr is installed as suid-root, some concern over security is
justified.  Since version 0.21, mtr does the following two things
after it is launched:

*  mtr requests a pair of raw sockets from the kernel.  
*  mtr drops root privileges by setting the effective uid to match
   uid or the user calling mtr.

See main() in mtr.c and net_preopen() in net.c for the details of this
process.  Note that no code from GTK+ or curses is executed before
dropping root privileges.

This should severely limit the possibilities of using mtr to breach
system security.  This means the worst case scenario is as follows:

Due to some oversight in the mtr code, a malicious user is able to
overrun one of mtr's internal buffers with binary code that is
eventually executed.  The malicious user is still not able to read
from or write to any system files which they wouldn't normally have
permission to read or write to, respectively.  The only privilege
gained is access to the raw socket descriptors, which would allow
the malicious user to listen to all ICMP packets arriving at the
system, and to send forged packets 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,
please see the README file for details on how to submit them.