LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityStockpiling zero-day vulnerabilitiesZero-day vulnerabilities (aka zero-days or 0days) are those that have not been disclosed, so that they could be exploited before systems can be updated to avoid them. Thus, having a supply of carefully hoarded zero-day vulnerabilities can be advantageous for various people and organizations who might want to attack systems. The market for these zero-days has been growing for some time, which raises some ethical, and perhaps political, questions. A post to the Electronic Frontier Foundation (EFF) blog back in March was the jumping off point for a discussion of the issue on the DailyDave security mailing list recently. The EFF post highlighted the fact that these vulnerabilities are for sale and that governments are participating in the market. When vulnerabilities have a market value, there is little or no impetus to actually report and fix the problems, but those who buy them are able to protect their systems (and those of their "friends"), while leaving the rest of the world unprotected. The EFF recommended that the US government (at least) ensure that these vulnerabilities be reported:
If the U.S. government is serious about securing the Internet, any bill,
directive, or policy related to cybersecurity should work toward ensuring
that vulnerabilities are fixed, and explicitly disallow any clandestine
operations within the government that do not further this
goal. Unfortunately, if these exploits are being bought by governments for
offensive purposes, then there is pressure to selectively harden sensitive
targets while keeping the attack secret from everyone else, leaving
technology—and its users—vulnerable to attack.
In a post about this year's Black Hat security conference, DailyDave list owner Dave Aitel mentioned the EFF post, noting that calls for restricting what zero-day owners can do is "giving up freedom for security". He pointed out that any legislative solution is likely to be ineffective, but, beyond that, it is a question of freedom. Restricting the kind of code that can be written, or what can be done with that code, is not respecting anyone's freedom, he said. He advocated something of a boycott of EFF until it changes its position. While there was some sympathy for his view of the EFF in the thread, there was also some wider discussion of the implications of zero-day hoarding. Michal Zalewski noted that the practice makes us all less safe:
[...] the side effect of governments racing to hoard 0-days and
withhold them from the general public is that this drastically
increases the number of 0-day vulnerabilities that are known and
unpatched at any given time. This makes the Internet statistically
less safe, and gives the government a monopoly in deciding who is
"important enough" to get that information and patch themselves. The
disparity in purchasing power is also troubling, given that
governments have tons of "free money" to spend on defense, and are
eager to do so, outcompeting any other buyers.
But Bas Alberts pointed out that vulnerabilities are something of a power-leveler between individuals and larger organizations (like governments):
I would go as far as to say that 0day ownership promotes freedom for the individual,
regardless of who is selling or buying it. That's coincidental. It is one of the
few areas where a sufficiently motivated individual or group of individuals can
find, exploit, and develop an offensive capability that rivals that of a nation
state. It represents a right to bear arms (RAWR!) on the Electronic
Frontier(tm).
The semi-public markets in vulnerabilities may be relatively new, but using vulnerabilities as commodities is not, as Alberts describes:
Vulnerabilities and exploits
have always been a commodity ... a commodity of ego, humor and yes *gasp* money.
Exploit developers on both sides of the fence have been commoditizing exploits
for close to 2 decades, if not longer. They've been commoditized as marketing
tools, network tools, performance art, weapons, and political statements ...
regardless of whether they were private or public and regardless of who was
using them.
But the focus on zero-days is somewhat misplaced, according to Ben Nagy. While they may be a threat, it is not the primary threat to individuals from governments. There are much simpler ways to compromise a system:
They send
their targets stock malware and say 'please install by clicking on
this photo, love, er... not the government, srsly'. Or, they leverage
the fact that they have physical access to the carrier, the internet
cafes and so forth. (Or probably they just use humint [human intelligence]
cause it's
easier).
Legislation is also something of a slippery slope. For one thing, it will be difficult (or impossible) to enforce, even within a government. But, even if it is only applied to the US government—as the EFF post seems to advocate—these kinds of laws have a tendency to grow over time. As David Maynor put it: "If you apply regulations to one part of an industry, at some point regulations will seep to every part like the stench of rotten eggs." He goes on to describe some—seemingly—unlikely scenarios, but his point is clear: if government is not "allowed" to possess zero-day exploits, who will be allowed to?
It is assumed that governments want these kinds of vulnerabilities to attack other countries (a la Stuxnet). As Nagy pointed out, there are easier ways to attack individuals. Security firms also want to stockpile zero-days to protect their customers. There are other reasons to collect vulnerabilities, though. There are reports that various folks are stockpiling Linux vulnerabilities so that they can "root" their mobile phones and other devices that use it. Presumably, there are iOS fans doing the same thing. Because some device vendors (Apple is the poster child, but various Android vendors aren't far behind) try to prevent users from getting root access, those that want to be able to do what they want with their devices need to find some kind of vulnerability to do so. That may be a "freedom-loving" example, but it suffers from many of the same risks that other types of vulnerability hoarding do. Zero-day vulnerabilities lose their zero-day status—along with much of their potency—once they are used, reported, or fixed. Someone holding a zero-day cannot know that someone else hasn't also discovered the problem. Any purchased zero-days are certainly known to the seller, at least, but they could also be sold multiple times. If those vulnerabilities fall into the "wrong hands" (however defined), they could be used or disclosed, which makes secrecy paramount in the eyes of the hoarder. But if the information is to be used to protect certain systems, it has to be disseminated to some extent. Meanwhile, those on the outside are blissfully unaware of a potential problem. It is a tricky problem, but it is a little hard to see how any kind of legislation is going to "fix" it. It may, in fact, not really be a solvable problem at all. As various posters in the thread said, it is tempting to want to legislate against "bad" things, but when trying to define "bad", the devil is in the details.
Brief items Security quotes of the week
There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?
-- Kaspersky
Lab asks for decryption help
Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.
Starting next week, we will begin taking into account a new signal in our
rankings: the number of valid copyright removal notices we receive for any
given site. Sites with high numbers of removal notices may appear lower in
our results. This ranking change should help users find legitimate, quality
sources of content more easily—whether it’s a song previewed on NPR’s music
website, a TV show on Hulu or new music streamed from Spotify.
-- Google
SUSE and Secure Boot: The Details (SUSE Blog)Vojtěch Pavlík explains SUSE's plans for supporting UEFI secure boot on the company's blog. It is similar to the Fedora approach, but creates its own key database for the shim bootloader to use with UEFI "Boot Services Only Variables". These "Machine Owner Keys" (MOKs) can be updated only during execution of the shim, thus allowing users to update them, but protecting them from overwrite by malware. "The enrollment process begins by rebooting the machine and interrupting the boot process (e.g., pressing a key) when the shim loads. The shim will then go into enrollment mode, allowing the user to replace the default SUSE key with keys from a file on the boot partition. If the user chooses to do so, the shim will then calculate a hash of that file and put the result in a “Boot Services Only” variable. This allows the shim to detect any change of the file made outside of Boot Services and thus avoid the tampering with the list of user approved MOKs." Matthew Garrett called it a "wonderfully elegant solution" and suspects that Fedora will adopt it too.
New vulnerabilities bind: memory leak
bugzilla: information leak
calligra: code execution
chromium: multiple vulnerabilities
condor: privilege escalation
dokuwiki: cross-site scripting
kernel: privilege escalation
koffice: code execution
libotr: code execution
libvirt: remote denial of service
openttd: denial of service
perl-RT-Authen-ExternalAuth: privilege escalation
php5: denial of service
rubygem-actionpack: denial of service
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||