Security and privacy considerations for DOMHighResTimeStamp resolution

[igrigorik]

Note: the intent of this issue is to provide a reference and track the ongoing research, discussions, proposals, and implementation techniques employed by various browsers on how they expose or provide access to high resolution time.

---

Paraphrasing Section 7.1: Clock resolution...

Access to accurate timing information, both for measurement and scheduling purposes, is a common requirement for many applications... This specification defines an API that provides sub-millisecond time resolution, which is more accurate than the previously available millisecond resolution exposed by DOMTimeStamp.

... Access to the same accurate timing information can sometimes be also used for malicious purposes by an attacker to guess and infer data that they can't see or access otherwise.

To ensure that the new API does not significantly improve the accuracy or speed of such attacks, the recommended minimum resolution of the DOMHighResTimeStamp type should be inaccurate enough to prevent attacks... In order to mitigate such attacks user agents may deploy any technique they deem necessary. These techniques may include: Resolution reduction, added jitter, abuse detection and/or API call throttling.

This problem space space remains an unsolved and an evolving one. There is no existing industry consensus or a definitive set of recommendations that applies to all browsers, which is reflected in the range of different implementations and platform-specific techniques used by various browsers.

---

Relevant prior art and discussions:

1. Reducing resolution (SPECTRE and microarchitecture timing attacks): https://github.com/w3c/hr-time/issues/56
2. PING review feedback: https://github.com/w3c/hr-time/issues/20
   • Gating timestamps behind existing permission prompts: https://github.com/w3c/hr-time/issues/64
   • Related discussion on evaluated and proposed strategies: https://github.com/w3c/hr-time/issues/56#issuecomment-485583476

[yoavweiss]

Thanks for filing that!

When looking at this space, I think it's critical to understand which of the potential attack vectors are not either of:

• Spectre related (to which there are various solutions in progress, all in the realm of limiting process access to sensitive data, rather than limiting timers)
• Covered by the 5 microsecond minimum resolution.

I also think that any such remaining attack vectors are something which we should take into consideration with any of the implicit timers we have or planning to have in the platform (SharedArrayBuffers, postMessage, requestAnimationFrame, Date.now(), etc).

[tildelowengrimm]

@yoavweiss Am I correct in understanding that this is the single open issue which represents the items raised by PING during review?

[igrigorik]

@tomlowenthal per my note in the introduction..

the intent of this issue is to provide a reference and track the ongoing research, discussions, proposals, and implementation techniques employed by various browsers on how they expose or provide access to high resolution time.

As discussed in https://github.com/w3c/hr-time/issues/20#issuecomment-506804763 (please see linked doc), HR-Time as a spec offers more than sub-millisecond resolution and the intent of this thread is specifically to track ongoing discussions on various implementation strategies of providing sub-millisecond resolution. If that's what you're referring to in your comment, then yes this is the right thread to continue the conversation.

[pes10k]

Thanks for following up here everyone. Just to reiterate, there are a number of concerns with exposing / adding more HRT timers; the concern is not only that Spectre mitigations don't address all the privacy violating timing attacks on the platform. Here's an overview of the topics that came up in the previous issue, and during the calls we had.

Technical concerns

Spectre mitigations (e.g. process isolation) address only some of the ways HRT can be used to harm privacy. Exactly which attacks depend on implementation details, but a partial list include:

1: Micro architecture attacks

• Andrysco, Marc, et al. "On subnormal floating point and abnormal timing." 2015 IEEE Symposium on Security and Privacy. IEEE, 2015.
• Oren, Yossef, et al. "The spy in the sandbox: Practical cache attacks in javascript and their implications." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, 2015.
• Kohlbrenner, David, and Hovav Shacham. "On the effectiveness of mitigations against floating-point timing channels." 26th {USENIX} Security Symposium ({USENIX} Security 17). 2017.

2. History Sniffing
   • Smith, Michael, et al. "Browser history re: visited." 12th {USENIX} Workshop on Offensive Technologies ({WOOT} 18). 2018.

Would be happy to share more examples as needed…

Existing timing sources are rarer than they appear

Much of the argument is that there are already many existing HRT sources, so adding more has low marginal privacy cost. Besides being a privacy-harming way of approaching the issue (b/c of the way that functionality is hard to extract from the environment, privacy-debt-etc), we also believe that there are less of existing sources of HRT that are suggested.

The frequently cited paper, "Fantastic Timers", conflates async implicit timers (e.g. postMessage), which would be much easier to address w/o breaking existing sites, w/ synchronous timers (e.g. performance.now) which would be harder to remediate w/o breaking promised / standardized functionality (e.g. a 5us performance.now enables 2ns-resolution timing).

Process concerns

W3C generally expects to shipping implementations of a standard prior to standardization. Firefox and Safari both don't implement the core feature of the standard (namely returning high-resolution time stamps), and so the standard does not seem to meet the expected bar.

Additionally, it's not a good practice to ship this standard, under the expectation that a future standard will correct it. That removes flexibility / options from the people working on that future standard, leaves users vulnerable in the interim, and makes it difficult-to-impossible the privacy impact of the current standard while the future standard is in flux.

Not User Serving

To echo the point @samuelweiler made on the call, the user-serving case for the feature seem narrow and uncommon. Making HRT globally available, when their user-serving cases are narrow, violates basic privacy and security principals (e.g. least privilege, etc.). The user serving cases mentioned in the standard appear to be achievable with greatly restricted feature availability.

Precaution

There are mountains of papers and attacks that leverage HRT timing signals. Its worth being extremely cautious before introducing more sources of HRT into the environment then, especially (but not only) because the positive use cases seem very uncommon.

[igrigorik]

@snyderp thanks for your feedback. I feel that we're (still) talking past each other a bit here though..

• I don't think there is any disagreement in that high-resolution timestamps can introduce privacy and security implications: that's well documented in the spec
• Similarly, as Yoav noted earlier in the thread, Spectre is not the only concern to consider.

These bits, I believe, we agree on.

W3C generally expects to shipping implementations of a standard prior to standardization. Firefox and Safari both don't implement the core feature of the standard (namely returning high-resolution time stamps), and so the standard does not seem to meet the expected bar.

I disagree with this evaluation. Please see our earlier discussion in https://github.com/w3c/hr-time/issues/20#issuecomment-506804763. The specification offers multiple important features, one of which is exposing DOMHighResTimestamp, and specifically allows user agents to adjust the exposed resolution. Implementations that chose to raise it to same same resolution as Date.now(), or anything in between 5us-1ms, are compliant.

The user serving cases mentioned in the standard appear to be achievable with greatly restricted feature availability.

This touches on the same themes I covered in https://github.com/w3c/hr-time/issues/20#issuecomment-506804763. Unfortunately I'm not aware of any strategies to restrict access with reasonable consensus amongst implementers.

[yoavweiss]

Technical concerns

@snyderp - Thanks for outlining your concerns. I understand you're relatively new to the standards world, but here we typically try to be respectful of people's time and avoid sending multiple ~20 page papers as an exercise to the reader. In the future when referring to such work, it'd be great if you could link to it, and sum up the different attacks that it details.

In order to better communicate your concerns to folks on this issue, I took the liberty to try and sum up the attacks you pointed out.

1: Micro architecture attacks

• Andrysco, Marc, et al. "On subnormal floating point and abnormal timing." 2015 IEEE Symposium on Security and Privacy. IEEE, 2015.

This attack is a "pixel stealing" attack (which can reveal sensitive contents inside a cross-origin resource or iframe, or the user's history through :visited links).

It is using the following facts:

• Floating point operations on subnormal numbers take significantly longer than other floating point operations.
• SVG filters can use floating point operations of on-screen pixels against attacker-controlled arbitrary numbers.

The attack then:

• "binarizes" a certain pixel (using SVG filters) to either white or black, by scrolling the victim iframe and placing a 1x1 pixel div on top of the desired pixel.
• It amplifies the pixel by painting its color on an arbitrarily large div. This amplification is using the (Mozilla-only) element() CSS function, which can set a background color based on an arbitrary element.
• It uses SVG filters to multipliy that div against a matrix of subnormal numbers, and inspects when the result is next painted.

While the attack does use performance.now(), it doesn't really rely on its sub-millisecond characteristics and mostly relies on requestAnimationFrame(), which has 16ms granularity by default. I suspect that Date.now() would have done just fine here, and no high-precision timers are needed for this attack to be successful.

If I had to look for the root cause here, I'd probably start with the application of SVG filters across-origins in unrestricted ways (e.g. in ways that enable the element() CSS function to inspect its results).

• Kohlbrenner, David, and Hovav Shacham. "On the effectiveness of mitigations against floating-point timing channels." 26th {USENIX} Security Symposium ({USENIX} Security 17). 2017.

This fascinating talk explores mitigations to the previously described pixel-stealing vulnerability, and bugs in those mitigations.

The mitigations described:

• Move to fixed point math, rather than floating point for the relevant SVG filters.
• Move to single precision floating point math
  • Doesn't cover all cases on all hardware.
• Use of CPU flags which disable subnormal numbers
  • Apparently, this made subnormal numbers faster, which is still observable.
  • It involves a lot of complexity, and some code paths messed it up
• Remove cross-origin SVG filters entirely
  • Effective, even if taking away valuable functionality

Note that no browser considered disabling or adding a permission prompt for the use of requestAnimationFrame().

• Oren, Yossef, et al. "The spy in the sandbox: Practical cache attacks in javascript and their implications." Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, 2015.

This attack is based on the fact that some CPU caches are shared between different processes and other trust boundaries, and timing attacks can be used to inspect those caches and conclude things regarding user activity (e.g. keystroke/mouse events, presence of a user through ambient light sensors, etc).

A few highlights from the paper:

• The attack is only relevant for recent(ish) Intel processors, which share cache state between different processes. It is explicitly not available on e.g. AMD processors.
• The root-cause for that vulnerability is that cache-sharing design choice.
• The same vulnerability exists in native OSes (between processes) and VMs (between instances) that run on top of these physical processors
• The timing attack requires 50 nanosecond timer granularity, but the researchers were able to circumvent that requirement in browsers that provided coarser one by amplifying the attack, making 1 microsecond granularity sufficient (section 6.1)

IIRC, that last point is the reason the granularity of HR-time was limited to 5 microseconds.

@snyderp - Do you know how native OSes deal with that type of attacks? Are they limiting access to timers in similar scenarios? Are there other mitigations used there that we could borrow?

1. History Sniffing

• Smith, Michael, et al. "Browser history re: visited." 12th {USENIX} Workshop on Offensive Technologies ({WOOT} 18). 2018.

This paper presents four different attacks which reveal the user's history.

• CSS Paint API
  • Attacker registers a paint worklet and adds a non-visited link to the page.
  • After the above is painted, the attacker changes the link to the target site, which visited state they want to exfiltrate.
  • When a newly-turned-to-visited link is painted, the attacker's paint worklet gets called.
  • The worklet cannot directly communicate that second call to DOM JS, but it can e.g. run in a tight loop for a large number of milliseconds, enabling the DOM JS to conclude state from that.
  • This attack does not rely on high precision timers, and can be executed with Date.now().
  • The attack also has an amplified version with similar characteristics, which stores state in the worklet (through registerPaint()) and exfiltrates later on.
  • The root-cause seems to be the fact that the paint worklet is called for paints that only involve :visited state. The CVE response was to disable paint worklets for link elements in general.
• CSS 3D transforms
  • The attacker applies extremely expensive transforms to links.
  • The attacker dynamically changes the link's URL to the one they want to exfiltrate.
  • The expensive transforms have to re-paint, due to the resulting color change, dropping the page's frame rate.
  • The page's frame rate is easily observable through requestAnimationFrame() and its 16ms resolution. No need for high precision timers for this attack.
  • The attack can be amplified by flip-flopping the URL displayed from a non-visited one to a potentially-visited one.
• SVG fill-color
  • Similar to the previous attack, SVG fill color can result in many expensive paint operations, which are observable.
• JS code-cache
  • The attackers claim that they can exfiltrate history by observing if a certain script arrived from the JS code cache, by timing when its download ended (using ResourceTiming) and when it first set a global variable.
  • AFAIK, this is mitigated in Chromium, by double-keying the V8 code cache, so that such scripts will not reveal the code cache state related to other sites.
  • If the code-cache was not double keyed, this would not require high-precision timers - 100KB JS (the minimum for the attack) typically takes way more than a millisecond to parse and compile.

IMO, the root cause for all these attacks that inspect :visited links is, well... the existence of :visited links across origins. We should double-key visited links (at least by default), so that they'd be decorated on the top-level origin where the user originally clicked those links, but not on unrelated sites, running a risk of exposing the user's browser history.

Would be happy to share more examples as needed…

Could you share examples where these 3 conditions are met?

• Sub-millisecond High-precision timers were a requirement for the attack
• The current mandatory limitation to 5 microseconds is not sufficient to mitigate the attack
• The attack is not mitigated by process-isolation related initiatives

Existing timing sources are rarer than they appear

Much of the argument is that there are already many existing HRT sources, so adding more has low marginal privacy cost. Besides being a privacy-harming way of approaching the issue (b/c of the way that functionality is hard to extract from the environment, privacy-debt-etc), we also believe that there are less of existing sources of HRT that are suggested.

The frequently cited paper, "Fantastic Timers", conflates async implicit timers (e.g. postMessage), which would be much easier to address w/o breaking existing sites, w/ synchronous timers (e.g. performance.now) which would be harder to remediate w/o breaking promised / standardized functionality (e.g. a 5us performance.now enables 2ns-resolution timing).

Could you expand on how performance.now() enables 2ns resolution?

[samuelweiler]

I'm continuing some discussions in https://github.com/w3c/hr-time/issues/20

[annevk]

89 might be of interest.

I don't really understand the Firefox claim above by the way, is there a test that demonstrates the issue?

[pes10k]

@annevk if its not correct that Firefox is still reducing the precision of DOMHighResTimeStamps, thats good to know. It might be that policy has changed (this issue is > a year old), or I could have been incorrect from the gitgo, OR maybe i confused the mitigations discussed here (https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp) with whats is / was shipping at the time.

[annevk]

Precision is reduced (since yesterday modulo cross-origin isolated, which made me file #89), but the specification explicitly encourages that.

[rniwa]

FWIW, we have no plan to change the precision of 1ms for now.

[npm1]

Should we change some of the spec wording where it's mentioning 'sub-millisecond' resolution? AFAIK that's not a spec requirement, and it may be better to avoid saying this if Webkit does not provide sub-millisecond resolution.

[clelland]

@yoavweiss, it's not clear whether there's anything actionable here. Do we need to append any of this discussion to the privacy section of the spec, or have the relevant coarsening issues been dealt with in the meantime?

[yoavweiss]

Agree that this is not actionable, but we were asked to keep this issue open to enable feedback from PING. @pes10k - should we still keep this open?