By Jake Edge
September 11, 2013
A 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.
Comments (12 posted)
Brief items
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.
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.
—
Bruce
Schneier issues a call to action
[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"
Comments (19 posted)
On 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."
Comments (21 posted)
New vulnerabilities
exactimage: denial of service
| Package(s): | exactimage |
CVE #(s): | CVE-2013-1441
|
| Created: | September 11, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Debian advisory:
It was discovered that exactimage, a fast image processing library,
does not correctly handle error conditions of the embedded copy of
dcraw. This could result in a crash or other behaviour in an
application using the library due to an uninitialized variable being
passed to longjmp. |
| Alerts: |
|
Comments (none posted)
fedora-business-cards: insecure temporary file usage
| Package(s): | fedora-business-cards |
CVE #(s): | CVE-2013-0159
|
| Created: | September 10, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Red Hat bugzilla:
Michael Scherer reported that the fedora-business-cards script used /tmp/fedora-business-cards-buffer.svg as a temporary file, which could be used in symlink attacks to overwrite the contents of a file with write permissions to the person running fedora-business-cards. |
| Alerts: |
|
Comments (none posted)
gdm: privilege escalation
| Package(s): | gdm |
CVE #(s): | CVE-2013-4169
|
| Created: | September 6, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Red Hat advisory:
A race condition was found in the way GDM handled the X server sockets
directory located in the system temporary directory. An unprivileged user
could use this flaw to perform a symbolic link attack, giving them write
access to any file, allowing them to escalate their privileges to root.
(CVE-2013-4169)
Note that this erratum includes an updated initscripts package. To fix
CVE-2013-4169, the vulnerable code was removed from GDM and the initscripts
package was modified to create the affected directory safely during the
system boot process. Therefore, this update will appear on all systems,
however systems without GDM installed are not affected by this flaw. |
| Alerts: |
|
Comments (none posted)
kernel: code execution
| Package(s): | EC2 kernel |
CVE #(s): | CVE-2013-1060
|
| Created: | September 6, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Ubuntu advisory:
Vasily Kulikov discovered a flaw in the Linux Kernel's perf tool that allows for privilege escalation. A local user could exploit this flaw to run commands as root when using the perf tool. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2012-5375
|
| Created: | September 6, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Ubuntu advisory:
A denial of service flaw was discovered in the Btrfs file system in the Linux kernel. A local user could cause a denial of service (prevent file creation) for a victim, by creating a file with a specific CRC32C hash value in a directory important to the victim. |
| Alerts: |
|
Comments (none posted)
LibRaw: denial of service
| Package(s): | LibRaw |
CVE #(s): | CVE-2013-1439
|
| Created: | September 10, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Fedora advisory:
Specially crafted photo files may trigger a series of conditions in
which a null pointer is dereferenced leading to denial of service in
applications using the library. These three vulnerabilities are
in/related to the 'faster LJPEG decoder', which upstream states was
introduced in LibRaw 0.13 and support for which is going to be dropped
in 0.16. |
| Alerts: |
|
Comments (none posted)
phpbb3: file overwrites
| Package(s): | phpbb3 |
CVE #(s): | |
| Created: | September 9, 2013 |
Updated: | September 11, 2013 |
| Description: |
From the Debian advisory:
Andreas Beckmann discovered that phpBB, a web forum, as installed in
Debian, sets incorrect permissions for cached files, allowing a
malicious local user to overwrite them. |
| Alerts: |
|
Comments (none posted)
python-django: directory traversal
| Package(s): | python-django |
CVE #(s): | CVE-2013-4315
|
| Created: | September 11, 2013 |
Updated: | September 19, 2013 |
| Description: |
From the Debian advisory:
Rainer Koirikivi discovered a directory traversal vulnerability with
'ssi' template tags in python-django, a high-level Python web
development framework.
It was shown that the handling of the 'ALLOWED_INCLUDE_ROOTS' setting,
used to represent allowed prefixes for the {% ssi %} template tag, is
vulnerable to a directory traversal attack, by specifying a file path
which begins as the absolute path of a directory in
'ALLOWED_INCLUDE_ROOTS', and then uses relative paths to break free.
To exploit this vulnerability an attacker must be in a position to alter
templates on the site, or the site to be attacked must have one or more
templates making use of the 'ssi' tag, and must allow some form of
unsanitized user input to be used as an argument to the 'ssi' tag. |
| Alerts: |
|
Comments (none posted)
subversion: privilege escalation
| Package(s): | subversion |
CVE #(s): | CVE-2013-4277
|
| Created: | September 9, 2013 |
Updated: | September 25, 2013 |
| Description: |
From the Fedora advisory:
svnserve takes a --pid-file option which creates a file containing the process id it is running as.
It does not take steps to ensure that the file it has been directed at is not a symlink. If the
pid file is in a directory writeable by unprivileged users, the destination could be replaced by a
symlink allowing for privilege escalation. svnserve does not create a pid file by default. |
| Alerts: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
