LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
Recent Features
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityDefault "secrets"One of the simplest principles of cryptography is that the secret keys which are used for encryption must be kept, well, secret. Exposing the key to anyone other than the intended recipient of the message can pretty obviously lead to a compromise of the encrypted data. So, for example, hardcoding a secret key into a firmware image is unlikely to lead to secure communications using that key. Unfortunately, networking device makers—and the creators of free software firmware replacements for those devices—seem to have missed, or ignored, this basic principle. The problem stems from the SSL keys that are installed into the firmware images for the devices. In many cases, those keys—including the supposedly private key—are generated when the image is built and then flashed into hundreds or thousands of different devices. If one can get access to the private SSL key, traffic encrypted with it (which might include HTTPS or VPN traffic) can be trivially decrypted. As the announcement of the LittleBlackBox project describes, it is, unfortunately, rather easy to obtain said keys; in fact the project provides a database of thousands of private keys indexed by their public key. In practical terms, that means an attacker can access a vulnerable SSL-protected web site, retrieve the public key certificate, look up the corresponding private key, and decrypt any traffic that is sent or received by the web site. An attacker could also do a man-in-the-middle attack by pretending to be the site in question, as there would be no way to determine that the spoofer wasn't the real site. In order to do either of those things, though, the attacker must get access to the encrypted data stream. Open, or weakly secured, wireless networks are the easiest way for an attacker to get that access—or to become a man in the middle. As the concerns over Firesheep have shown, there is still a lot of traffic that travels unencrypted over wireless networks. Ironically, HTTPS is touted as a solution to that problem, but that only works if the private keys are kept secret. For the web applications targeted by Firesheep, that is not likely to be a problem, as their private keys were presumably generated individually and kept safe. But for others who might be using wireless networks to configure their routers—or connect to another network via VPN—it could be a much bigger problem. While reconfiguring your router from the local coffee shop may be a pretty rare event, even having the HTTPS-enabled web server available over the internet gives an attacker the ability to retrieve the public key, which can then be looked up in the LittleBlackBox database. If that SSL key is used for other things like VPN—something that might well be used at an open WiFi hotspot—that traffic is at risk as well. The right solution seems clear: don't supply default "secrets". In some ways, this problem parallels the longstanding, but hopefully improving, situation with default administrative passwords. Device manufacturers and firmware projects should not be shipping SSL keys and either generate them at "first boot" or provide a way for users to generate and upload their own keys. There are a few different reasons that it isn't always done that way today, from concerns over devices having enough entropy to generate a random key to the amount of time it can take to generate a key on a slow CPU, but those reasons aren't really offset by the damage that could be done. Users who enable HTTPS access to their devices do so with the idea that it will be more secure, and can be used in places where unencrypted communication doesn't make sense. There are also hurdles to overcome in either creating a key for each device (and/or firmware image) or providing instructions for users but, once again, that really doesn't help users that are relying on the device for secure communications. While some in the DD-WRT community don't see it as a big problem it is likely more serious than they are crediting. It would make far more sense to disable HTTPS access entirely—perhaps requiring a manual process to generate keys and enable that access—than it does to provide well-known keys. While the problem highlighted by LittleBlackBox isn't earth-shattering, it does show the sometimes cavalier attitude towards security that is shown by some in the embedded device arena. When you are selling (or providing) a device or firmware that is meant to secure someone's network, it makes sense to proceed carefully. And to keep secrets, secret.
Brief items Security quotes of the week
The bankers also fret that "future research, which may potentially be more
damaging, may also be published in this level of detail". Indeed. Omar is
one of my coauthors on a new Chip-and-PIN paper that's been accepted for
Financial Cryptography
2011. So here is our Christmas present to the
bankers: it means you all have to come to this conference to hear what we
have to say!
-- Ross
Anderson after a bankers' trade association tried to quash some
Chip-and-PIN research
Of course, in addition to the "green" advantages of this technology, there
are privacy implications. Even without your consent, the electric company
and the water company are permitted to continuously measure your use of
electricity and water; taken to the extreme, this monitoring alone could
tell them exactly when you use each and every device in your house.
-- Andrew
Appel on research that can identify the signatures of electronic and
water-based (e.g. sink, toilet) devices
Did you notice that? A two-terabyte rainbow table. A few years ago, that
kind of storage was largely theoretical. Now it's both cheap and portable.
-- Bruce
Schneier on GSM decryption
Breaking GSM With a $15 Phone Plus Smarts (Wired)Wired's Threat Level blog looks at a GSM cellphone eavesdropping demonstration made at the recent Chaos Computer Club Congress in Berlin. "As part of this background communication, GSM networks send out strings of identifying information, as well as essentially empty "Are you there?" messages. Empty space in these messages is filled with buffer bytes. Although a new GSM standard was put in place several years ago to turn these buffers into random bytes, they in fact remain largely identical today, under a much older standard. [...] This allows the researchers to predict with a high degree of probability the plain-text content of these encrypted system messages. This, combined with a two-terabyte table of precomputed encryption keys (a so-called rainbow table), allows a cracking program to discover the secret key to the sessions encryption in about 20 seconds."
Bareil: Linux Security, one year later...Nicolas Bareil looks at GNU/Linux security in 2010. "Bug #1: Disabling frontier: The kernel has to validate each user-provided pointer to check if it is coming from user or kernel space. This is done by access_ok() with a simple comparison of the address against a limit (XXX). Sometimes, the kernel needs to use function which are normally designed to be called by userspace, and as such, theses functions checks the provenance of the pointer... which is embarrassing because the kernel only provides kernel pointers. So the kernel goes evil and cheats by manipulating the boundary via set_fs() in order to make access_ok() always successful. At this moment and until the kernel undoes its boundary manipulation, there is no protection against NULL pointer dereference attack." (Thanks to Patrick Guignot)
Spengler: False Boundaries and Arbitrary Code ExecutionBrad Spengler has posted a review of Linux capabilities and how they can be leveraged for full root privileges on the grsecurity blog. In short, 20 of the 35 capabilities bits allow actions that can result in root privileges from an exploitable program. "As mentioned earlier, there are 35 capabilities currently implemented. I'll now discuss each capability that is effectively equal to root and a rough description of how each transition is made. I will try to make a distinction between cases that are generally applicable and those that are situational. Since we've already established that real uid 0 is equivalent to having full capabilities on any normal system, I'll assume we're a non-root user with only the mentioned capability raised." (Thanks to Dan Carpenter.)
New vulnerabilities dbus: denial of service
drupal-views: cross-site scripting
eclipse: cross-site scripting
evince: arbitrary code execution
gif2png: arbitrary code execution
kernel: multiple vulnerabilities
kernel: multiple vulnerabilities
libwmf: multiple vulnerabilities
libxml2: arbitrary code execution
mantis: multiple vulnerabilities
opensc: arbitrary code execution
perl-IO-Socket-SSL: denial of service
phpmyadmin: multiple vulnerabilities
wordpress: SQL injection
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||