Understanding Spectre: Speculative Execution, Side‑Channel Attacks, and Browser Mitigations

ConardLi introduces the Spectre vulnerability, describing why browsers have devoted extensive effort to mitigate it and what makes it both easy to construct and highly dangerous.

Memory Operation

Computers consist of storage (memory, disks), a CPU, and I/O devices. The CPU loads programs from storage, performs calculations using data from memory, and outputs results to displays. Memory is organized as a large array of small cells and is layered with multiple cache levels to hide latency.

When the CPU reads data, it may create a cached copy; subsequent accesses to the same data are faster, while uncached accesses are slower.

Side‑Channel (Side‑Channel) Attacks

A side‑channel occurs when unintended signals (timing, power, electromagnetic emissions, etc.) leak information about secret data. By measuring the time taken for certain operations, an attacker can infer the values being processed.

Example: guessing a password character by character and observing that the response time increases by ~0.1 ms when a guessed character matches, allowing the attacker to recover the password in linear time.

CPU Speculative Execution

Because memory access is slow, CPUs predict which instructions will be needed next and execute them speculatively. If the prediction is correct, performance improves; if not, the CPU rolls back register changes but the effects on the cache remain.

if (Memory === 0) {
  // perform first calculation
  // perform second calculation
  // perform third calculation
}

If the CPU speculatively executes a branch that accesses out‑of‑bounds memory, the out‑of‑bounds read can leave a trace in the cache even though the architectural state is rolled back.

Attack Principle

The attacker allocates a small array Tools in their own memory, then forces the CPU to speculatively read Tools[A[x]] where A[x] indexes beyond the array. The speculative read brings the victim’s secret value into the cache. By measuring access times to each element of Tools , the attacker identifies which element is fast (cached) and thus learns the secret byte.

Impact on the Web

JavaScript can implement the above steps, allowing a malicious page to read data from other origins that share the same browser process. This makes cross‑site data leakage possible.

Browser Mitigations

Cache Recommendations

Use Cache-Control: private and, when responses depend on cookies, add Vary: Cookie to limit shared caching.

Disabling High‑Resolution Timers

Browsers reduce the precision of performance.now() (to ~5 µs) and block SharedArrayBuffer to make precise timing attacks harder.

rel="noopener"

When opening untrusted pages, add rel="noopener" to prevent the new window from sharing the same browsing context group.

Cross‑Origin Opener Policy (COOP)

Setting the HTTP header Cross-Origin-Opener-Policy: same-origin isolates windows from different origins into separate context groups.

Cross‑Origin Embedder Policy (COEP)

Using Cross-Origin-Embedder-Policy: require-corp forces the page to load only resources that explicitly allow cross‑origin sharing.

Cross‑Origin Read Blocking (CORB)

Browsers block certain MIME types (e.g., JSON) from being rendered as images, preventing malicious pages from pulling sensitive data into the renderer’s memory where Spectre could read it.

Conclusion

While these strategies raise the cost of exploiting Spectre on the web, they cannot eliminate the underlying hardware flaw; speculative execution and caching are fundamental to modern CPUs, and any mitigation inevitably trades performance for security.

References

https://www.bilibili.com/video/av18144159/

https://zhuanlan.zhihu.com/p/32784852