4

In the wake of recent news of CPU bugs like Meltdown and Spectre which rely on precise(-ish) measurments of elapsed time, I find myself in the mood for disabling things like window.performance.now() in my browser (apart from other mitigations, obviously).

  • Is it possible to disable a particular JS API function in either recent Firefox or Chromium? (Preferably by configuration, but I'm also up for compiling from sources if needed.)
  • If so, does it make sense to do so?
kralyk
  • 161
  • 3
  • 6
    It certainly makes sense, Firefox is going to reduce timer resolution because of this: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ – mr.spuratic Jan 04 '18 at 10:46
  • `performance.now()` isn't as high-res as you might think: `performance.now()-performance.now()` == -0.005 in chrome – dandavis Jan 04 '18 at 19:10
  • @dandavis That difference is not representative of the timer's actual obtainable resolution, refer to the Mozilla statement linked by mr.spuratic and the paper linked therein. – kralyk Jan 05 '18 at 10:20
  • @kralyk: how is calling it twice in a row not representative, or is there a way to call it faster? – dandavis Jan 05 '18 at 19:49
  • @dandavis There isn't a way to call it faster, but you can still extract high precision by measuring the timer rounding edges. If you want to know how this is done please read the [linked paper](https://gruss.cc/files/fantastictimers.pdf). – kralyk Jan 06 '18 at 10:27

1 Answers1

1

Before the browsers get patched, you can write a user script to replace these DOM objects with dummies or delete the performance property altogether.

This is mostly a development feature and public website shouldn't need it to function anyways.

However, due to stupid "features" like NaCl/WebAssembly and WebGL, there may be many other ways to do a timing side channel attack in a browser.

billc.cn
  • 3,852
  • 1
  • 16
  • 24
  • 4
    Just a note: It may be difficult to truly make these properties inaccessible. The user script would need to run before any other code in every context (frames, web workers, etc.), and ensure they are not still accessible through object prototypes. An attacker might not go that far though. – Alexander O'Mara Jan 04 '18 at 12:08
  • don't forget about web workers: altered dom/bom handles will be fresh in the clean worker context. – dandavis Jan 04 '18 at 19:08
  • @AlexanderO'Mara: An extension could do the work? – Crouching Kitten Jan 05 '18 at 13:22
  • @CrouchingKitten Maybe. I'm not really sure if either a user script or a Web Extension have the necessary API's. – Alexander O'Mara Jan 05 '18 at 13:59
  • @AlexanderO'Mara: if it runs first the script only need to break/clobber the window property. A cleaver hacker can restore new copies, say from a new iframe's window object, but it should stop "drive bys" – dandavis Jan 05 '18 at 19:58