Check Your (Root) Privilege - On CVE-2016-4484

A Cryptsetup Initrd Script Flaw

Recently, a programming flaw was found in the init scripts for certain Linux distributions. These scripts handle decryption of the system volume when full disk encryption is used to guard the system's data. There has been a lot of confusion as to whether this is a high priority vulnerability or not. I would qualify this bug as a security risk, but as a very low priority risk. In fact, if I were auditing a system with this flaw in it, I would likely mark it as "Risk Accepted" after a conversation with the customer.

As the reader may or may not know, the vulnerability in this script allows an adversary with access to the boot interface to gain a root shell. This is accomplished by abusing a flaw with the initrd scripts that accept passwords for decrypting the disk. After a somewhat short period of waiting for a valid password, the scripts literally just give up and decide to grant access to a shell. This is done in case the console user needs to administer the disk in some way.

Oh, No! Not a Shell!

It's important to note the technical attributes of a computing environment that determine whether access to that environment is privileged or not. Most importantly, access to an administrative shell is not equivalent to access to the underlying system objects. 

This is most evident in sandboxed environments or jails where an untrusted application (or user) is granted administrative privileges within that walled garden. Sure, they can screw up the walled garden all they want, but that does not affect the host environment without a secondary vulnerability in the operating system environment or kernel software. This can also be easily observed by terminal services environments where a "clean" operating system is presented to each user that logs in, and is automatically cleaned up and refreshed on logout. 

The Model

The points to acknowledge when evaluating a computing environment are:

• Is the boot process trusted
• Is the full-disk encryption integrity checked
• Is initrd read only

These points are really all the reader needs to keep in mind when determining whether this is a security flaw. The answer is very simple once you put your computing device into the above context. 

For example, in a trusted boot model, the following steps should occur:

• The first-stage bootloader (Boot1) in either ROM or locked Flash executes
• Boot1 loads the next-stage bootloader (the featurefull bootloader, Boot2) into memory
• Boot1 cryptographically validates the integrity of Boot2
• If integrity check fails, halt; Otherwise, continue
• Boot2 loads the next-stage executable (Kernel1) into memory
• Boot2 cryptographically validates its configuration as well as the next-stage executable
• If integrity check fails, halt; Otherwise, continue
• Boot2 adjusts the launch of Kernel1 based on the secure configuration
• Boot2 executes Kernel1
• Kernel1 loads an operating system bootstrap image Initrd1 into memory
• Typically Initrd1 is already cryptographically validated per Boot2's process
• Kernel1 passes control to the init or init-alike application in Initrd1

At the end of this chain of events, the loaded mini-operating system image should not only be trusted, it should originate from an immutable environment. In other words, any applications executing within Initrd1 should not be able to alter the configuration or subvert the trust of any of the executable objects that have executed prior to it. In fact, it is possible to lock down an initrd such that manipulating key peripherals and kernel memory is not possible. 

The reader may at this point acknowledge that all objects loaded after this point are vulnerable to tampering. This will always be true unless the encrypted disk image is read-only. Even so, if the system relies on the console user to provide a password and the user does not have access to this password, a read-only image cannot be read and a read/write image can only be destroyed (presuming the image is properly integrity checked).

It's Not a Toomah

So, from the perspective of this model, gaining access to a root shell means absolutely nothing if the system was properly secured. If it was not secured, then abuse of the computing environment via a root shell is only a symptom of the underlying gaps in security and not a cause. Access to the computing device in an untrusted boot system will always yield privileged access regardless of whether or not a shell is immediately accessible. 

For example, a few years ago a team at iSEC Partners was able to manipulate a Verizon/Sprint femtocell simply by gaining access to the console. I reverse engineered the next model of the same femtocell which had two separate processing units (one PowerPC and one MIPS). The PowerPC side controlled the baseband while the MIPS side controlled the user configurable interface. While they went to great lengths to separate application layers for stability and security, access to the "secure" processor on the femtocell was as easy as attaching a JTAG adapter and interrupting the boot process to enable write on the read-only console. 

Why do I bring this up? Because this was not a hack. It was an abuse of a fundamental part of a poorly secured and over-engineered system. It was a symptom of flawed engineering and not the cause. 

But it Is Cancerous

The fundamental takeaway from this isn't that this bug is a security flaw (because it really isn't). The takeaway is that we have engineered systems that are untrustworthy by design. This was initially because we didn't have the technology, the cost-effectiveness, or the interest to engineer secure systems for consumers (or even mass distributed technologies like embedded systems for ATMs, in-flight entertainment, telematics, etc). But, now we do. However, the skill for implementing this seems to be isolated within engineering teams at Apple and Chromebook. 

The only way to make perceived vulnerabilities like CVE-2016-4484 go away is to provide the consumer (or engineering firm) with technology that ensures programming flaws such as the bugs in these init scripts will not have privileged side effects, if and when they are abused.

As always, if you need assistance ensuring your embedded systems are designed securely from the ground up, or want your trust model evaluated by skilled engineers and reverse engineers, Lab Mouse Security is available for consulting engagements.

Best wishes,
Don A. Bailey
CEO / Founder
Lab Mouse Security (The IoT Experts)
https://www.securitymouse.com/
@DonAndrewBailey