Meltdown and Spectre

On January 2018, security researchers disclosed two attacks coined Meltdown and Spectre. These attacks bypass the memory isolation of modern CPU by exploiting side-channel attacks on hardware-based optimization features of these CPUs. Thus, Meltdown and Spectre can gain arbitrary access to confidential information in the memory of the computer.

Modern CPUs, so-called superscalar computers, do not execute anymore the instructions sequentially. They implement many hardware-based optimization techniques that modify the normal instruction flow. For instance, the CPU executes multiple instructions concurrently to keep the processor’s sub-units as busy as possible (See Eben Upton’s post). Thus, out-of-order execution speculatively executes instructions further down the instruction flow as soon as all needed resources are available. Thus, the CPU may execute an instruction before it is sure that the instruction is needed. If later the CPU determines the instruction was not needed, it discards the corresponding results from its registers. This mechanism is sound architecturally but not at the microarchitecture level. The cache memory still holds the discarded results. Unfortunately, for many years, security researchers have designed side-channel attacks that leak confidential information from the cache. Modern CPUs’ branch predictors attempt to guess the future control flow and, execute the instructions of the predicted instruction flow preemptively. If the predicted decision is wrong, the CPU discards the “results” of the speculative instructions if the prediction was incorrect. Once more, this mechanism is sound architecturally. Unfortunately, the results remain in the cache memory. Covert-side-channel cache attacks can retrieve them.

The attacks

The goal of Meltdown is to dump the kernel memory space from a user-space process. In a simplified explanation, Meltdown operates in two steps. During the first step, Meltdown entices the CPU to access the kernel space through out-of-order instructions. When the instruction flow reaches this execution point, it detects the violation and triggers an exception handling that blocks actual access to the kernel space. During the second step, Meltdown uses covert-channel cache attacks to retrieve the cached “inaccessible” data. Intel memory management maps privileged kernel memory in the user-space. Thus, kernel memory becomes accessible. The usual security assumption is that kernel memory is secure and not accessible on a computer without root access. Meltdown breaks the hardware-enforced isolation between kernel space and user-space.

Meltdown may affect any CPU using out-of-order mechanism and is OS-independent. Meltdown has been successfully tested on Intel x86, Intel XEON processors, and ARM Cortex A57. Meltdown was mounted on cloud containers, such as Docker, successfully. The software countermeasures use KAISER. KAISER is a software patch that prevents the mapping of kernel memory into the user space, thus thwarting Meltdown. The KAISER patch is available for Windows 10, Linux, MacOS and iOS.

The goal of Spectre is to reach information from another process. Spectre exploits branch prediction and speculative execution. It operates in three steps. During the first step, Spectre mistrains the branch predictor by repeatedly executing a given branching. During the second step, Spectre entices the branch predictor to mispredict the control flow. The CPU then executes the speculative code that should perform the “illegal” operations, such as reading unauthorized memory. As in Meltdown, the third step exfiltrates the cached data using a covert-channel cache attack. Spectre accesses from a given user-space the memory of another user-space. Spectre breaks the hardware-enforced isolation between processes.

Spectre has been successfully implemented on recent Intel processors, AMD Ryzen, AMD FX, and AMD PRO. Spectre was implemented on Windows and Linux-based OS. It was written in C and also in JavaScript. The countermeasure would be to halt predictive execution on sensitive execution paths. This is a difficult task as the current instruction set is not fit for that purpose. The alternative solution is to implement in the code mechanisms that reduce the impact of the leaked information (for instance, combining conditional select and conditional move. In other words, developers must be aware of the covert-channel cache attack and implement adequate countermeasures. Compilers may also implement some tricks.

As Spectre can be mounted with JavasScript, malicious adware may become the first exploits using Spectre in the field. Thus, browsers are receiving patches to mitigate the risk. The exploitability via JavaScript is worrying.

Google’s Project Zero released concurrently three vulnerabilities, coined variant 1 to 3. These three vulnerabilities are identical to Meltdown and Spectre. Variant 1 and 2 correspond to Spectre whereas variant 3 maps to Meltdown.

Conclusion

Meltdown and Spectre are not due to bugs. They are the consequences of a new breed of side-channel attacks exploiting information leaking at the microarchitectural level for speed optimization.

It is interesting to notice that Paul Kocher is one of the researchers disclosing Meltdown and Spectre. In 1996, Paul designed the first side channel attack. His attack disrupted the security of smart cards. Since 1996, side-channel attacks have been among the most prolific, complex fields of research in security.

We want/need the CPUs to be faster. Thus, silicon designer added these optimization features to go faster. Unfortunately, most trivial countermeasures would defeat the benefit. For instance, cache attacks may be defeated by randomizing or equalizing the access time, which would annihilate the purpose of the cache. New hardware architecture, as well as new instruction sets, will help to defend. Nevertheless, we have a new class of side channel attacks to take into account. No doubts that variants will soon flourish.

White box cryptography: an open challenge

The ideal implementation of a cryptographic algorithm would be such that even if the attacker would have the source code and would entirely control the platform, she would not be able to retrieve the secret key. In 2002, Stanley Chow and his colleagues proposed a new concept coined the white-box cryptography. The threat model of white-box attack assumes that the attacker has full access to the encryption software and entirely controls the execution platform. White-box cryptography attempts to protect the keys even under such a hostile threat model. The main idea is to create a functionally equivalent implementation of the encryption or decryption algorithm that uses only look-up tables. Corresponding look-up tables, with the corresponding hard-coded secret key, replace the S-boxes, Feistel boxes and XOR functions usually employed by symmetric cryptography. Then, the look-up tables are further randomized. In theory, the randomization hides the hard-coded key. White box cryptography is a difficult challenge for skilled reverse engineers.

Abundant cryptographic analysis has demonstrated that these constructions are not theoretically secure. Nevertheless, well-crafted real implementations may resist reverse engineering. Many vendors offer such white-box cryptography for AES. The issue is how do you know whether an implementation is robust. Securing white-box cryptography is a lot of black magic. Currently, the only solutions are either reverse-engineer it yourself or trust your supplier blindly.

Fortunately, the European-funded research project ECRYPT launches an exciting challenge: The WhiBox contest. It is a capture the flag challenge dedicated to white-box cryptography. Developers are encouraged to post AES-128 white-box implementation as a C source code. Attackers are invited to break the challenge, i.e., extract the encryption key.

The contest starts on May 15 and ends August 31. The winners, i.e., the implementation that resisted the longest, and the attacker who broke the “strongest” implementation, during the rump session of CHES 2017.

This initiative is interesting. It will be a benchmark of state of the art in this obscure field. Of course, it will have value only if enough skilled attackers will answer the challenge. I expect some success. It reminds the challenges to evaluate oracle attacks for digital video watermarking (BOWS and BOWS2). BOWS demonstrated the risk associated with the access to a watermark detector.

We will follow this challenge. Will commercial solutions dare to submit implementations? Winning this challenge would be a feather in their hat.

 

Reference:

    Chow, S., Eisen, P., Johnson, H., Oorschot, P.C. van: A White-Box DES Implementation for DRM Applications. In: Feigenbaum, J. (ed.) Digital Rights Management. pp. 1–15. Springer Berlin Heidelberg (2003).

An insight in Knox

Samsung provides for its Galaxy devices an enterprise mobile security solution Knox. Among the features, Knox offers Workspace that compartments the mobile device in two spaces: user space and Knox space. Of course, the Knox space is running in a TrustZone™ and executes only authenticated trusted applications. There is not much public information about the actual implementation of Knox.

Uri Kanonov and Avishai Wool have lifted a part of the veil by reverse engineering Knox 1.0. Their paper provides an interesting in-depth description of some secure mechanisms such a compartmentalization (based on SELinux) or encryption file system. They also disclose some vulnerabilities. The last section describes some enhancements available in Knox 2.3 as well as some remaining issues.

An interesting element of the paper is the list of lessons:

  • Component reuse is welcome, provided a proper protection for the added attack surface.
  • Protect the software code of secure components
  • Validating the application authorized to run in the Trust Zone is key for security
  • Hardware Root of Trust should be at the root of any secure container system
  • Avoid resource sharing; it increases the attack surface.
  • Check the integrity of the secure container periodically; only checking at boot time is insufficient.

If you want to learn more about Knox, this paper is a good reading.

Kanonov, Uri, and Avishai Wool. “Secure Containers in Android: The Samsung KNOX Case Study.” arXiv, May 27, 2016. http://arxiv.org/abs/1605.08567.

Attackers are smart

In 2010, Steven MURDOCH, Ross ANDERSON, and their team disclosed a weakness in the EMV protocol. Most Credit / Debit card equipped with a chip use the EMV (Europay, MasterCard, Visa) protocol. The vulnerability enabled to bypass the authentication phase for a given category of transactions. The card does not condition transaction authorization on successful cardholder verification. At the time of disclosure, Ross’s team created a Proof Of Concept using an FPGA. The device was bulky. Thus, some people minored the criticality.

The team of David NACCACHE recently published an interesting paper disclosing an exemplary work on a real attack exploiting this vulnerability: “when organized crime applies academic results.” The team performed a non-destructive forensic analysis of forged smart cards that exploited this weakness. The attacker combined in a plastic smart card the chip of a stolen EMV card (in green on the picture) and an other smart card chip FUN. The FUN chip acted like a man in the middle attack. It intercepted the communication between the Point of Sales (PoS) and the actual EMV chip. The FUN chip filtered out the VerifyPIN commands. The EMV card did not verify the PIN and thus was not blocked in case of the presentation of wrong PINs. On the other side, the FUN chip acknowledged the PIN for the PoS which continues the fraudulent transaction.

Meanwhile, the PoS have been updated to prevent this attack.

This paper is an excellent example of forensics analysis as well as responsible disclosure. The paper was published after the problem was solved in the field. It discloses an example of a new potential class of attacks: Chip in The Middle.

Law 1: Attackers will always find their way. Moreover, they even read academic publications and use them.

RowHammer: A powerful new attack

In 2014, a group of researchers from Carnegie Mellon University and Intel published a new kind of disturbance attack on DRAM: rowHammer [1]. At the difference of SRAM (static), DRAM (dynamic) need regular refreshing to keep their memory. DRAM are organized by rows. Indeed, when reading or writing to an address, the circuit access the full row rather than only one specific cell. Cells are susceptible to inter-cell crosstalk (like any electronic elements). The researchers discovered the fast, repetitive reading of two rows they could generate a high rate of disturbances that produce errors in the memory. The actual code to produce errors is simple and short. It is a simple loop that reads two addresses, flushes the registers and the instruction cache. A typical 1 million iterations takes less than one second. The code does not need to be root. They tested 129 different DDR3 DRAM commercial modules. They induced errors in 110 modules.

Thus, they demonstrate that with simple software, it was possible to wreck DRAM memory.

This month, Google researchers went one step further. They used the rowHammer technique to create actual fault injection. On a standard x86-64 bit machine, they demonstrated two exploits [2].

  • Native Client (NACl) is a sandboxing system that allows only a limited subset of instructions. They were able to have ‘blacklisted’ instructions to execute in the NACl environment.
  • They succeeded to escalate the privilege to Kernel privilege on a standard Linux.

Of course, these exploits have some limitations. The escalation was done only on a Linux machine without some sandboxing mechanisms. Nevertheless, they highlight that rowHammer may become a powerful fault injection tool. The interesting part of rowHammer is that it is purely software.

Currently, they have only experimented rowHammer on standard DRAM commercial modules. This may be an interesting way to bypass some trusted execution environment that isolate the DRAM space.

DRAM for servers should be more resistant to rowHammer as Error Correction is embedded in the chip. Nevertheless, error correction can only correct a limited amount of simultaneous errors. It may be possible perhaps to also overflow the correction. If rowHammer would be possible on DRAM for servers, then it may be a potential interesting attack vector in the public cloud. The attacker may either bypass the sandbox or impair the memory of another user of the same server.

We may see in coming months more studies and exploits around rowHammer. Will it have the same impact than side channel attacks? To be surveyed…

The two papers are worthwhile to read. Read them in the chronological order.

[1]    Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors,” in Proceeding of the 41st annual international symposium on Computer architecture, 2014, pp. 361–372.

[2]    C. Evans, “Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges,” Project Zero, 09-Mar-2015.

 

Lenovo, Superfish, Komodia: a Man In The Middle story

Lenovo has made this week the headlines with the alleged malware: superfish.   Lenovo delivered  some PCx loaded with “bloatware” Superfish.  Superfish provides solution that performs visual search.  Seemingly, Superfish designed a software that allowed to place contextual ads on the web browsing experience.   To perform this highjacking, superfish uses a software stack from Komodia:  SSL Digestor.  According to the site of Komodia:

Our advanced SSL hijacker SDK is a brand new technology that allows you to access data that was encrypted using SSL and perform on the fly SSL decryption. The hijacker uses Komodia’s Redirector platform to allow you easy access to the data and the ability to modify, redirect, block, and record the data without triggering the target browser’s certification warning.

How does Komodia do the decryption without triggering the certificate validation of the browser?   The CERT has disclosed on Thursday the trick with its vulnerability note VU#529496.

Komodia Redirector with SSL Digestor installs non-unique root CA certificates and private keys, making systems broadly vulnerable to HTTPS spoofing

Komodia install stealthily its own root certificate within the browsers’ CA repository.   The stack holds its private key. This allows to ‘self-sign’ certificate to forge SSL connection.  The software then generates a typical Man In The Middle.   Despite the private key was encrypted, it was possible to extract some corresponding private keys (easy to guess the password; komodia).  This means that as long as the root key is not erased from browsers’ repository, an attacker may use the corresponding private key.  The attacker may sign malware that would be accepted by the machine, and generate phony certificates for phishing.   In other words, other principals than Superfish may use the hack for infecting Lenovo computers.

Lenovo provided a patch that removed the Superfish application.   Unfortunately, the patch does not erase the malicious certificate.  Microsoft provided such patch, and Mozilla should soon revoke it.

This is a perfect example of supply chain attack. The main difference is that the supplier voluntarily infected its product.    Do never forget law 4: Trust No One.

PS:  at the time of writing, the Komodia site was down, allegedly for a DOS.  It may also be because too many people try to visit the site.