LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityUEFI and "secure boot"Hardware-based secure boot mechanisms are clearly useful for some users. By determining that firmware, bootloaders, and operating systems are not compromised, these mechanisms can protect systems against rootkits and other low-level attacks. Typically, the way that is done is by cryptographically signing the binaries in question such that they can be verified before being run. But disallowing unsigned binaries from running has a potentially problematic side effect: booting free operating systems becomes difficult or, in the worst case, impossible. It all depends on who holds the signing keys. The Linux kernel has the integrity measurement architecture (IMA) and the proposed extended verification module (EVM) which could be combined with system hardware—such as the Trusted Platform Module (TPM)—to provide a secure boot environment. There have been concerns about these mechanisms as they can be used for both good and ill: either preventing rootkits and other tampering or preventing users from running code of their choice on their hardware. The unified extensible firmware interface (UEFI) specification has recently added some features that could be used similarly, leading to many of the same concerns. But there is also an additional wrinkle for systems that use the GRUB 2 bootloader. UEFI is a relatively new standard for firmware that provides the boot environment for computer systems. For x86-64 systems (there are no plans to put UEFI in 32-bit x86 systems), it is aimed at replacing the 20+ year-old BIOS interface that is used to boot systems today. While BIOS is x86-specific, UEFI aims to be cross-architecture, and various vendors of ARM-based systems—Apple is rumored to be among them—have started adopting it. The UEFI 2.3.1 specification [agreement required] has a number of new features, one of which is the optional "secure boot" protocol. So far, UEFI 2.3.1 is not being shipped by any vendor and is only available on evaluation boards, but that will change in time. The basic idea behind secure boot is to sign executables using a public-key cryptography scheme (RSA with 2048-bit keys with SHA-1 or SHA-256 as the hash). The public part of a "platform key" (PK) can be stored in the firmware for use as a root key. Additional "key exchange keys" (KEKs) can also have their public portion stored in the firmware in what is called the "signature database". That database contains public keys that can be used to verify different components that might be used by UEFI (e.g. drivers) as well as bootloaders, and operating systems that get loaded from external sources (disks, USB devices, network, and so on). The signature database will also contain "forbidden" signatures which correspond to a revocation list of previously valid keys. The signature database is meant to contain the current list of authorized and forbidden keys as determined by the UEFI organization. Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems. All of this presents some problems for free software. If device makers create PKs and KEKs for the devices before shipping them to users, and do not provide the private portion of the keys, only entities listed in the signature database will be able to sign bootloaders and OSes. That is a fairly secure option for the device maker, but makes it difficult for those who might want to choose what code gets run on their hardware. Secure boot is optional, but there is likely to be a fair amount of pressure applied by proprietary OS makers to enable it. One could imagine that those vendors might also provide a way to turn off secure boot (from a BIOS-like menu for example), but that is something that might be exploited by rootkits and other malware, so there may well be resistance to allowing that kind of option. Protecting users from rootkits and the like is certainly useful, but there is a competitive advantage as well. Hardware vendors can ensure that only the code they approve can run on the hardware, and proprietary OS vendors will be largely unaffected because their keys will be in the signature database. One would hope that the protection against malware is the primary motivation, but the ability to lock out free OSes is likely seen as a plus. It is Linux and other free systems that could suffer most from secure boot implementations. While it would be possible for various distributions to get their keys added, that wouldn't help anyone who wanted to run a tweaked version of the "approved" bootloader or kernel. Distributors would not be able to release their private keys to allow folks to sign their own binaries either. Each key is just as valid as any other, so malware authors would just pick up those keys to sign their wares. Exposed keys would also find their way onto the forbidden list rather quickly one suspects. But there is another potential pitfall here. The GRUB 2 bootloader, which is finding its way into some distributions, is licensed under GPLv3. One of the attributes of GPLv3 (the so-called "anti-Tivo-ization" language) requires that any keys needed to "install and execute modified versions of a covered work" must be disclosed just like the source code. So, any distribution that wanted to get a key and keep it private so that their systems will boot on locked-down hardware will not be able to do so if it uses GRUB 2. Platform vendors are likely to use a key from UEFI as the PK, and distribute updated signature databases from the organization signed by that key. While any KEK that gets compromised will be added to the forbidden list, updating the firmware will presumably be optional so that existing hardware will still boot from code signed by compromised keys; newer hardware would get the updated forbidden list. But it would certainly be possible for an OS to "phone home" for the most recent signature database and refuse to run until the database in the firmware is current. That could be seen as reasonable protection (against malware signed by the compromised key) but would also be a fairly effective anti-jailbreaking feature. It will be important for free software OSes (Linux distributions, the BSDs, etc.) and users to ensure that hardware vendors are aware of their needs here. Microsoft and Apple have no interest in enabling anything other than their own code to boot and run on tomorrow's hardware, and it wouldn't bother them at all to see free software get left out in the cold. In the consumer device space, it is certain that some vendors will take the opportunity to lock down their devices using UEFI, but in the server space, Linux has such a presence that one would guess some kind of solution (perhaps just an "off" switch) will be found. Desktop computers, on the other hand, are dominated by Microsoft (and to a lesser extent Apple), so our leverage there may be insufficient. If we don't keep an eye on it, your next desktop may simply refuse to boot your OS of choice. [ I would like to thank Manoj Iyer for giving me a heads-up about this issue. ]
Brief items Security quotes of the week
Once inside, they leapfrogged between the accounts of different Citi customers by inserting various account numbers into a string of text located in the browser's address bar. The hackers' code systems automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data.
-- The
New York Times with an interesting definition of "ingenious"
The method is seemingly simple, but the fact that the thieves knew to focus on this particular vulnerability marks the Citigroup attack as especially ingenious, security experts said.
But some RSA customers say they still don't have enough information from RSA to determine whether they are actually at risk. RSA still hasn't come clean with all of the details on what the bad guys stole. If the seeds were compromised, for instance, then SecurID customers who replace their tokens might have to do so again at another time.
-- Dark
Reading
"Customers need to ask RSA why new tokens matter. Does getting a new token mean I'm more secure? That's the question that needs to be asked," says Marcus Carey, a security researcher with Rapid7. "Companies need to know that this isn't a 'token' gesture."
One thing should be noted; the attacks against Sony are not coordinated,
nor are they advanced. Sony has demonstrated they have not implemented what
any rational administrator or security professional would consider "the
absolute basics". Storing millions of customer's personal details and
passwords without using any form of encryption is reckless and
ridiculous. Even security books from the '80s were adamant about encrypting
passwords at the very least. Several of Sony's sites have been compromised
as a result of basic SQL injection attacks, nothing elaborate or complex.
-- "Security
Curmudgeon" in "A concise history of recent Sony hacks"
We've created a culture of self-perpetuating paranoia in
military-industrial data security by building systems that are deliberately
compromised then arguing that draconian measures are required to defend
these holes we've made ourselves. This helps the unquestioned three-letter
agencies maintain political power, doing little or nothing to increase
national security, while at the same time compromising
personal security
for all of us.
-- Robert
X. Cringely
2011 Linux Security Summit schedule publishedJames Morris has announced that the schedule for the Linux Security Summit is now available. The summit will be held on September 8 as part of the Linux Plumbers Conference in Santa Rosa, CA. Talks on Smack, MeeGo security, and various topics around the Linux integrity subsystem are planned. In addition, two roundtable discussions will be held in the afternoon, one on kernel hardening and the other on the Linux Security Module (LSM) architecture including ideas for ways to stack LSMs.
Jacob: Cross-domain WebGL textures disabled in Firefox 5Over at hacks.mozilla.org, Benoit Jacob explains why cross-domain textures have been disabled for WebGL in Firefox 5. "When a cross-domain image was used as a WebGL texture, the WebGL canvas was "tainted" so that reading from it was no longer possible. Theoretically, that eliminated the concern. But a while ago, a researcher wrote to the public WebGL list with a possible attack that could still allow reading pixels from WebGL textures. The idea was to paint the texture one pixel at a time with a WebGL fragment shader crafted to take an amount of time proportional to its brightness, and then time how long it takes: that would conceivably allow to get an approximation of the original image. Initially this attack seemed difficult to execute practically, but since then further research, including a proof-of-concept has been published which shows the attack to be more realistic than initially expected." LWN looked at WebGL vulnerabilities a few weeks back.
New vulnerabilities ConsoleKit: privilege escalation
fex: authentication bypass
httpcomponents-client: credentials disclosure
jabberd: denial of service
java: multiple vulnerabilities
java-1.6.0-openjdk: mysterious vulnerabilities
mutt: man-in-the-middle attack
networkmanager: password information disclosure
open-vm-tools: multiple vulnerabilities
redmine: multiple vulnerabilities
sudo: multiple vulnerabilities
vlc: arbitrary code execution
webmin: cross-site scripting
wireshark: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||