January 3, 2018 9:45 pm

Mitigating speculative execution side-channel attacks in Microsoft Edge and Internet Explorer

Today, Google Project Zero published details of a class of vulnerabilities which can be exploited by speculative execution side-channel attacks. These techniques can be used via JavaScript code running in the browser, which may allow attackers to gain access to memory in the attacker’s process.

Microsoft has issued security updates (KB4056890) with mitigations for this class of attacks. As part of these updates, we are making changes to the behavior of supported versions of Microsoft Edge and Internet Explorer 11 to mitigate the ability to successfully read memory through this new class of side-channel attacks.

Initially, we are removing support for SharedArrayBuffer from Microsoft Edge (originally introduced in the Windows 10 Fall Creators Update), and reducing the resolution of performance.now() in Microsoft Edge and Internet Explorer from 5 microseconds to 20 microseconds, with variable jitter of up to an additional 20 microseconds. These two changes substantially increase the difficulty of successfully inferring the content of the CPU cache from a browser process.

We will continue to evaluate the impact of the CPU vulnerabilities published today, and introduce additional mitigations accordingly in future servicing releases.  We will re-evaluate SharedArrayBuffer for a future release once we are confident it cannot be used as part of a successful attack.

— John Hazen, Principal PM Lead, Microsoft Edge

Join the conversation

  1. Is Microsoft going to release the IE11 fix for Windows 8.1 (‘Metro’ IE11) as well? There are small Intel Atom tablets that works better with Windows 8.1 than 10 version. And Windows 8.1 is still officially supported OS.

    Thanks.

  2. Firstly, Spectre and Meltdown are indeed extremely serious security issues.
    Many vendors, rightfully, doing emergency fixes including temporarily reducing timer precision.

    However, I have seriously grave concerns about Mozilla/FireFox’s decision to reduce performance.now() precision to 2ms — there are unanticipated major side effects, including one that will reduce security. I hope Microsoft doesn’t copy planned FireFox’s 2ms precision reduction.

    MAJOR SIDE EFFECT 1:

    The precision degradation is so massive (even at 60Hz) — affecting fullscreen WebGL and WebVR majorly — that I have heard from a friend that a site that plans to automatically detect the 2ms imprecision and automatically prompt the user with step-by-step instructions to fix the imprecision for their site. As a global FireFox setting, this is problematic from a security perspective. A global setting changed.

    I think the safer solution is:

    “In an absolute emergency: Personally if there’s a duress to reduce timer precision, then a temporary permissions API (cameras and fullscreen have more security/privacy fears) to prompt the user for permission to stay at 5us precision. At least during the duration of security studying, until being reverted to maximized precision.”

    MAJOR SIDE EFFECT 2:

    As a past game developer (most standards writers aren’t game developers), let me tell you:

    Accurate gametimes are necessary for accurate calculations of 3D object positions, especially in full-screen WebGL games.

    At sub-refresh-cycles, animations should still use sub-millisecond accuracy to prevent jank, when calculating time-based animations (e.g. calculating object positions based on time) — that’s what 3D graphics often do compensating for fluctuating frame rates, they calculate object world positions based on gametime.

    That means 1000 inch per second moving balls (~60mph) can be wrongly mispositioned by 2 inches if the gametime is off by 2 millisecond. That can mean goal/nogoal. Fastballs, baseballs, hockey pucks can go much faster than this. Low-precision gametimes will ruin a lot of HTML5 and WebGL game programming.

    Gametimes need sub-millisecond accuracy, especially full-screen WebGL games, because they calculate real-world 3D object positions based on gametime.

    That way everything looks correct regardless of framerate. Framerates fluctuate all over the place, so video games using 3D graphics use gametime to calculate the position of everything. 3D object positions are calculated based on gametime. Wrong gametime means everything janks like crazy in full screen WebGL games.

    Again, this is for 60 Hz. I’m not even talking about higher refresh rates. 1ms gametime errors create noticeable motion-fluidity flaws in 60Hz full-screen WebGL games!

    Things even janks crazily with 5ms and 8ms gametime errors on a 60Hz display. You’re in the driver’s seat of a 300mph car, in a racing game — a 2ms gametime error becomes large even on a 60 Hz display. Jank/jerkiness/stutter can get huge even at sub-refresh-cycle levels even on a 60 Hz display, even with sub-refresh-cycle errors.

    Also, don’t forget that there are advantages to frame rates above refresh rates in reducing latency: https://www.blurbusters.com/faq/benefits-of-frame-rate-above-refresh-rate/

    My prediction is FireFox may get a tsunami wave of huge complaints from game designers suddenly hit by major precision reductions in ability to calculate gameworld positions.

    MAJOR SIDE EFFECT 3:

    Depending on how timer precision is degraded, it potentially eliminates educational motion tests in web browsers. Many scientific tests such as http://www.testufo.com/ghosting and http://www.testufo.com/frameskipping (display overclocking) is heavily dependant on perfect frame rate synchronization, and the site is able to detect whenever Chrome misses a frame.

    Peer reviewed papers have already been written based on browser motion tests (including http://www.blurbusters.com/motion-tests/pursuit-camera-paper …) thanks to browser’s ability to achieve perfect refresh rate synchronization)

    Even one of my sites, TestUFO, depending on how the site is degraded in upcoming FireFox A/B tests (new versus old browser) — it may be forced to do something similar to the popup in “MAJOR SIDE EFFECT 1” — for specific kinds of peer-reviewed scientific motion testing. Is there a way for me to tell users how to whitelist only one site (TestUFO.com) for high-precision timers, without doing it as a global setting? (Thought exercise for W3C)

    The TestUFO website already automatically displays a message telling TestUFO users to switch web browsers instead of IE/Edge for 120Hz testing, due to IE/Edge continued violation of Section 7.1.4.2 of HTML 5.2. More than 50% of TestUFO visitors are using a refresh rate other than 60 Hz.

    MAJOR SIDE EFFECT 4:

    It makes WebVR useless.

    Its premise (without creating nausea/headaches) is heavily dependant on accurate gametimes for accurate positions of 3D objects (see MAJOR SIDE EFFECT 2 above).

    MAJOR SIDE EFFECTS 5-100

    I have a much longer list, but for brevity, I am shortening this email to point out the graveness of FireFox’s decision.

    CONCLUSION

    The approach by the FireFox team should be refined.

    If continued short-term emergency mitigation is absolute critical, it should includes a Permissions API (much like Full Screen mode and WebRTC camera permissions) to case-by-case ask the user for permission to use high-precision timers (allowing 5us or 1us precision).

    If absolutely necessary, this could even be limited to Organization Validation HTTPS sites, combined with only exclusive same-origin use, even triggered by a click, and only after confirming via a popup Permission API (like for WebRTC), that 5us/1us precision becomes granted to that particular site.

    Long-term, these restrictions should be removed once the underlying causes of Spectre/Meltdown becomes solved. However, massive precision reductions, that forces web developers to give instructions to visitors how to configure their web browsers, is a less secure solution.

    I hope Microsoft doesn’t copy planned FireFox’s 2ms precision reduction.

    Thanks,
    Mark Rejhon
    Founder, Blur Busters / TestUFO
    (Past Invited Expert, W3C Web Platform Working Group for HTML 5.2)