UEFI

Shrinking Linux Attack Surfaces

Zack Brown — Thu, 18 Jul 2019 11:00:00 +0000

Often, a kernel developer will try to reduce the size of an attack surface against Linux, even if it can't be closed entirely. It's generally a toss-up whether such a patch makes it into the kernel. Linus Torvalds always prefers security patches that really close a hole, rather than just give attackers a slightly harder time of it.

Matthew Garrett recognized that userspace applications might have secret data that might be sitting in RAM at any given time, and that those applications might want to wipe that data clean so no one could look at it.

There were various ways to do this already in the kernel, as Matthew pointed out. An application could use mlock() to prevent its memory contents from being pushed into swap, where it might be read more easily by attackers. An application also could use atexit() to cause its memory to be thoroughly overwritten when the application exited, thus leaving no secret data in the general pool of available RAM.

The problem, Matthew pointed out, came if an attacker was able to reboot the system at a critical moment—say, before the user's data could be safely overwritten. If attackers then booted into a different OS, they might be able to examine the data still stored in RAM, left over from the previously running Linux system.

As Matthew also noted, the existing way to prevent even that was to tell the UEFI firmware to wipe system memory before booting to another OS, but this would dramatically increase the amount of time it took to reboot. And if the good guys had won out over the attackers, forcing them to wait a long time for a reboot could be considered a denial of service attack—or at least downright annoying.

Ideally, Matthew said, if the attackers were only able to induce a clean shutdown—not simply a cold boot—then there needed to be a way to tell Linux to scrub all data out of RAM, so there would be no further need for UEFI to handle it, and thus no need for a very long delay during reboot.

Matthew explained the reasoning behind his patch. He said:

Unfortunately, if an application exits uncleanly, its secrets may still be present in RAM. This can't be easily fixed in userland (eg, if the OOM killer decides to kill a process holding secrets, we're not going to be able to avoid that), so this patch adds a new flag to madvise() to allow userland to request that the kernel clear the covered pages whenever the page reference count hits zero. Since vm_flags is already full on 32-bit, it will only work on 64-bit systems.

Matthew Wilcox liked this plan and offered some technical suggestions for Matthew G's patch, and Matthew G posted an updated version in response.

Go to Full Article

Tamper-Evident Boot with Heads

Kyle Rankin — Thu, 31 Jan 2019 14:08:08 +0000

by Kyle Rankin

Learn about how the cutting-edge, free software Heads project detects BIOS and kernel tampering, all with keys under your control.

Disclaimer: I work for Purism, and my experience with Heads began as part of supporting it on Purism's hardware. As a technical writer, I personally find ads that mask themselves as articles in technical publications disingenuous, and this article in no way is intended to be an advertisement for my employer. However, in writing this deep dive piece, I found that mentioning Purism was unavoidable in some places without leaving out important information about Heads—in particular, the list of overall supported hardware and an explanation of Heads' HOTP alternative to TOTP authentication, because it requires a specific piece Purism hardware.

Some of the earliest computer viruses attacked the boot sector—that bit of code at the beginning of the hard drive in the Master Boot Record that allowed you to boot into your operating system. The reasons for this have to do with stealth and persistence. Viruses on the filesystem itself would be erased if users re-installed their operating systems, but if they didn't erase the boot sector as part of the re-install process, boot sector viruses could stick around and re-infect the operating system.

Antivirus software vendors ultimately added the ability to scan the boot sector for known viruses, so the problem was solved, right? Unfortunately, as computers, operating systems and BIOSes became more sophisticated, so did the boot-sector attacks. Modern attacks take over before the OS is launched and infect the OS itself, so when you try to search for the attack through the OS, the OS tells you everything is okay.

That's not to say modern defenses to this type of attack don't exist. Most modern approaches involve proprietary software that locks down the system so that it can boot only code that's signed by a vendor (typically Microsoft, Apple, Google or one of their approved third-party vendors). The downside, besides the proprietary nature of this defense, is that you are beholden to the vendor to bless whatever code you want to run, or else you have to disable this security feature completely (if you can).

Fortunately, an alternative exists that is not only free software, but that also takes a completely different approach to boot security by alerting you to tampering instead of blocking untrusted code. This approach, Heads, can detect tampering not only in the BIOS itself but also in all of your important boot files in the /boot directory, including the kernel, initrd and even your grub config. The result is a trusted boot environment with keys fully under your own control.

In this article, I describe some of the existing boot security approaches in more detail, along with some of their limitations, and then I describe how Heads works, and how to build and install it on your own system.

Go to Full Article

Good Lockdown vs. Bad

Zack Brown — Wed, 08 Aug 2018 12:00:00 +0000

by Zack Brown

There's an ongoing series of skirmishes between corporations who want to sell products that users don't fully control and the kernel developers who want users to be the highest authority. Sometimes these skirmishes manifest in the form of security patches intended to lock down the kernel. Do they lock down the kernel against outside attackers? Or do they lock down the kernel against change from anyone at all, including the user who owns the device?

David Howells recently pushed a patch out of the linux-next, submitting it for inclusion in the main source tree. As he put it, the patch "adds kernel lockdown support for EFI secure boot". And a man page included in the patch said:

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorized modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

The patch gave birth to an odd debate, but a familiar one by now. Matthew Garrett, ultimately the main proponent of the patch, kept defending it on technical grounds that Linus Torvalds felt were meaningless and dishonest, hiding a secret agenda that included helping companies like Microsoft lock users out of making changes to their own systems.

Andy Lutomirski was another critic of Matthew's defense of the patch. The debate circled around and around, with Linus and Andy trying to get Matthew to admit the true motivation they believed he had and Matthew attempting to give solid reasons why the patch should go into the kernel. Things got ugly.

James Morris initially accepted the patch, planning to send it up to Linus for inclusion, and Andy reviewed the code. Among his comments, Andy said the goal of the patch was not clearly stated. He said for the purpose of his code review he would assume the goal was to prevent the root user from either reading kernel memory or intentionally corrupting the kernel.

But, he didn't think those were proper goals for a kernel, even a UEFI Secure Boot kernel. He said, "the kernel should try to get away from the idea that UEFI Secure Boot should imply annoying restrictions. It's really annoying and it's never been clear to me that it has a benefit." He singled out the idea of preventing the root user from accessing kernel memory as one of these annoying restrictions.

Kees Cook replied with his overall justification for this patch. He said:

Go to Full Article

The Growing Role of UEFI Secure Boot in Linux Distributions

Mark Doran — Wed, 21 May 2014 18:48:31 +0000

by Mark Doran

With the increasing prevalence of open-source implementations and the expansion of personal computing device usage to include mobile and non-PC devices as well as traditional desktops and laptops, combating attacks and security obstacles against malware is a growing priority for a broad community of vendors, developers and end users. This trend provides a useful example of how the flexibility and standardization provided by the Unified Extensible Firmware Interface (UEFI) technology addresses shared challenges in ways that help bring better products and experiences to market.

The UEFI specification defines an industry-leading interface between the operating system (OS) and the platform firmware, improving the performance, flexibility and security of computing devices. Designed for scalability, extensibility and interoperability, UEFI technology streamlines technological evolution of platform firmware. In 2013, developers of several open-source Linux-based operating systems, including Ubuntu 12.10, Fedora 18 and OpenSUSE 12.3, began using UEFI specifications in their distributions.

Additional features of UEFI include improved security in the pre-boot mode, faster booting, support of drives larger than 2.2 Terabytes and integration with modern 64-bit firmware device drivers. UEFI standards are platform-independent and compatible with a variety of platform architectures—meaning, users of several different types of operating systems, including both Linux and commercial systems, can enjoy the benefits of UEFI. Equally, because the UEFI specification includes bindings for multiple CPU architectures, these benefits apply on a variety of hardware platforms with these operating systems.

While UEFI Secure Boot may be one of the most talked about features, the complete set of features in the UEFI specification provide a standardized interoperable and extensible booting environment for the operating system and pre-boot applications. The attributes of this environment make it ideal for increased use in a rapidly widening array of Linux-based distributions. UEFI specifications are robust and designed to complement or even further advance Linux distributions. Industry experts expect to see continued expansion of their use during 2014 and beyond.

Go to Full Article

Microsoft’s Take on UEFI May Impede Linux (and that’s being polite)

Michael Reed — Mon, 26 Sep 2011 14:51:28 +0000

by Michael Reed

Recent revelations about the way that Windows 8 will make use of UEFI, the next generation PC BIOS, have caused speculation that this may cause problems for people wanting to install Linux. Potentially, this could cause the PC to switch away from its historic position as the standard bearer for open platforms.

The next version of Windows, Windows 8, may only run on a PC that features the UEFI BIOS. The snag is that it will probably make use of the “secure booting” feature of UEFI which prevents unsigned operating systems from booting on the hardware. The maker of the computer can install a certificate into the firmware on the motherboard, and consequently, only signed boot loaders (and possibly kernels and drivers and even applications) can then run on the machine. Software vendors such as Microsoft must send their code away to the manufacture of the computer to be signed so that it will run.

In other words, the PC will undergo a historic change, from the consummate open platform to a closed one. This also means that Linux wont boot on future PCs unless the motherboard manufacturer takes the time to certify each version of the boot loader and possibly each distro or even every kernel. It also seems that compliance with this system may be incompatible with licenses such as GPL 3.

To digress for a moment, it’s worth considering a software environment that may voluntarily go down this path, Mac OS X, as its users could be willing to accept a change in the balance between freedom for security. It’s quite possible that a future version of Mac OS will only allow software installation via the app store, and furthermore, it might become impossible to run a binary that has not been signed and approved by Apple itself. Apple itself would probably not be too bothered that its hardware would be inaccessible to other operating systems.

By contrast, Linux is a broad church. Part of what makes Linux so great is that you can do anything you like with it. You can install it where you like and modify it so that it meets your needs. What we’re facing is a potential future in which ex-corporate PCs, for example, may well be tied to a specific version of Windows and absolutely nothing else will run.

Unsurprisingly, Microsoft employees have attempted to play down the undesirable ramifications of what may happen. In a post entitled “Protecting the pre-OS environment with UEFI”, Microsoft blogger Steven Sinofsky says:

“The most important thing to understand is that we are introducing capabilities that provide a no-compromise approach to security to customers that seek this out while at the same time full and complete control over the PC continues to be available.”

Go to Full Article