LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityPicking a MAC address for a FreedomBoxThe FreedomBox project is working toward the creation of an inexpensive, in-home device that can be used for secure and private communications. The initial plan is to create a version of the Debian distribution that can be installed on a device like the DreamPlug; the resulting configuration should "just work" for nontechnical users in potentially hostile situations. The project has many challenges to overcome, one of which — the choice of MAC address for the network interface — shows how tricky this problem space can be.An interface's MAC address is a unique number identifying the interface to any other devices it may communicate directly with. Ethernet-style MAC addresses are six-byte quantities; half of those bytes identify the manufacturer while the other half are meant to be a unique serial number. The MAC address for the Ethernet interface on the system where this article being typed is:
18:03:73:be:76:4a
This MAC address identifies the relevant system as having been manufactured by Dell. If Dell has done its job properly (and there is no evidence to the contrary), no other Ethernet interface on the planet should have that same MAC address. FreedomBox developer Nick Daly recently started pondering the question of how a FreedomBox should set its MAC address. The hardware will come with an address provided by the manufacturer, of course, but that address can be changed by the kernel and there may well be good reasons for doing so. Many of those were outlined in this lengthy message from John Gilmore, which is well worth reading in its entirety; it forms the basis of this summary. One obvious problem is that a static MAC address is a unique number identifying a particular system. Most interfaces never operate with anything but the vendor-supplied address; if a hostile party learns that address, they can quickly identify the system it belongs to. So, while a FreedomBox device might move around, a suitably informed observer will always know which device it is. That allows the correlation of activities over time and the monitoring of specific devices. Current technologies make things worse. Quoting John:
Apple iPhones record the MAC addresses that are nearby, report
these to Apple, and Apple uses them to return a physical position
fix. This is used to more rapidly cause the GPS algorithm to
converge on a position, and also used when GPS isn't working. The
phones often report their GPS position and any nearby MAC addresses
back to Apple servers... It's easy for hackers to query that
database of MAC addresses and locations, by pretending to be an
iPhone seeking its location.
In other words, a hostile entity might not have to drive around a city in an attempt to detect a device with a specific MAC address; instead, it is just a matter of asking Apple, which has a widespread surveillance network in place and can simply say where that device is to be found. Similar information is maintained by other parties — Google, for example. John also pointed out that it is often trivial to determine which IP address is assigned to a device; it is often just a matter of sending a DNS query to the MAC address of interest. That can enable the identification of the location from which specific network activity has been generated. Finally, there is the matter of that manufacturer identification number found in every MAC address. If FreedomBox becomes a widely used and effective system, certain authorities might develop a strong interest in knowing where DreamPlug systems are to be found. The identifying information found in the MAC address makes that identification a relatively simple task. Turning on a DreamPlug could be a way of painting a target on a specific location — not the sort of dream the owner may have been looking for. The obvious conclusion is that FreedomBox systems should not normally run with the default MAC address provided by the vendor. They should, instead, generate a new address, and that address should be changed frequently. Fortunately, much of this is easy to do; any even remotely contemporary hardware will allow the host system to provide a new MAC address, and the data link layer (and above) protocols are pretty good about responding to MAC address changes. So there is no obvious technical barrier preventing frequent changing of a system's MAC address. But there is still the question of what that address should be. Nick had suggested defaulting to 00:00:00:00:00:00 by default, a choice that would clearly prevent the identification of specific FreedomBoxes. But there are problems with that choice, starting with the fact that confusion would result as soon as two FreedomBoxes appeared on the same network. So something a little smarter is needed. One obvious possibility is to simply generate a six-byte random number and use that. Care would have to be taken to avoid MAC address collisions on any given net, but that is not a particularly hard problem to solve. There are also the usual issues with having enough entropy available to generate a proper random number at boot time; without an adequate level of care, that random address might be far less random than people expect. Once again, that is a problem that should be amenable to a proper solution. But, as John pointed out, there is another problem: real-world MAC addresses follow a specific pattern; a random address, being unlikely to fit that pattern, would probably stand out like a neon sign to anybody who is looking for it. To be convincing, a system-chosen MAC address cannot be completely random. It should have a recognized manufacturer number, preferably a manufacturer that actually makes contemporary wireless network interfaces. The serial number also needs to fit into a range that was actually shipped by that manufacturer. In other words, a random MAC address will only blend in if it makes the device look like some other random piece of real-world hardware. These problems are all tractable, but the solution requires a great deal of due care if it is not to expose its users to unwanted consequences. Indeed, the whole system must be designed and implemented with that level of care; that is part of why the FreedomBox has not come to fruition as quickly as many would have liked. Privacy is a surprisingly difficult problem, with many pitfalls for those who try for a quick solution.
Brief items Security quotes of the week
My computer was arrested before me
-- Syrian protester Dr. Taymour Karim
… the FBI has access to … the
emails of virtually everybody in the country. -- NSA whistle-blower
William
Binney, interviewed on RT.com
Jellyfish are interesting to trojan writers. Deep at their heart they
are colony creatures, with stealth capabilities. What could be more
pertinent to those of us who feed on the world's information like
opportunistic predators?
-- Dave Aitel
Right now my feeling is that the world has been lucky because most of the malicious software on the internet has been, at worst, a rapscallion, or a scofflaw, or perhaps a ne'er-do-well. And there are modern networks who fare pretty well against that kind of adversary. But longer term, there's going to be malware that resembles science fiction <http://www.immunityinc.com/downloads/TheLongRun.pdf>...or maybe jellyfish? :>
These companies own us, so they can sell us off
-- again, like serfs -- to rival lords... or turn us in to
the authorities. -- Bruce
Schneier
New vulnerabilities apache2: denial of service
claws-mail: user credential leak
firefox: multiple vulnerabilities
kernel: information leak
kernel: privilege escalation
keystone: multiple vulnerabilities
libxml2: code execution
lynx: multiple vulnerabilities
mod_security: multipart/invalid part ruleset bypass
mysql: code execution
perl: code execution
Page editor: Michael Kerrisk |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||