New ZeroConf Spec
iwj at ubuntu.com
Mon Jul 17 17:25:32 BST 2006
I suppose after my somewhat catty contributions earlier (sorry), I
should try to do something resembling a security review of mdns
service discovery for Ubuntu as described in
Like almost any new software, service, facility, protocol, or other
functionality, this plan increases the risks to the security of the
system. As with any deployment, these risks need to be weighed
against the benefits of the proposed change.
The main risks with ZeroConfPolicySpec as I see them are described
below, along with my recommendations for Ubuntu:
* avahi would be an additional piece of software exposed directly and
permanently to hostile network traffic initiated outside the
current host. Currently Ubuntu has very few such pieces of
software - pretty much, only the kernel is so exposed. The `no
open ports' policy is a good rule of thumb, intended to keep things
I have no clear idea about the complexity, implementation quality
and security record of avahi. The decision to deploy avahi in this
way should be made after a review of its size and history. The
discussion in ZeroConfPolicySpec is not particularly helpful for
this; the referenced avahi wiki page SecurityConsiderations  is
interesting, but we should make up our own mind.
Note that offering the user the choice between `keep your computer
secure' and `get your work done' is not IMO an acceptable answer to
difficult decisions of this kind. A user confronted by such a
choice is generally lacking in the knowledge and experience which
would allow them to make the tradeoff appropriately.
Furthermore, because this question (whether asked as a dialogue, or
arising from a request by someone to `turn on zeroconf') will occur
in the context of a particular task and there is a lot of evidence
(eg, try reading the literature about safety) to suggest that
people are very bad at making these kind of decisions in such a
* mdns service discovery's basic design is to allow all
`locally-connected' systems to determine amongst themselves which
names correspond to which services. (By its very design, it is
intended to put flexibility and convenience ahead of security.)
It is an explicit design goal that any machine can claim ownership
of any name in the mdns (*.local) namespace; preventing machines
from `masquerading' as each other is explictly excluded from the
With wired networks this is relatively safe in a small and
relatively trusted group but with the increasing prevalence of
wireless networking it will be difficult to exclude uninvited
guests from `participating'. Suitable link-layer authentication
and encryption could be used to mitigate this risk but there is no
description in the ZeroConfPolicySpec of anything of this kind.
So I conclude that many users who use avahi and mdns on wireless
networks, in the currently anticipated setup, will be unwittingly
opening themselves to `sharing' with anyone in the neighbourhood
(or of course anyone further away with a sufficiently good
This defect should be remedied before this spec is implemented.
* libnss-mdns is a new resolver library component which will process
replies from mdns servers. AIUI it listens on the network in
almost the same way as a normal resolver: that is to say, it
accepts network traffic when it has a query on the go, using a
port allocated by the kernel from the client range.
This introduces a new piece of security-critical software. We
should consider the size, history, and maintenance approach of
libnss-mdns. libresolv (which it's probably based on) has had a
somewhat chequered history, so this is not an entirely theoretical
* The expected user behaviour is to enable sharing of certain local
services - primarily, filesharing. We need to consider the whole
system and user behaviour implied by the use cases, rather than
just the mdns part.
The mechanisms for enabling sharing of these services need to be
clearly set out as part of the spec. For those services where
sharing is already possible via the UI, this should be stated. In
all cases the security implications should be considered.
The lack of information about this aspect of the setup is, I think,
a weakness which should be remedied before the spec is implemented.
More information about the ubuntu-devel