

The load after the branch can execute before the CPU verifies that the branch actually did fall through. In this case, they will observe that the branch always falls through. Modern CPUs are able to execute the bounds check branch ( jae) and the subsequent load ( mov (%rdx,%rcx,4), %ecx) in parallel. Mov (%rdx,%rcx,4), %ecx Load intArray->vector. This loadsĬmp 0x18(%rsi), %ecx %ecx has the index. The compiler will have to emit a bounds check when it translates this high-level JavaScript operation into a lower-level form: if (((unsigned) index) >= ((unsigned) intArray->length))Ĭompiling this on x86 CPUs results in the following instructions: mov 0x10(%rsi), %rdx %rsi has intArray. In this example, let’s assume that intArray is known to our JavaScript engine to be a reference to a Int32Array instance, but that we have not proved that index is in bounds of intArray.length. Most discussions about Spectre have involved bounds checks, so this section considers that case as well. To understand how Spectre works, it’s useful to think about how security-sensitive programming language operations (like any property access in JavaScript) get executed in JavaScriptCore on a modern processor. Hence, Spectre is not just an attack on JavaScriptCore itself but also everything that is callable from JavaScript. Spectre breaks this property of JavaScriptCore because untrusted JavaScript or WebAssembly now has a theoretical path to reading all of the host process’s address space.ĭOM APIs and system APIs called by DOM APIs also use branches to enforce their security properties, and those are callable from JavaScript.
#Spectre meaning code
It should be possible to load untrusted JavaScript or WebAssembly code into your process without the risk of your process’s memory being leaked to the JavaScript code except in cases where you explicitly export data to JavaScript via our C or Objective-C binding API. JavaScriptCore is meant to be a secure language virtual machine.
/ghosts-of-past-461628677-59a074be845b340011fd7b7d.jpg)
For example, if some type contains an integer at offset 8 while another type contains a pointer at offset 8, then an attacker could use Spectre to bypass the type check that is supposed to ensure that you can’t use the integer to craft an arbitrary pointer. This could allow an attacker to read arbitrary memory. Almost all bounds checks can be bypassed to read arbitrarily out-of-bounds. The most impacted subsystem is JavaScriptCore (WebKit’s JavaScript engine). Spectre means that branches are no longer sufficient for enforcing the security properties of read operations in WebKit.
#Spectre meaning full version
You can check if your Safari and WebKit are patched by verifying the full version number in About Safari. High Sierra 10.13.2 Supplemental Update.

The first of these mitigations shipped on Jan 8, 2018: This document explains how Spectre and Meltdown affect existing WebKit security mechanisms and what short-term and long-term fixes WebKit is deploying to provide protection against this new class of attacks. Therefore, Spectre mitigations that fix the branch problem also prevent an attacker from using WebKit as the starting point for Meltdown. Mounting a Meltdown attack via JavaScript running in WebKit requires first bypassing branch-based security checks, like in the case of a Spectre attack. Not all CPUs are affected by Meltdown and Meltdown is being mitigated by operating system changes. Meltdown means that userland code, such as JavaScript running in a web browser, can read kernel memory. Spectre means that an attacker can control branches, so branches alone are no longer adequate for enforcing security properties.
