Security
UEFI 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
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.
"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."
2011 Linux Security Summit schedule published
James 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 5
Over 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
| Package(s): | ConsoleKit | CVE #(s): | CVE-2010-4664 | ||||
| Created: | June 15, 2011 | Updated: | June 15, 2011 | ||||
| Description: | ConsoleKit treats users logged in via ssh as if they were local, possibly giving them extra privileges. | ||||||
| Alerts: |
| ||||||
fex: authentication bypass
| Package(s): | fex | CVE #(s): | CVE-2011-1409 | ||||
| Created: | June 13, 2011 | Updated: | June 18, 2011 | ||||
| Description: | From the Debian advisory:
It was discovered that fex, a web service for transferring very large, files, is not properly validating authentication IDs. While the service properly validates existing authentication IDs, an attacker who is not specifying any authentication ID at all, can bypass the authentication procedure. | ||||||
| Alerts: |
| ||||||
httpcomponents-client: credentials disclosure
| Package(s): | httpcomponents-client | CVE #(s): | CVE-2011-1498 | ||||
| Created: | June 15, 2011 | Updated: | June 16, 2011 | ||||
| Description: | According to the 4.1.1 release notes, HttpClient suffers from a vulnerability whereby it can send proxy authorization headers to sites other than the proxy. | ||||||
| Alerts: |
| ||||||
jabberd: denial of service
| Package(s): | jabberd | CVE #(s): | CVE-2011-1755 | ||||||||||||
| Created: | June 10, 2011 | Updated: | June 15, 2011 | ||||||||||||
| Description: | From the Red Hat advisory:
jabberd2, when expat is used, does not properly detect recursion during entity expansion, which allows context-dependent attackers to cause a denial of service (memory and CPU consumption) via a crafted XML document containing a large number of nested entity references, aka the "billion laughs attack." | ||||||||||||||
| Alerts: |
| ||||||||||||||
java: multiple vulnerabilities
| Package(s): | java | CVE #(s): | CVE-2011-0786 CVE-2011-0788 CVE-2011-0815 CVE-2011-0817 CVE-2011-0866 CVE-2011-0872 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 14, 2011 | Updated: | August 30, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | Multiple vulnerabilities have been fixed in Oracle Java update 26. See the Oracle advisory for details. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
java-1.6.0-openjdk: mysterious vulnerabilities
| Package(s): | java-1.6.0-openjdk | CVE #(s): | CVE-2011-0822 CVE-2011-0870 | ||||||||||||||||||||
| Created: | June 15, 2011 | Updated: | June 28, 2011 | ||||||||||||||||||||
| Description: | The java-1.6.0-openjdk packages suffers from vulnerabilities described as "integer overflows in 2D code" (CVE-2011-0822) and "vulnerability in SAAJ" (CVE-2011-0870). | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
mutt: man-in-the-middle attack
| Package(s): | mutt | CVE #(s): | CVE-2011-1429 | ||||||||||||||||||||||||||||
| Created: | June 13, 2011 | Updated: | April 2, 2012 | ||||||||||||||||||||||||||||
| Description: | From the CVE entry:
Mutt does not verify that the smtps server hostname matches the domain name of the subject of an X.509 certificate, which allows man-in-the-middle attackers to spoof an SSL SMTP server via an arbitrary certificate, a different vulnerability than CVE-2009-3766. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
networkmanager: password information disclosure
| Package(s): | NetworkManager | CVE #(s): | CVE-2011-1943 | ||||
| Created: | June 10, 2011 | Updated: | June 15, 2011 | ||||
| Description: | From the Fedora advisory:
NetworkManager-0.8.999-3.git20110526 inadvertently included a piece of debugging code that may have logged some VPN passwords to syslog. That version was available as an update for five (5) days before the fixed version was available. Users are advised to inspect log files in /var/log (and any backups) for VPN passwords and remove any that are found. The string "destroy_one_secret" may be used to identify files to be cleaned, such as by using the following command: 'grep -riI "destroy_one_secret" /var/log'. | ||||||
| Alerts: |
| ||||||
open-vm-tools: multiple vulnerabilities
| Package(s): | open-vm-tools | CVE #(s): | CVE-2011-1681 CVE-2011-1787 CVE-2011-2145 CVE-2011-2146 | ||||
| Created: | June 9, 2011 | Updated: | June 15, 2011 | ||||
| Description: | From the Novell bugzilla [1, 2]: CVE-2011-2146: The mount.vmhgfs utility makes a call to stat() to check for the existence and type (file, directory, etc.) of the user-supplied mountpoint, and provides an error message if the provided argument does not exist or is not a directory. Because mount.vmhgfs is setuid-root, a local attacker can leverage this behavior to identify if a given path exists in the guest operating system and whether it is a file or directory, potentially violating directory permissions. CVE-2011-1787: The mount.vmhgfs utility checks that the user-provided mountpoint is owned by the user attempting to mount an HGFS share prior to performing the mount. However, a race condition exists between the time this checking is performed and when the mount is performed. Successful exploitation allows a local attacker to mount HGFS shares over arbitrary, potentially root-owned directories, subsequently allowing privilege escalation within the guest. CVE-2011-2145: The vmware-user-suid-wrapper utility attempts to create a directory at /tmp/VMwareDnD. Next, it makes calls to chown() and chmod() to make this directory root-owned and world-writable. By placing a symbolic link at the location of this directory, vmware-user-suid-wrapper will cause the symbolic link target to become world-writable, allowing local attackers to escalate privileges within the guest. Only FreeBSD and Solaris versions of VMware Tools are affected. CVE-2011-1681: vmware-hgfsmounter in VMware Open Virtual Machine Tools (aka open-vm-tools) 8.4.2-261024 and earlier attempts to append to the /etc/mtab file without first checking whether resource limits would interfere, which allows local users to trigger corruption of this file via a process with a small RLIMIT_FSIZE value, a related issue to CVE-2011-1089. | ||||||
| Alerts: |
| ||||||
redmine: multiple vulnerabilities
| Package(s): | redmine | CVE #(s): | |||||||||
| Created: | June 15, 2011 | Updated: | November 26, 2015 | ||||||||
| Description: | According to the Debian update, the redmine package contains vulnerabilities which can enable logged-in users to access private data, facilitate cross-site scripting attacks, and remotely execute code via the Bazaar repository adapter. | ||||||||||
| Alerts: |
| ||||||||||
sudo: multiple vulnerabilities
| Package(s): | sudo | CVE #(s): | |||||
| Created: | June 10, 2011 | Updated: | June 15, 2011 | ||||
| Description: | From the sudo changelog:
| ||||||
| Alerts: |
| ||||||
vlc: arbitrary code execution
| Package(s): | vlc | CVE #(s): | CVE-2011-2194 | ||||||||||||
| Created: | June 10, 2011 | Updated: | July 14, 2011 | ||||||||||||
| Description: | From the Debian advisory:
Rocco Calvi discovered that the XSPF playlist parser of vlc, a multimedia player and streamer, is prone to an integer overflow resulting in a heap-based buffer overflow. This might allow an attacker to execute arbitrary code by tricking a victim into opening a specially crafted file. | ||||||||||||||
| Alerts: |
| ||||||||||||||
webmin: cross-site scripting
| Package(s): | webmin | CVE #(s): | CVE-2011-1937 | ||||
| Created: | June 13, 2011 | Updated: | June 15, 2011 | ||||
| Description: | From the Mandriva advisory:
Cross-site scripting (XSS) vulnerability in Webmin 1.540 and earlier allows local users to inject arbitrary web script or HTML via a chfn command that changes the real (aka Full Name) field, related to useradmin/index.cgi and useradmin/user-lib.pl | ||||||
| Alerts: |
| ||||||
wireshark: multiple vulnerabilities
| Package(s): | wireshark | CVE #(s): | CVE-2011-2175 CVE-2011-2174 CVE-2011-1959 CVE-2011-1957 CVE-2011-1958 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 9, 2011 | Updated: | January 14, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Fedora advisory: Bug #710109 - CVE-2011-2175 wireshark: Heap-based buffer over-read in Visual Networks dissector Bug #710097 - CVE-2011-2174 wireshark: Double-free flaw by uncompressing of a zlib compressed packet Bug #710039 - CVE-2011-1959 wireshark: Stack-based buffer over-read from tvbuff buffer when reading snoop capture files Bug #710021 - CVE-2011-1957 wireshark: Infinite loop in the DICOM dissector Bug #710184 - CVE-2011-1958 wireshark (64bit): NULL pointer dereference by processing of a corrupted Diameter dictionary file | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>