[unisog] Bonjour Sleep Proxy Server issues (was: Mac OS X 10.6 workstation stole the IP address of another device, Apple Time Capsules too)

Irwin Tillman irwin at princeton.edu
Wed Sep 16 02:17:49 GMT 2009


Another update:

Our institution has now seen a number of additional incidents.

The devices that have stolen IP addresses in this way have included Apple Time
Capsules, an Apple AirPort Express or Extreme Base Station (model not clear),
and a number of Mac OS X 10.6 workstations.

All the victims to-date have been Mac OS X workstations. (In the cases where I
was able to obtain version information from the owner, I've seen that the
workstations were running Mac OS X 10.6.)

I see that the updated version of http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
(version -08 dated September 10 2009) now documents that this is in fact the way
that a Bonjour Sleep Proxy Server is intended to behave. That is, section 17 of
that document states that a Sleep Proxy Server does indeed take over the IP
address of the Sleep Proxy client.

So I understand that the incidents we are seeing is in fact due to the intended
behavior of the Sleep Proxy Server.

( I note that in a number of the incidents I have seen, the devices that stole the IP addresses
-- the device acting as a Sleep Proxy Server -- were workstations running Mac OS X 10.6.
So despite what http://support.apple.com/kb/HT3774 says about which Apple devices can
act as Sleep Proxy Servers, it seems to me that Mac OS X 10.6 *can* act as a
Sleep Proxy Server, at least under some circumstances. )


I have revised the bug report I filed with Apple, to indicate
that these are my issues with the behavior of the Sleep Proxy Server:


1) I'm unhappy with the fact that a Sleep Proxy Server takes over the IP address
of a Sleep Proxy client (it claims the IP address via ARP, and sends packets
with the client's IP source address), because it makes managing an enterprise
IP network harder.

One of the most effective tools I have for detecting problems with our
institution's IP network is automated reviewing of our IP routers' IP ARP caches to
locate devices (identified by hardware address) using IP addresses they are not
assigned to use.  This allows us to detect a wide variety of problems,
from accidentally and deliberately misconfigured machines, to malware
stealing large blocks of addresses.
 
The behavior of the Sleep Proxy Server makes this infeasible.

Also, our institution is often required to identify what hardware address was
using an IP address at a particular time. Sometimes this is for legal reasons,
say, prompted by reports of copyright violation. Now some of those incidents
will be tagged as being the fault of the person responsible for the Sleep
Proxy Server (rather than the sleeping client), because the Sleep Proxy Server
had taken over or relinquished the IP address close to the time of the
incident. It's bad because the Sleep Proxy Server (or really, the person
responsible for the device running the Sleep Proxy Server) gets blamed for the
incident, and also bad because that person never had any intention of running
a Sleep Proxy Server.

>From my point of view, the device acting as a Sleep Proxy Server was assigned to
use one IP address, yet the behavior of the Sleep Proxy Server results in this
device using other IP addresses as well. Without the Sleep Proxy Server present,
daily review of the IP ARP cache data reveals a number of anomalies -- problems
(such as devices configured to steal another's IP address) that need to be
diagnosed and corrected. But finding those anomalies becomes impractical once
there are Sleep Proxy Servers on the network. Our network has 20-30K network
interfaces attached during the course of a day. Even with just a hundred or so
Sleep Proxy Servers (say, just the Time Capsules and AirPort Base Stations), the
number of anomalies to handle each day becomes impractical. Spotting the anomalies that
*aren't* due to Sleep Proxy Servers is no longer feasible.




2) If the IP address was assigned to a client via DHCP, is it really
appropriate for the client to temporarily "transfer" this IP address to
another device? Put another way, is a DHCP lease transferrable?

I've always viewed a DHCP lease as something a DHCP server awards to a DHCP
client. The client can use the lease, renew it, or release it, but it can't give
it to someone else (even temporarily). I don't feel the DHCP lease includes the right
to (temporarily) transfer the leased IP address to another device.




3) Is it easy for an attacker on the same IP network as the Sleep Proxy Server
to leverage the Sleep Proxy Server behavior to force the Server
to participate in a Denial of Service attack?

That is, say an attacker on the same subnet as the Sleep Proxy Server
sends the Server a message telling it to take over the IP address of some victim
(on the same network) for some time period.  Perhaps the attacker send messages telling
the Sleep Proxy Server to take over every IP address on the network,
or just the address of the network's IP router.

Or does the protocol include measures that make this sort of attack
impractical?




4) I feel that any Sleep Proxy Server implemenation (e.g. in the Apple Time
Capsule, AirPort Base Station, Mac OS X 10.6, and any platform on which it is
implemented) must have an "on/off" switch, to allow the owner of the device to
cause the device to *not* act as a Sleep Proxy Server.

That's in keeping with a general philosophy that if own the device, I should be
able to turn on and off the various (optional) services that the device offers
to the network.

Just as my Mac has an on/off switch for whether or not it acts as a file server
to the network, I would think that if my device is capable of acting as a Sleep
Proxy Server for the network, I should be able to turn that on or off. Otherwise
you are (in effect) saying "If you attach your Time Capsule to the network,
we're going to force you to offer Sleep Proxy Service to the network."

In addition to providing the user with a way to disable the Sleep Proxy Server
functionality, I think that the default setting should be that the
Sleep Proxy Server is disabled.

That default is in keeping with a philosophy that my device shouldn't offer a
service to the network without my explicitly telling it to do so. I don't expect
a modern OS or appliance to (by default) act as an FTP server, TFTP server, SMTP
server, TELNET server, file server, etc. I expect such services to be disabled
by default; the owner of the device must enable the services s/he wishes to
offer to the network. Offering services to the network by default (without the
owner explicitly turning on the service) harkens back to the bad old days, when
OS's were shipped "insecure by default."

I would like to see Apple add an "enable/disable the Sleep Proxy Server" setting
to the user interface of each of the products that is capable of acting as a
Sleep Proxy Server, and have that setting default to the Sleep Proxy Server
being disabled. And I'd also like to see this be added as a requirement to the
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
specification, so that other vendors who implement Sleep Proxy Servers could be
expected to do the same thing.

(One exception, I imagine, would be for a product that is intended to function
solely as a Sleep Proxy Server. If someone were to ship an appliance or a
program that acts solely as a Sleep Proxy Server, it wouldn't need such an
on/off control, as presumably the person deploying that product did intend for the
product to act as a Sleep Proxy Server to the network.)




/Irwin Tillman
OIT Network Systems, Princeton University


More information about the unisog mailing list