Click here for security advisories.
You should refer to the README file which has some informations on how to secure your Miredo installation, depending on the version of the program.
To mitigate risks in case a security breach were to be found, Miredo normally drops all privileges before handling any data from the network. Unless the default settings were changed at build-time, Miredo will automatically setgid, chroot and setuid at startup. That should effectively prevent possible privileges escalation and even execution of remote non-root shell (thanks to chroot). For increased security, you can also use grsecurity or similar patches against the Linux kernel. Miredo still has to be started by root.
Note: when Teredo client support is compiled-in (which is the default), chroot is disabled by default. Teredo client namely needs the DNS resolver library which can not run from within a chroot without specific non-portable setup. You can enable chroot manually, provided you setup the DNS resolver properly.
By default, Miredo uses the common
nobody unprivileged user
to run as, for ease of installation. It is not considered best security
practice, as some other programs may also be using the same user context.
Hence, it is recommended to create a separate Unix user account, with no
shell, to run miredo as. That is particularly important if you are
packaging the program for many people.
When run as a Teredo client, Miredo still needs network administration privileges when running. That is implemented with privilege separation : a separate process keeps root privileges with changing the tunnel network parameters as its only job. The process that handles network traffic cannot obtain root privileges directly. POSIX capabilities will additionnaly be used if the required library (for Linux, it’s in libcap) is found at build-time.
In case of remote compromise of the program, the attacker should, unfortunately, be able to blow up the IPv6 connectivity, but not much more.
Here is the list of official security advisories for Miredo in reverse chronological order. High priority is assigned to items that poses an immediate threat. Low priority is assigned to items that are difficult to exploit, or have a minor potential impact. Null priority refers to security advisories that are present only for reference to external vulnerability reports that are not considered to be problematic.