Blog entry by Les Bell

Les Bell
Security News: 2023-10-26
by Les Bell - Thursday, 26 October 2023, 10:40 AM
Anyone in the world

Welcome to today's daily briefing on security news relevant to our CISSP (and other) courses. Links within stories may lead to further details in the course notes of some of our courses, and will only be accessible if you are enrolled in the corresponding course - this is a shallow ploy to encourage ongoing study. However, each item ends with a link to the original source.

News Stories

New Attack Extracts Credentials from Safari Browser (But Don't Panic!)

Most security pros will doubtless remember the original speculative execution attacks, Spectre and Meltdown, which were first disclosed in early 2018. These attacks exploit the side effects of speculative, or out-of-order, execution, a feature of modern processors.

One design challenge for these CPU's is memory latency - reading the computer's main memory across an external bus is slow by comparison with the internal operation of the processor, and the designs deal with this by making use of one or more layers of on-chip cache memory. Much of the time, programs execute loops, for example, and so the first time through the loop, the relevant code is fetched and retained in cache so that subsequent executions of the loop body fetch the code from the cache and not main memory.

In fact, modern processors also feature a pipelined architecture, pre-fetching and decoding instructions (e.g. pre-fetching required data from memory) ahead of time, and they are also increasingly parallelized, featuring multiple execution units or cores. The Intel i9 CPU of the machine I am typing this on, for example, has 16 cores, and 8 of those each has two independent sets of registers to make context switching even faster (a feature Intel calls hyperthreading) so that it looks like 24 logical processors. All those processors need to be kept busy, and so they may fetch and execute instructions from the pipeline in a different order from the way they were originally fetched and placed in the pipeline, especially if an instruction is waiting for the required data to be fetched.

One aspect of this performance maximization is branch prediction and speculative execution. A branch predictor circuit attempts to guess the likely destination of a branch instruction ahead of time, for example, if the branch logic depends on the value of a memory location that is in the process of being read. Then having predicted this, the CPU will set out executing the code starting at the guessed branch destination. One downside is that sometimes the branch predictor gets it wrong, resuling in a branch misprediction, so this computation is done using yet another set of registers which will be discarded in the event of a misprediction (or committed, i.e. switched for the main register set, if the prediction was correct). This technique is referred to as speculative execution, and it is possible because the microarchitecture that underlies x86_64 complex instruction set (CISC) processors is really a RISC (reduced instruction set complexity) processor with a massive number of registers.

The result is an impressive performance boost, but it has a number of side-effects. For example, a branch misprediction will cause a delay of between 10 and 20 CPU clock cycles as registers are discarded and the pipeline refilled, so there will be a timing effect. It will also leave traces in the cache - instructions that were fetched but not executed, for example. And if a branch prediction led to, for example, a system call into the OS kernel, then a low-privilege user process may have fetched data from a high-privilege, supervisor mode, address into a CPU register.

These side-effects were exploited by the Spectre and Meltdown exploits of 2018, which caused some panic at the time; AMD's stock fell dramatically (leading some observers to suspect that the objective of related publicity was stock manipulation) while the disabling of speculative execution led to a dramatic rise in the cost of cloud workloads as more cores were required to carry the load. In due course, the processor manufacturers introduced various hardware mitigations, and we have gradually forgotten they were a problem.

You could think of these attacks as being related to the classic trojan horse problem in multi-level security systems, in which a high security level process passes sensitive data to a low security level process via a covert channel; they are probably most similar to the timing covert channel (in fact, most variants of these attacks make use of various timers in the system, just like the low security level part of the trojan horse). The essential distinction is that in the case of the trojan horse, the high security level process is a willing participant; in this case, it is not. Even secure-by-design, well-written programs will leak information via speculative execution and related attacks.

While the original investigation that led to Spectre and Meltdown was done on the Intel/AMD x86_64 architecture, Apple's silicon foundry has been doing some amazing work with the M series processors used in recent Macbooks, Mac minis, iMacs and iPads, not to mention the earlier A series which powered the iPhone, earlier iPads and Apple TV. Could the Apple Silicon processors be similarly vulnerable? The M1 and M2 processors, in particular, were produced after these attacks were known, and incorporate some mitigation features, such as 35-bit addressing and value poisoning (e.g. setting bit 49 of 64-bit addresses so they are offset \(2^{49}\) bytes too high).

A group of researchers from Georgia Tech, University of Michigan and Ruhr University Bochum - several of whom had been involved in the earlier Spectre and Meltdown research - turned their attention to this problem a couple of years ago and found that, yes - these CPU's were exploitable. In particular, they were able to get round the hardware mitigations as well as the defenses in the Safari browser, such as running different browser tabs in different processes (hence different address spaces).

On the web site they created for their attack, the researchers write:

We present iLeakage, a transient execution side channel targeting the Safari web browser present on Macs, iPads and iPhones. iLeakage shows that the Spectre attack is still relevant and exploitable, even after nearly 6 years of effort to mitigate it since its discovery. We show how an attacker can induce Safari to render an arbitrary webpage, subsequently recovering sensitive information present within it using speculative execution. In particular, we demonstrate how Safari allows a malicious webpage to recover secrets from popular high-value targets, such as Gmail inbox content. Finally, we demonstrate the recovery of passwords, in case these are autofilled by credential managers.

Their technical paper lists the work involved in combining a variety of techniques to create the iLeakage attack:

Summary of Contributions. We contribute the following:

  • We study the cache topology, inclusiveness, and speculation window size on Apple CPUs (Section 4.1, 4.2, and 4.5).
  • We present a new speculative-execution technique to timerlessly distinguish cache hits from misses (Section 4.3).
  • We tackle the problem of constructing eviction sets in the case of low resolution or even non-existent timers, adapting prior approaches to work in this setting (Section 4.4).
  • We demonstrate timerless Spectre attack PoCs with near perfect accuracy, across Safari, Firefox and Tor (Section 4.6).
  • We mount transient-execution attacks in Safari, showing how we can read from arbitrary 64-bit addresses despite Apple’s address space separation, low-resolution timer, caged objects with 35-bit addressing, and value poisoning countermeasures (Section 5).
  • We demonstrate an end-to-end evaluation of our attack, showing how attackers can recover sensitive website content as well as the target’s login credentials (Section 6).

In essence, the iLeakage exploit can be implemented in either JavaScript or WebAssembly, and will allow an attacker's malicious web page, runing in a browser tab, to recover the desired data from another page. In order for this to work, the victim must visit a malicious attack site, and the exploit code needs to monitor the hardware for cache hits vs cache misses, which will take around five minutes. Once it has done this, it can then use the window.open() function to open pages which will share the rendering process with the attacker page, making its memory accessible. Even if the user closes the page, the attack will continue, since the memory is not reclaimed immediately.

The researchers disclosed their technique to Apple on 12 September 2022, upon which Apple requested an embargo on the publication of their work and set about refactoring the Safari multi-process architecture to include mitigation features. As of today, the mitigation feature is present in Safari Technology Preview versions 173 and newer, but is not enabled by default and is hidden in an internal debug menu. Users of MacOS Sonoma can enable it fairly easily, but users of earlier versions who have not updated will first need to download and install the appropriate Safari Technology Preview.

In addition to their deeply technical paper, which will be presented at CCS '28 in Copenhagen late next month, the researchers have set up a web site which is much easier to follow, where you can find their FAQ which explains the attack and also presents step-by-step instructions for enabling mitigation in Safari. There are also some videos demonstrating the attack in practice.

There is no need to panic, however; this is an extremely complex and technically challenging attack technique which depends upon a deep understanding of both the Apple Silicon processor architecture and the internals of the Safari browser (it will not work against other browsers, for example, although it could be adapted). A real attack in the wild is vanishingly improbable, and in fact, by the time that a threat actor could come up with one, it is likely that we will all have moved on to new processors with effective mitigations in hardware.

Kim, Jason, Stephan van Schaik, Daniel Genkin and Yuval Yarom, iLeakage: Browser-based Timerless Speculative Execution Attacks on Apple Devices, CCS '23, Copenhagen, Denmark, 26 - 30 November 2023. Available online at https://ileakage.com/files/ileakage.pdf.

Kim, Jason, Stephan van Schaik, Daniel Genkin and Yuval Yarom, iLeakage: Browser-based Timerless Speculative Execution Attacks on Apple Devices, web site, October 2023. Available at https://ileakage.com/.

Upcoming Courses

These news brief blog articles are collected at https://www.lesbell.com.au/blog/index.php?courseid=1. If you would prefer an RSS feed for your reader, the feed can be found at https://www.lesbell.com.au/rss/file.php/1/dd977d83ae51998b0b79799c822ac0a1/blog/user/3/rss.xml.

Creative Commons License TLP:CLEAR Copyright to linked articles is held by their individual authors or publishers. Our commentary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and is labeled TLP:CLEAR.

Tags:
Permalink