LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityIntegrity management using Intel TXTBeing able to verify that the code running on a system is the "correct" code is an important feature for some environments. The Linux integrity management architecture (IMA) patches—recently merged for 2.6.30—look at the integrity of processes as they are started by the kernel. But that requires running on a "good" kernel. So a patch, recently put out for comments on linux-kernel, proposes a lower-level mechanism which uses Intel's Trusted Execution Technology (TXT) to verify the integrity of the kernel itself. Whereas the IMA lives completely within the Linux kernel, but uses Trusted Platform Module (TPM) hardware to check and enforce the integrity of code that is executed, the TXT-based integrity system interposes a virtual machine monitor (VMM or hypervisor) between the hardware and the kernel. This hypervisor, called Trusted Boot or tboot interacts with the TXT hardware, which is contained in various recent Intel chipsets, to verify the integrity of the kernel before launching it. The TXT hardware can itself verify the integrity of many of the firmware components (things like BIOS and option ROMs) that must be assumed when using IMA. In their introductory post, Joseph Cihula and Shane Wang of Intel describe the advantages of a TXT-based integrity system as follows:
To get trust in the initial kernel without using Intel TXT, a static root
of trust must be used. This bases trust in BIOS starting at system reset
and requires measurement of all code executed between system reset through
the completion of the kernel boot as well as data objects used by that
code. In the case of a Linux kernel, this means all of BIOS, any option
ROMs, the bootloader and the boot config. In practice, this is a lot of
code/data, much of which is subject to change from boot to boot
(e.g. changing NICs may change option ROMs). Without reference hashes,
these measurement changes are difficult to assess or confirm as benign.
This process also does not provide DMA protection, memory
configuration/alias checks and locks, crash protection, or policy
support.
By using the hardware-based root of trust that Intel TXT provides, many of these issues can be mitigated. Specifically: many pre-launch components can be removed from the trust chain, DMA protection is provided to all launched components, a large number of platform configuration checks are performed and values locked, protection is provided for any data in the event of an improper shutdown, and there is support for policy-based execution/verification. This provides a more stable measurement and a higher assurance of system configuration and initial state than would be otherwise possible. Since the tboot project is open source, source code for almost all parts of the trust chain is available (excepting SMM and Intel-provided firmware). It is interesting that they mention system management mode (SMM) as that has recently been the target of some research on undetectable rootkits. The kind of malware described in the research could subvert even TXT-based integrity systems. In a followup post, Cihula and Wang describe in some detail how TXT, tboot, and the kernel cooperate to make it all work. Tboot is loaded by the bootloader—typically grub—as the "kernel". The grub.conf file lists the Linux kernel and Intel-supplied binary-only "authenticated code module" as "modules" that get loaded as well. For those who wish it, tboot also supports launching the Xen hypervisor, instead of the Linux kernel, as the guest. Tboot then does all of the setup necessary to determine if the TXT environment is present and configured correctly, if not, it just launches the kernel as usual. But if it finds a proper TXT environment, it initiates the integrity checking and verifies the hardware environment. At that point, user-defined policies are consulted to determine the how to verify the integrity of the kernel and initial ramdisk (initrd) and what to do if verification fails. Tboot creates a shared page of memory and populates it with some data about itself for the kernel to use. The physical address of the shared page is passed to the kernel as a boot parameter. The kernel then maps that page as part of the boot process. The shared page is also used by the kernel to communicate its intent to move to one of the sleep states of the processor. Instead of directly sleeping, it informs tboot of all of the relevant ACPI data via the shared page and jumps into tboot via a vector listed in the page. When going into the standby (suspend to RAM or S3) sleep, additional steps are taken to ensure the memory integrity across the S3 boundary. This is done by calculating a hash value over critical memory regions (kernel code and data as well as the S3 resume code) and signing it using the TPM. The user-supplied tboot policies determine what actions to take if the RAM verification fails upon coming out of S3. The patch itself is relatively small and comments on it nearly non-existent. While it provides a potentially interesting protection against various attack scenarios, it also adds a layer underneath the kernel. In addition, there are some binary components to tboot that may raise some eyebrows. It will be interesting to see what kind of reception it gets, once folks start looking at it.
Brief items An update on the Fedora August 2008 intrusionThe Fedora project has sent out an update on last August's intrusion; there is quite a bit more information here now. "The compromise was not the result of a software vulnerability, and as we have previously stated, our investigation has revealed no such vulnerabilities. Instead, the intruder took a copy of a SSH private key which was not secured with a passphrase from a system outside the Fedora infrastructure. The intruder then used that key, which belonged to a Fedora administrator, to access Fedora systems."
Vast Spy System Loots Computers in 103 Countries (New York Times)The New York Times broke the story of "GhostNet", a globe-spanning infiltration of computers, most of which are controlled by various governments. In investigating malware at the offices of the Dalai Lama, security researchers found a much larger operation. "Their sleuthing opened a window into a broader operation that, in less than two years, has infiltrated at least 1,295 computers in 103 countries, including many belonging to embassies, foreign ministries and other government offices, as well as the Dalai Lamas Tibetan exile centers in India, Brussels, London and New York. [...] The researchers, who have a record of detecting computer espionage, said they believed that in addition to the spying on the Dalai Lama, the system, which they called GhostNet, was focused on the governments of South Asian and Southeast Asian countries."
New vulnerabilities acroread: multiple vulnerabilities
auth2db: SQL injection
firefox: remote code execution
java-1.6.0-sun: multiple vulnerabilities
kernel: denial of service
krb5: denial of service
nss-ldapd: insecure config file creation
openssl: denial of service
openswan: denial of service
systemtap: race condition
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||