ileakage.com Open in urlscan Pro
185.199.110.153  Public Scan

Form analysis
0 forms found in the DOM

Text Content

ILEAKAGE: BROWSER-BASED TIMERLESS SPECULATIVE EXECUTION ATTACKS ON APPLE DEVICES



OVERVIEW OF THE ILEAKAGE ATTACK.

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.

View Our Paper Cite (BibTeX)

CITE ILEAKAGE

@inproceedings{ileakage, title = {iLeakage: Browser-based Timerless Speculative
Execution Attacks on Apple Devices}, author = {Jason Kim and Stephan van Schaik
and Daniel Genkin and Yuval Yarom}, booktitle = {ACM CCS 2023}, year = {2023}, }
Copy to Clipboard Close

DEMO VIDEOS.

RECOVERING INSTAGRAM CREDENTIALS

We show a scenario where the target uses an autofilling credential manager
(LastPass in this demo) to sign into Instagram with Safari on macOS.



RECOVERING GMAIL INBOX CONTENT

Assuming the target is signed into Google on Safari for iOS, we recover the
subject lines of the Gmail account's most recent messages on an iPad.



RECOVERING YOUTUBE WATCH HISTORY

We recover YouTube watch history from the Chrome browser for iOS, which is a
shell on top of Safari's browsing engine due to Apple's App Store policy.



THE PEOPLE BEHIND ILEAKAGE.

 * Jason Kim Georgia Institute of Technology
 * Stephan van Schaik University of Michigan
 * Daniel Genkin Georgia Institute of Technology
 * Yuval Yarom Ruhr University Bochum


ARCHITECTURE.FAIL

Check out our lab website!

Contact us at info@ileakage.com




FREQUENTLY ASKED QUESTIONS.

THE BASICS


IS MY APPLE DEVICE AFFECTED?

Yes (with a very high chance), if you have a device running macOS or iOS with
Apple's A-series or M-series CPUs. This includes all recent iPhones and iPads,
as well as Apple's laptops and desktops from 2020 and onwards.


WHY IS ILEAKAGE SIGNIFICANT?

Code running in one web browser tab should be isolated and not be able to infer
anything about other tabs that a user has open. However, with iLeakage,
malicious JavaScript and WebAssembly can read the content of a target webpage
when a target visits and clicks on an attacker's webpage. This content includes
personal information, passwords, or credit card information.


HOW CAN I DEFEND AGAINST ILEAKAGE?

At the time of public release, Apple has implemented a mitigation for iLeakage
in Safari. However, this mitigation is not enabled by default, and enabling it
is possible only on macOS. Furthermore, it is marked as unstable. We will keep
this FAQ updated as Apple pushes more iOS and macOS updates. If you wish to
enable the mitigation on your Mac now, below are the steps. Please note: this
mitigation is compatible only with macOS Ventura 13.0 and higher.

First, the Terminal app needs full disk access:

 1. Open the System Settings app, which is likely to be on your Dock. You can
    also find the app in the Launchpad or Spotlight search.
 2. Navigate to the Privacy & Security tab.
 3. Click the menu item for Full Disk Access, and then the '+' button. You may
    be prompted for your credentials here.
 4. A Finder window will appear. Select Applications on the sidebar to the left,
    and scroll near the bottom of the list to find a folder named Utilities.
 5. Within the Utilities folder is the Terminal app. Click on it, followed by
    the Open button in Finder.

If you have updated to macOS Sonoma 14.0 or higher:

 1. Open the Terminal app. You can find this in the Launchpad, or through
    Spotlight search.
 2. Copy and paste the following command (in magenta), and press the Return key
    to run it:
    defaults write com.apple.Safari IncludeInternalDebugMenu 1.

If you are on an earlier macOS version (macOS Ventura 13.0 to 13.6):

 1. We recommend enabling automatic updates and updating to macOS Sonoma.
    However, if you wish to enable the mitigation on older macOS versions,
    follow these steps:
 2. First, download the version of Safari Technology Preview tht matches your
    macOS version from Apple's download page.
 3. Double-click the downloaded installer with the .pkg file extension, and
    follow its directions until Safari Technology Preview is installed.
 4. Open the Terminal app. You can find this in the Launchpad, or through
    Spotlight search.
 5. Copy and paste the following command (in magenta), and press the Return key
    to run it:
    defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1.

This enables Safari's hidden debugging menu. Then, follow these steps:

 1. Open Safari (or Safari Technology Preview). On the menu bar, you should see
    a new entry named Debug.
    
 2. Click the Debug menu. This opens a long dropdown. Click on WebKit Internal
    Features.
    
 3. This opens another long dropdown to the side. Scroll down to the bottom of
    this new dropdown, where you'll find an entry called Swap Processes on
    Cross-Site Window Open.
    
 4. Click this entry. A checkmark should appear to the left of it, like the
    screenshot below.
    

Afterwards, you're all set! To disable the mitigation, repeat steps 1-4 from
above, and the checkmark will disappear. To disable the hidden debugging menu,
open the Terminal app, copy and paste the following command (depending on your
OS version), and press the Return key to run. The changes will apply the next
time you start Safari (or Safari Technology Preview).

 * For Safari (macOS Sonoma 14.0 and higher):
   defaults write com.apple.Safari IncludeInternalDebugMenu 0
 * For Safari Technology Preview (macOS Ventura 13.0 to 13.6):
   defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 0


DOES ENABLING LOCKDOWN MODE OR DISABLING JAVASCRIPT MITIGATE ILEAKAGE?

Lockdown Mode does mitigate our work by disabling just-in-time (JIT) compilation
in Safari, which is a performance feature used by iLeakage to build its attack
primitives. However, Lockdown Mode changes device behavior in other aspects. For
example, some message attachments and unknown FaceTime calls may be blocked. See
Apple's documentation for a complete list.

Furthermore, since iLeakage is written in JavaScript, disabling it also
mitigates our work. However, disabling JavaScript may cause Safari to render
some websites incorrectly or incompletely, and some advanced web features such
as online payments may not work.


IS THIS ATTACK DETECTABLE?

iLeakage is highly unlikely to be detected, since the attack runs in Safari and
does not leave traces in the system's log files. However, traces of an attacker
webpage hosting iLeakage may be present in the browser's cache of pages it has
recently visited.


HAVE MALICIOUS ACTORS USED ILEAKAGE IN PRACTICE?

So far, we do not have evidence that iLeakage has been or not been abused.
However, we note that iLeakage is a significantly difficult attack to
orchestrate end-to-end, and requires advanced knowledge of browser-based
side-channel attacks and Safari's implementation.


AM I AT RISK IF I USE CREDENTIAL MANAGERS?

Not for the most part. In fact, we encourage using credential managers as
opposed to trying to remember all of your passwords. In general, this is a
better approach than reusing passwords or storing them insecurely. While
iLeakage can recover credentials that are autofilled into a webpage, we note
that many platforms require user interaction for autofill to occur.


WHEN DID YOU NOTIFY APPLE?

We disclosed our results to Apple on September 12, 2022 (408 days before public
release).

FOR TECH-SAVVY READERS


WHAT ARE JAVASCRIPT AND WEBASSEMBLY?

JavaScript and WebAssembly are two programming languages that make up the
backbone of interactive webpages, such as online games and video streaming
services. JavaScript can update the content of the website directly, while
WebAssembly is used for high-performance web applications. Ultimately,
WebAssembly interfaces with JavaScript to deliver dynamic content to users.
Since both are sandboxed in a browser environment, side-channel attacks are
notably more difficult to implement in these languages. However, the impact is
drastically greater, as browsers execute both types of code automatically and do
not require the user to download the malicious program.


WHAT IS A SIDE CHANNEL?

Most computer bugs arise from mistakes in programming, such as missing bounds
checks or use-after-frees. However, a side-channel attack exploits the
implementation of a computer system to attack it, even if the program it runs is
a secure algorithm. Systems can leak sensitive data through sound,
electromagnetic radiation, or thermal throttling, just for a few examples.

Many side channels, including ones we use for iLeakage, comes from the CPU's
microarchitecture. Whenever an attacker and target run on the same CPU, they
share the CPU's internal resources such as cores, caches, and internal buffers.
Sharing resources leads to contention, and contention can be measured indirectly
through several variables like timing or power consumption. These measurements
leave fingerprints on the target's behavior on the CPU. Accordingly, an attacker
can abuse this to make inferences about the target's secrets even if they are
isolated at the process level or the hypervisor level.


WHAT ARE SPECULATIVE EXECUTION ATTACKS?

Virtually all modern CPUs use a performance optimization where they predict if a
branch instruction will be taken or not, should the outcome not be readily
available. Once a prediction is made, the CPU will execute instructions along
the prediction, a process called speculative execution. If the CPU realizes it
had mispredicted, it must revert all changes in the state it performed after the
prediction. Both desktop and mobile CPUs exhibit this behavior, regardless of
manufacturer (such as Apple, AMD, or Intel).

Spectre is a hardware vulnerability in virtually all modern CPUs that occurs
when speculative execution backfires. While the CPU should ideally revert all
changes in state, speculative execution leaves traces in the CPU's
microarchitectural state and especially the cache. A Spectre attack coerces the
CPU into speculatively executing the wrong flow of instructions. If this wrong
flow has instructions depending on sensitive data, their value can be inferred
through a side channel even after the CPU realizes the mistake and reverts its
changes. An adversary can abuse this behavior to read data that they cannot
normally access through program semantics. Because speculative execution is an
important part of CPU performance that is infeasible to simply remove as a
countermeasure, Spectre continues to be dangerous to software even years after
its discovery.


HOW IS ILEAKAGE DIFFERENT FROM SPECTRE?

Since the original Spectre exploit, browser vendors had significantly hardened
browsers against attacks based on speculative and transient execution. For the
case of Safari, this includes 35-bit addressing and the value poisoning, one
process per tab isolation policy, as well as a low resolution timer.

Nonetheless, iLeakage is the first demonstration of a speculative execution
attack against Apple Silicon CPUs and the Safari browser. In particular, we show
that speculative execution attacks are possible on Apple's latest A-series and
M-series architectures, despite Apple's side channel hardening. More
specifically, we first devise an empirical method to recover the cache
organization of Apple CPUs, since it is not publicly documented. We then use
this information to develop a gadget that can distinguish cache hits from misses
even in the absence of a cycle-accurate timer, which is the case for both native
and browser environments for Apple devices. We use this gadget as both a test to
generate cache eviction sets and as a covert channel. Finally, we migrate these
techniques to the Safari browser, where we make Safari run code designed for one
datatype on our maliciously crafted object of the wrong type while the CPU is
performing speculative execution. Ultimately, we achieve a out-of-bounds read
anywhere in the address space of Safari's rendering process.


HOW DOES ILEAKAGE WORK?

In order to construct iLeakage, we first reverse engineer the cache topology on
Apple Silicon CPUs. We then overcome Apple's timer limitations using a new
speculation-based gadget, which allows us to distinguish individual cache hits
from cache misses, despite having access to only low resolution timers. We also
demonstrate a variant of this gadget that uses no timers, leveraging race
conditions instead. After using our speculation-based gadget to construct
eviction sets, we proceded to analyze Safari's side channel resilience. Here, we
bypass Safari's 35-bit addressing and the value poisoning countermeasures,
creating a primitive that can speculatively read and leak any 64-bit pointer
within Safari's rendering process. Combining this with a new method for
consolidating websites from different domains into the same address space, we
are able to mount a speculative type confusion attack that leaks sensitive
information.


IS THERE MORE TECHNICAL INFORMATION?

The download button at the top of this website links to an academic paper, also
available through this link. Our paper will appear at the 2023 ACM Conference on
Computer and Communications Security (CCS).

MISCELLANEOUS


WHAT ABOUT OTHER WEB BROWSERS?

On macOS, other popular browsers such as Chrome, Firefox and Microsoft Edge use
different JavaScript engines. Since iLeakage exploits idiosyncrasies in Safari's
JavaScript engine, these nuances suffice to deter iLeakage from working on them.

However, iOS has a different situation. Due to Apple's App Store and sandboxing
policies, other browser apps are forced to use Safari's JavaScript engine. That
is, Chrome, Firefox and Edge on iOS are simply wrappers on top of Safari that
provide auxiliary features such as synchronizing bookmarks and settings.
Consequently, nearly every browser application listed on the App Store is
vulnerable to iLeakage.


IS THE LOGO FREE TO USE?

Yes, we have SVG and PNG versions of the iLeakage logo. While the logo contains
a modified version of the Safari logo, we note the Safari logo is in the public
domain at Wikimedia Commons. Furthermore, it is not on Apple's list of
trademarks.

ILEAKAGE IN THE NEWS.

 * Hackers can force iOS and macOS browsers to divulge passwords and much more
 * 'iLeakage' Flaw Can Prompt Apple's Safari to Expose Passwords, Sensitive Data
 * Side channel attacks take bite out of Apple silicon with iLeakage exploit
 * New iLeakage attack steals emails, passwords from Apple Safari
 * iLeakage flaw could force iPhones and Macs to divulge passwords and more
 * New iLeakage attack can steal your emails and passwords on iPhone and Mac —
   how to stay safe
 * iLeakage Attack Exploits Safari to Steal Sensitive Data From Macs, iPhones
 * iLeakage attack resurrects Spectre with password and website data extraction
 * iLeakage: New Safari Exploit Impacts Apple iPhones and Macs with A- and
   M-Series CPUs
 * iPhone and Mac users beware - this dangerous new iOS and macOS security flaw
   might see you give up your password without knowing
 * ‘iLeakage’ Attack Can Force Apple Safari To Reveal Passwords
 * iLeakage Vulnerability Found In Apple Silicon Can Leak Passwords To Attackers
 * #iLeakage: All Apple CPUs Vulnerable — No Patch in Sight
 * Boffins declare open season on Apple Safari
 * Onderzoekers vinden Spectre-achtig lek in Safari dat wachtwoorden kan
   vrijgeven
 * iLeakage × Safari: Spectre nun auch bei Apple-CPUs ein Thema
 * Apple processors vulnerable to sensitive data leaks
 * iLeakage: Safari unzureichend vor Spectre-Seitenkanalangriff geschützt
 * Patch...later? Safari iLeakage bug not fixed
 * iLeakage Hackers Can Read Gmail On All 2020 Or Later iPhones And Macs
 * Apple Vulnerability Can Expose iOS and macOS Passwords, Safari Browsing
   History
 * Newly discovered ‘iLeakage’ exploits speculative execution in Apple devices
 * iLeakage Attack: Theft of Sensitive Data from Apple’s Safari Browser
 * 'iLeakage' Attack on Apple Devices: A Silent Threat Lurking in the Shadows
 * iLeakage updates Spectre for novel info-stealing side-channel attack
 * No patches yet for Apple iLeakage side-channel attack
 * SILENT DANGER Billions of iPhone owners warned their Gmail inbox could be
   exposed in silent iLeakage hack to steal data

ACKNOWLEDGMENTS.

This research was supported by the Air Force Office of Scientific Research
(AFOSR) under award number FA9550-20-1-0425; an ARC Discovery Project number
DP210102670; the Defense Advanced Research Projects Agency (DARPA) under
contract HR00112390029 and W912CG-23-C-0022; the Deutsche Forschungsgemeinschaft
(DFG, German Research Foundation) under Germany's Excellence Strategy - EXC 2092
CASA - 390781972; the National Science Foundation under grant CNS-1954712; and
gifts by Cisco and Qualcomm.

The views and conclusions contained in this website are those of the authors and
should not be interpreted as representing the official policies, either
expressed or implied, of the U.S. Government.

Parts of this work were undertaken while Yuval Yarom was affiliated with the
University of Adelaide.

Copyright © 2023 Georgia Institute of Technology. All rights reserved.