Security
LSS: Secure Boot
Matthew Garrett gave the opening keynote at the 2012 Linux Security Summit on his new "favorite" topic: UEFI Secure Boot. Up until about a year ago, he was working on power management for the Linux kernel, but at LinuxCon in Vancouver he found out about the requirement that systems shipping with the Windows 8 logo would be required to have Secure Boot enabled. He "ended up drinking quite a lot that week", he said, but things are not quite as bad as he had thought at first. Contrary to his initial fears, users will be able to boot Linux on hardware certified for Windows 8.
UEFI Overview
Garrett began with an overview of UEFI, noting that it is a replacement for the legacy PC BIOS. Its role is to initialize the hardware and to provide services to the bootloader for tasks like discovering hardware. It is the "least relevant 16MB of code you will ever encounter", he said. The code is mostly open and available from Intel under a BSD license. There is also some proprietary, machine-specific code to program memory controllers. The firmware vendors add their own code for "3D UIs"; those vendors also "add bugs of course". There is a surprisingly good compatibility suite and there are regular plugfests to ensure that the UEFI implementations can boot a variety of operating systems.
There are some relevant differences between UEFI and BIOS. To start with, UEFI firmware can read filesystems. The standard only requires VFAT support—and Microsoft grants a patent license for UEFI implementations. The bootloader is now an executable in PE/COFF format like Windows binaries. There is also non-volatile flash storage available where things like the location of the bootloader and parameters to pass to it can be stored.
When a computer is turned on, the firmware runs first, followed by a bootloader, which loads the operating system (OS). Traditionally, malware has targeted the OS, but vendors, particularly Microsoft, have gotten very aggressive at cutting down the OS as a target. Windows 8, for example, will load a virus checker very early on, before even some of the drivers are loaded, Garrett said.
Given that, we are seeing malware move away from the OS. Instead of "rootkits" we are starting to see "bootkits". For BIOS-based systems, the easiest way to install boot-time malware is to replace the master boot record (MBR). Once that's done, the bootloader can no longer be trusted (as the MBR will point to a malicious version), and the bootloader can change the OS when it loads it. The malware can then intercept attempts to verify the MBR by returning a "clean" copy, making it difficult to detect the compromise.
The key thing to note, Garrett said, is that if you are running untrusted code at any level, you can't trust the code at a higher level. UEFI Secure Boot is an attempt to fix the problem of bootkits. A header section is added to bootloaders (or other binaries) to contain signed hashes of the contents. The firmware will only launch binaries with a valid hash signed by a trusted key. It uses the same cryptographic algorithms that are used by Secure Sockets Layer (SSL), so there is no reason to believe that Secure Boot is insecure, other than the fact that it will be implemented by firmware vendors, he said.
Key management
For managing the keys, there are four databases in the firmware's flash. With UEFI, it will no longer be possible to write to that flash directly, instructions from x86 system management mode (SMM) will need to be used instead. The first database, "dbx", will contain keys and hashes that will always be rejected by the firmware. If a binary's hash is in dbx or if the key used to sign that hash is present, the firmware will not run it.
The "db" database contains keys and hashes that will be accepted, but entries in dbx override those in db. After the October launch of Windows 8, standard systems will contain the manufacturer's key and Microsoft's key in db. Vendors will want to enable Secure Boot so that they can access marketing money from Microsoft for promoting the hardware as "Windows 8 compatible". The margins on a laptop are "pennies", Garrett said, so the marketing money makes a big difference.
Being able to blacklist keys is an important part of the design of Secure Boot. Keys that have been used to sign malware or to sign other, non-malicious software that can be exploited can be disabled.
The other two databases are the "kek" (key exchange key), which stores keys that can be used to sign updates to db or dbx, and the "pk" (platform key) which can sign kek updates. Installing a pk causes the transition from "setup mode" to Secure Boot mode. Normally, the pk will be a hardware vendor key, which will be used to sign the update to the kek, which is where the Microsoft key will reside. This protects the vendor from Microsoft losing control of its key, because they could (in some unspecified way) have their customers update the kek using their key. If the private half of the key in the pk leaks, Secure Boot is no longer secure on those systems.
The UEFI specification defines the technical details of Secure Boot, but does not specify any particular policy with regard to how it is used. But Microsoft has specified policies for systems that want to get Windows 8 certification. For those, Secure Boot must be enabled by default, and the Microsoft key must be present. In January, Microsoft added the requirement that a physically present user must be able to disable Secure Boot and install their own keys—but only for x86-based systems, not those that are ARM-based.
An audience member asked if there was "any hope" of that requirement changing for ARM. Right now, Garrett said, ARM systems with Windows 8 certification must not allow disabling Secure Boot or adding user-specified keys. Whether ARM-based system vendors will actually pursue that certification is an open question since the Windows on ARM market "doesn't exist" at this point.
Linux on Secure Boot
To boot Linux on a Secure Boot system, there needs to be a signed bootloader. "Distasteful though it might be", the only sensible way to do that is to get Microsoft to sign it. One can set up an account with Verisign, pay some money, and get access to the Microsoft signing system. From there, you upload a binary, and a get a signed object back a day later. Because of the way headers are added with the signatures, you can still verify that it is your binary, rather than something that has been modified by Microsoft.
Once that signed bootloader has been run, it could do anything. But there are or could be consequences if it does. The signed bootloader stops malware from being inserted between the firmware and the bootloader. But, there is no way for code to determine if it is really running in Secure Boot mode. That is one difference between Secure Boot and Trusted Boot; the latter adds attestations that can prove the running code is what it says it is. In Secure Boot, one can ask the firmware if it is enabled, but there is no way to trust the answer unless the code at each level can be trusted.
In order to be able to extend trust to the higher-levels, those pieces (e.g. kernel, drivers) must be signed as well. But there is more to it than that, whatever signed kernel that runs must not be usable to run unsigned privileged code.
One of the problem areas is kexec(), which allows replacing a running kernel with a new kernel. It is like booting the new kernel, but without going through the hardware initialization (thus Secure Boot) step. But, kexec() could be used to boot Windows instead, which would allow an attacker to create a malicious Windows that boots on Secure Boot hardware. It would use the signed Linux bootloader and kernel, but kexec() into the mal-Windows. If that were to happen, Garrett said, Microsoft would blacklist the bootloader. "Apparently, our management was not enthusiastic" about that possibility, he said.
So, signed kernels require some changes to support Secure Boot. That means doing things like disallowing kexec() and restricting the ability of user space programs to cause hardware devices to perform direct memory access (DMA). The latter mostly affects graphics hardware that does not have support for kernel mode setting (KMS).
In the past, there was this idea of a separation between regular users and root. The idea was to prevent people from elevating their privileges to those of the root user, and protecting the kernel from root was not particularly important. That is no longer the case in the Secure Boot world. Root is no longer trusted, only the physically present user, who may not be the same as root, is trusted.
There are other things that will need to be handled to avoid signed kernels from "attacking" Windows. Garrett said that Kees Cook mentioned hibernation images recently as a vector for attack. When a user resumes from a suspend-to-disk, memory contents are read from disk. A crafted hibernation image could subvert the protections, so unless some other solution is found, hibernation will need to be disabled. That's fine, "because it doesn't really work in Linux anyway", he said.
Plan of attack
The plan is to create a trusted first-stage "shim" bootloader that will be signed with the Microsoft key. Because free software tends to change frequently, and it is desirable to avoid getting things signed all the time, having the shim, which should change infrequently, makes sense. The full bootloader is then signed with a distribution-specific key. Kernels and modules would also be signed with that key, or with a key already in the firmware key databases. If a user wants to sign their own kernels or modules, they can put their own key in the firmware.
Instead of adding keys to the four databases established by UEFI, SUSE came up with a way to add keys from the bootloader (which cannot access the key databases) to a secure location in the firmware. There are UEFI boot services variables that are only available to the boot environment. Using those to store keys will allow the bootloader to update them, when prompted by physically present users. Doing so from the bootloader avoids the problem of having to try to figure out and document how to add keys using the vendor-specific UEFI firmware set up tools. So far, that code does not exist, but SUSE is working on it, he said.
The management of thousands of systems requiring physically present users is "not a solved problem", he said in response to a question. There is the belief that those who are buying many systems will be able to convince vendors to ship their hardware in setup mode (with no keys) or to put custom keys into the firmware.
There are still some outstanding questions, including how to handle third-party module signing (e.g. for NVIDIA drivers). There could be some kind of Linux certificate authority (CA), but no one has stepped up to run such a thing. It would cost "at least millions" to set up and run, plus probably more than a year to get going, so "no one is jumping up and down to do this", he said. There is the possibility that third parties could have their modules signed by Microsoft or there could be some way to have the bootloader prompt for the installation of third party keys. Red Hat and other vendors are not inclined to sign third-party modules because of licensing issues and that it could be seen as an endorsement of binary-only modules.
Early on in the process of sorting out Secure Boot issues, there was concern that GPLv3 (which is the license for the GRUB2 bootloader) would require the signing keys to be disclosed. Garrett said that he and others had worked with the FSF on that problem. The conclusion that was reached is that the signing keys are not required to be disclosed as long as users can install their own keys, which they will be able to do.
In the final analysis, Secure Boot is "much less bad than it could be", Garrett said. It will increase the security of Linux "somewhat", but is mostly for increasing the security of Windows. As long as we are careful not to get our keys blacklisted (by allowing signed kernels to attack Windows), it won't seriously impede Linux in the future.
Brief items
Security quotes of the week
The notion that policies should focus almost exclusively on preventing the next attack has also masked an ideological battle within homeland-security policy circles between "never again" and its antithesis, commonly referred to as "shit happens" but in polite company known as "resiliency." The debate isn't often discussed this way, and not simply because of the bad language. Time has not only eased the pain of that day, but there have also been no significant attacks. "Never again" has so infiltrated public discourse that to even acknowledge a trend away from prevention is considered risky, un-American. Americans don't do "Keep Calm and Carry On." But if they really want security, the kind of security that is sustainable and realistic, then they are going to have to.
Tinnes: Introducing Chrome's next-generation Linux sandbox
Julien Tinnes describes the new sandbox mechanism for the Chrome browser under Linux. "In a similar, but very limited, fashion, this is what we have now in Chrome: we stacked the seccomp-bpf sandbox on top of the setuid sandbox. The setuid sandbox gives a few easy to understand semantic properties: no file system access, no process access outside of the sandbox, no network access. It makes it much easier to layer a seccomp-bpf sandbox on top."
New vulnerabilities
beaker: information disclosure
| Package(s): | beaker | CVE #(s): | CVE-2012-3458 | ||||
| Created: | September 10, 2012 | Updated: | September 12, 2012 | ||||
| Description: | From the Debian advisory:
It was discovered that Beaker, a cache and session library for Python, when using the python-crypto backend, is vulnerable to information disclosure due to a cryptographic weakness related to the use of the AES cipher in ECB mode. Systems that have the python-pycryptopp package should not be vulnerable, as this backend is preferred over python-crypto. | ||||||
| Alerts: |
| ||||||
dnsmasq: DNS proxy is wrongly created
| Package(s): | dnsmasq | CVE #(s): | CVE-2012-3411 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 12, 2012 | Updated: | March 11, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | David Woodhouse reports:
It seems that your dnsmasq instance is listening on that address, but *not* correctly discarding packets which come from a different interface. Even though the --bind-interface option is set. See the Red Hat bugzilla for more information. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
freeradius: code execution
| Package(s): | freeradius | CVE #(s): | CVE-2012-3547 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 12, 2012 | Updated: | January 14, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Timo Warns discovered that the EAP-TLS handling of freeradius, a high-performance and highly configurable RADIUS server, is not properly performing length checks on user-supplied input before copying to a local stack buffer. As a result, an unauthenticated attacker can exploit this flaw to crash the daemon or execute arbitrary code via crafted certificates. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ghostscript: code execution
| Package(s): | ghostscript | CVE #(s): | CVE-2012-4405 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 12, 2012 | Updated: | February 28, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
An integer overflow flaw, leading to a heap-based buffer overflow, was found in Ghostscript's International Color Consortium Format library (icclib). An attacker could create a specially-crafted PostScript or PDF file with embedded images that would cause Ghostscript to crash or, potentially, execute arbitrary code with the privileges of the user running Ghostscript. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GraphicsMagick: denial of service
| Package(s): | GraphicsMagick | CVE #(s): | CVE-2012-3438 | ||||||||||||||||||||
| Created: | September 7, 2012 | Updated: | March 26, 2013 | ||||||||||||||||||||
| Description: | From the Red Hat advisory: "As this function stands, it invisibly does the wrong thing for any request over 4GB. On big-endian architectures it very possibly will do the wrong thing even for requests less than that. So the reason why the hard-wired 4GB limit prevents a core dump is that it masks the ABI mismatch here." So basically we have memory allocations problems that can probably lead to a denial of service. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
mahara: cross-site scripting
| Package(s): | mahara | CVE #(s): | CVE-2012-2237 | ||||
| Created: | September 10, 2012 | Updated: | September 12, 2012 | ||||
| Description: | From the Debian advisory:
Emanuel Bronshtein discovered that Mahara, an electronic portfolio, weblog, and resume builder, contains multiple cross-site scripting vulnerabilities due to missing sanitization and insufficient encoding of user-supplied data. | ||||||
| Alerts: |
| ||||||
pnp4nagios: information disclosure
| Package(s): | pnp4nagios | CVE #(s): | CVE-2012-3457 | ||||
| Created: | September 12, 2012 | Updated: | September 12, 2012 | ||||
| Description: | From the CVE entry:
PNP4Nagios 0.6 through 0.6.16 uses world-readable permissions for process_perfdata.cfg, which allows local users to obtain the Gearman shared secret by reading the file. | ||||||
| Alerts: |
| ||||||
rpmdevtools: symlink attack
| Package(s): | rpmdevtools | CVE #(s): | CVE-2012-3500 | ||||||||||||||||||||||||||||
| Created: | September 12, 2012 | Updated: | April 10, 2013 | ||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
A TOCTOU race condition was found in the way 'annotate-output' (used to execute a program annotating the output linewise with time and stream) tool of rpmdevtools, a suite of scripts and (X)Emacs support files to aid in development of RPM packages, performed management of its temporary files used for standard output and standard error output. A local attacker could use this flaw to conduct symbolic link attacks, possibly leading to their ability in an unauthorized way to alter files belonging to the user running the 'annotate-output' tool. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
trousers: denial of service
| Package(s): | trousers | CVE #(s): | CVE-2012-0698 | ||||||||||||||||||||
| Created: | September 7, 2012 | Updated: | October 23, 2014 | ||||||||||||||||||||
| Description: | From the Red Hat advisory: This update closes a small security issue where a remote user could crash tscd if it were enabled for networking. This update also has improved init scripts which should make it load quicker. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
ubiquity-slideshow-ubuntu: code injection
| Package(s): | ubiquity-slideshow-ubuntu | CVE #(s): | CVE-2012-0956 | ||||
| Created: | September 10, 2012 | Updated: | September 12, 2012 | ||||
| Description: | From the Ubuntu advisory:
Paul Mutton discovered that ubiquity-slideshow-ubuntu incorrectly handled the Twitter feed displayed during system installation. A remote attacker could use this flaw to inject code into the Twitter feed and read arbitrary files off the filesystem during system installation. This flaw has been resolved in the Ubuntu 12.04.1 LTS installation images by disabling the Twitter feed. | ||||||
| Alerts: |
| ||||||
Xen: multiple vulnerabilities
| Package(s): | Xen | CVE #(s): | CVE-2012-3494 CVE-2012-3495 CVE-2012-3496 CVE-2012-3498 CVE-2012-3516 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 7, 2012 | Updated: | September 18, 2012 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the SUSE advisory: A malicious guest could cause a crash on the host which leads to a Denial of Service (CVE-2012-3494). A memory corruption related to PHYSDEVOP_get_free_pirq function could lead to a Denial of Service of the host or potentially to execution of arbitrary code (CVE-2012-3495). A BUG can be triggered via calling functions with invalid flags which causes a Denial of Service (host crash) (CVE-2012-3496). A malicious guest kernel could crash the host or potentially read hypervisor or guest memory (CVE-2012-3498). Unspecified vulnerability (CVE-2012-3516). | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
xen-qemu: privilege escalation
| Package(s): | xen-qemu-dm-4.0 | CVE #(s): | CVE-2012-4411 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 10, 2012 | Updated: | November 20, 2012 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
The qemu monitor was enabled by default, allowing administrators of a guest to access resources of the host, possibly escalate privileges or access resources belonging to another guest. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>