Understanding the Spectre Vulnerability and Browser Mitigations

Spectre

The Spectre vulnerability is easy to construct and can cause severe damage because it exploits a hardware‑level flaw that allows speculative execution to leak data across security boundaries.

How Memory Works

Computers consist of storage (RAM, disks), a CPU, and I/O devices. Programs are loaded from storage into the CPU, which performs calculations using data fetched from memory. Because memory access is slow, CPUs use multiple levels of cache to speed up repeated reads.

Side‑Channel Attacks

A side‑channel (or side‑channel) attack occurs when unintended emissions—such as timing, power consumption, electromagnetic radiation, or acoustic signals—leak information about secret data. By measuring these side‑effects, an attacker can infer the hidden values.

Example: guessing a password character by measuring the time the program takes to reject each guess. When the first character matches, the program spends slightly longer (e.g., 0.1 ms) before reporting failure, revealing the correct character.

CPU Speculative Execution

When the CPU waits for a memory load, it may predict the outcome and execute subsequent instructions ahead of time. If the prediction is correct, performance improves; if not, the CPU rolls back register changes but cannot roll back cache side‑effects.

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

Attack Principle

By forcing the CPU to speculatively access out‑of‑bounds memory, an attacker can cause the CPU to load secret data into the cache. Measuring the access time to different cache lines then reveals which data was cached, leaking the secret.

Typical steps:

Place a small, legal array (A) in attacker‑controlled memory.

Speculatively read A[x] where x is out of bounds, causing the CPU to also read a victim’s memory location.

Observe that the cache line containing the victim data is now fast to access.

Impact on the Web

JavaScript can implement the above attack with only a few lines, allowing arbitrary memory reads across origins when pages share the same process. This threatens any site that handles sensitive user data.

if
(index < array.length){
index = array[index | 0];
index = (((index * TABLE_STRIDE) | 0) & (TABLE_BYTES - 1)) | 0;
localJunk ^= probeTable[index | 0] | 0;
}

Browser Mitigation Strategies

Cache Recommendation Settings

Use Cache-Control: private and Vary: Cookie to limit shared caching of user‑specific responses.

Disable High‑Resolution Timers

Browsers reduce the precision of performance.now() (to ~5 µs) and restrict 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 (window.opener).

Cross‑Origin Opener Policy (COOP)

Setting 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 ensures only explicitly shared cross‑origin resources are loaded.

Cross‑Origin Read Blocking (CORB)

CORB blocks certain MIME types (e.g., JSON) from being rendered in a way that would expose their raw bytes to other origins, reducing the data available for side‑channel extraction.

References

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

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

Conclusion

Browser mitigations can raise the cost of exploiting Spectre but cannot eliminate the underlying hardware flaw; full mitigation would require changes at the CPU design level, which would impact performance.