LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityUsing vulnerabilities instead of new lawsA paper presented at the Privacy Law Scholars Conference in June asks an interesting question: what are the implications of allowing law enforcement to use existing vulnerabilities to wiretap the internet? In some sense, current events have outrun the paper's focus as we now know that the NSA has been using vulnerabilities in its quest for every last bit of internet traffic, but there are legitimate questions raised by the paper. If, someday, the US returns to the idea of actual oversight of domestic (at least) internet surveillance, it will be worth considering the tradeoffs described in the paper. The paper starts by pointing out that critics of the Communications Assistance for Law Enforcement Act (CALEA), which mandated wiretap-friendly interfaces for telephony equipment, were fully justified by later events. Those interfaces were illegally used in a number of different ways, including wiretapping a large number of Greek politicians in 2005. Extending CALEA to the internet, which is something the FBI has been advocating, will predictably lead to similar abuses, so it is worthwhile to look at alternatives. The authors, Steven M. Bellovin, Matt Blaze, Sandy Clark, and Susan Landau, instead propose that the FBI be authorized to use existing vulnerabilities for wiretapping. Rather than requiring vendors to insert vulnerabilities into their code so that the FBI can wiretap voice-over-IP (VoIP) and other communications, just recognize that there are already vulnerabilities available that allow the required access. But, there are a number of consequences—along with ethical questions—that stem from allowing that behavior. The wide-ranging paper covers a lot of ground. Some of the more interesting technical discussion has to do with vulnerabilities themselves. The authors' argument, essentially, is that there will always be vulnerabilities available that will allow the capabilities needed by law enforcement. It is simply a matter of finding or obtaining them, then using them against the target for whom a warrant has been issued. Even if a CALEA-style law were passed for internet communications, they argue, there would still be a need for vulnerability-based wiretapping. There is existing software that doesn't implement the interfaces and targets may be using end-to-end encryption, for example. But in order to gain access to the "right" vulnerabilities for the target (which would need to be determined by some kind of "technical reconnaissance"), the FBI would need to access the vulnerability "black market". Since the goal of wiretapping is different than that of typical attackers, any exploit would likely need to be modified to have a "wiretapping payload" rather than the usual spambot, remote-access, or credential-stealing payloads. There is, in short, quite a bit of work that would need to be done before bits of VoIP data start flowing to the cops. From what we know now, it would be far easier to just ask the NSA. But, assuming the NSA option closes down at some point, the ethical dilemmas surrounding this whole idea still pose some significant hurdles. For example, if the FBI knows about a highly useful vulnerability that is also being exploited by botnet herders or other criminals, will it report the hole? Or if a company is about to release an update that closes a hole being actively used, will pressure be applied to delay (or subvert) the release? How does the FBI ensure that its wiretapping tools aren't disseminated to the underworld? There are, of course, plenty more questions beyond just those. Overall, it is an interesting quandary. On the one hand, routing around a "CALEA for the internet" is certainly attractive. The harm to both innovation and privacy that could be caused by such legislation is huge. On the other hand, though, turning the FBI and other law enforcement organizations into players on the malware stage has its own set of dangers. The authors conclude that those dangers (or "uncomfortable issues" as they call them) are less of a concern than the legislative solution. Unfortunately for all of us, legislators and law enforcement rarely grasp the idea that there might be solutions outside of new laws. In fact, the NSA revelations may have shown an entirely different way to operate without any new laws.
Brief items Security quotes of the week
In other circumstances I also found situations where NSA employees
explicitly lied to standards committees, such as that for cellphone
encryption, telling them that if they merely debated an
actually-secure protocol, they would be violating the export control
laws unless they excluded all foreigners from the room (in an
international standards committee!). The resulting paralysis is how
we ended up with encryption designed by a clueless Motorola employee
-- and kept secret for years, again due to bad NSA export control
advice, in order to hide its obvious flaws -- that basically XOR'd
each voice packet with the same bit string!
— John
Gilmore
So, in pointing to implementation vulnerabilities as the most likely
possibility for an NSA "breakthrough," I might have actually erred a bit
too far on the side of technological interestingness. It seems that a
large part of what the NSA has been doing has simply been strong-arming
Internet companies and standards bodies into giving it backdoors. To put
it bluntly: sure, if it wants to, the NSA can probably read your email.
But that isn't mathematical cryptography's fault—any more than it
would be
mathematical crypto's fault if goons broke into your house and carted away
your laptop. On the contrary, properly-implemented, backdoor-less strong
crypto is something that apparently scares the NSA enough that they go to
some lengths to keep it from being widely used.
— Scott Aaronson
Government and industry have betrayed the internet, and us.
— Bruce
Schneier issues a call to action
By subverting the internet at every level to make it a vast, multi-layered and robust surveillance platform, the NSA has undermined a fundamental social contract. The companies that build and manage our internet infrastructure, the companies that create and sell us our hardware and software, or the companies that host our data: we can no longer trust them to be ethical internet stewards. This is not the internet the world needs, or the internet its creators envisioned. We need to take it back.
[Wickr's Nico] Sell has yet to receive a secret order, so she can legally report in each transparency report: "Wickr has received zero secret orders from law enforcement and spy agencies. Watch closely for this notice to disappear." When the day came that her service had been served by the NSA, she could provide an alert to attentive users (and, more realistically, journalists) who would spread the word. Wickr is designed so that it knows nothing about its users' communications, so an NSA order would presumably leave its utility intact, but notice that the service had been subjected to an order would be a useful signal to users of other, related services.
— Cory
Doctorow suggests a "dead man's switch"
Roeckx: State of encryptionOn his blog, Kurt Roeckx rounds up the current state of encryption, especially as it relates to Secure Sockets Layer/Transport Layer Security (SSL/TLS). He looks at key lengths, techniques (like Diffie-Hellman for perfect forward security), ciphers, random numbers, and existing software, showing where the likely vulnerabilities lie. "A lot of the algorithms depend on good random numbers. That is that the attacker can't guess what a (likely) random number you've selected. There have been many cases of bad RNG [random number generator] that then resulted in things getting broken. It's hard to tell from the output of most random number generators that they are secure or not. One important thing is that the RNGs gets seeded with random information (entropy) to begin with. If it gets no random information, very limited amount of possible inputs or information that is guessable as input it can appear to give random numbers, but they end up being predictable There have been many cases where this was broken."
New vulnerabilities exactimage: denial of service
fedora-business-cards: insecure temporary file usage
gdm: privilege escalation
kernel: code execution
kernel: denial of service
LibRaw: denial of service
phpbb3: file overwrites
python-django: directory traversal
subversion: privilege escalation
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||