Security Considerations

This text has been written originally to persuade the Ubuntu people to move Avahi from "universe" to "main". Apparently it was successful.

  • Avahi properly drops priviliges, enforces resource limits and chroot()s itself. Needless to say this is much more than most programs currently available in Ubuntu/main do. Please note that to work properly in a chroot() environment avahi forks off a small helper daemon which lives outside the chroot(). It provides access to some static data files (notably DBUS introspection data) and to PID files. Communication between the main daemon and the helper daemon is limited to the minimum verbosity needed. We use single-byte commands to request an action from the helper daemon. In response a single byte is sent, possibly accompanied by a (read only) file descriptor. The chroot() process has four ways to contact the system outside the chroot(): firstly there's normal network access (port 5353, UDP), secondly there is the chroot helper process, thirdly there is the DBUS interface, and finally there is the UNIX socket which may be used to contact the NSS module.
  • All network input is validated before it is actually processed.
  • The same is true for the DBUS interface. In addition to the basic validation the DBUS library imposes by itself we validate all user arguments and provide an elaborate error reporting facility to report the exact failure cause back to the user
  • All error conditions are handled properly. We use a lot of asserts to make sure that everything works as intended.
  • Though Avahi is actually quite popular these days, we only had a single security sensitive bug. (And almost no other bugs.) The bug triggered an assert (i.e. it allowed a simple DoS attack) and could not be exploited in a way that code could be smuggled into the process.
  • The Avahi daemon aborts on OOM. However the client library deals with OOM situations properly and returns this as normal error code.
  • Fedora now moved Avahi from "extras" to "core", so i guess it is good enough for them. (BTW: they provide an SElinux policy file for avahi which can be used to make avahi even more secure)
  • Certainly, Avahi *will* have bugs, but I believe that it has a lot less bugs than many of the other software available in Ubuntu/main.
  • Please keep in mind that Avahi is mostly used in local area networks and that it ignores traffic from non-local networks.
  • We pass Apple's Bonjour conformance tests without exceptions (which includes a lot of tests to make sure that Avahi will not flood your network). Please note, however, that mDNS is not fully "flooding-proof". This is by design of the protocol and is justified by the Apple people with the fact that mDNS is not an internet protocol but a LAN protocol.
  • Much more security sensitive than Avahi is nss-mdns (which is loaded into every process using gethostbyname()). However, Avahi does not rely on nss-mdns to be useful. You might consider supporting Avahi but not nss-mdns for the near future. (Though nss-mdns is actually tiny in contrast to Avahi) Update: recent nss-mdns versions gained a new configure switch which allows it to be compiled without the small mini-mDNS implementation. If this is enabled it uses exclusively Avahi for resolving. Fedora uses it this way.
  • A dead Avahi daemon will not make the system unstable or vulnerable in any way (at least if all clients are written cleanly).
  • For more information, feel free to contact one of the Avahi developers

Lennart Poettering, December 2005

Addendum: Please read this:

Last modified 10 years ago Last modified on Jul 28, 2006, 1:26:33 PM