TC39 Delegates
2025-08-08
plaintext logs
prev next
source on github
01:50
<Justin Ridgewell>
However I haven't heard a request for userland to be able to implement the safe resolve operation itself. Just that whatever hosts can do, that userland can do it just as much (aka a virtualization constraint, which of course I'm 100% behind)
Unfortunately this approach may not be web compatible, based on Svelte.
01:51
<Justin Ridgewell>
I realize svelte just added it, but the fact that anyone’s done a get accessor that depends on immediate access makes me wary that others may have done it.
01:52
<bakkot>
The idea would be to only use this in certain places not by default, I think?
01:52
<Justin Ridgewell>
If we limit this to just a safe capability that does the proxy check, that’d work.
01:52
<Justin Ridgewell>
Yah, that’d be fine.
01:54
<Justin Ridgewell>
The default promise capability (and then return value, and promise constructor) could use the current immediate then access. The safe capability does a check to immediately resolve a non-thenable, or defers then access if proxy or then accessor is defined.
01:55
<Justin Ridgewell>
Although, Fulfilled wrapper could do this without us having to switch everything to a new capability 😉
02:27
<mgaudet>
Catching up on the discussion right as I head into a late night chat, so can't participate too much at the moment, but, I just want to explicitly say how much I appreciate how much thought and discussion is going into trying to fix this. It really is wonderful to see. Thanks everyone.
19:49
<Justin Ridgewell>
mgaudet: Can we get access to the test case mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1923344#c11?
19:49
<Justin Ridgewell>
I mainly want to see what the thenable implementation was, if it had some exploit code to it
19:50
<Justin Ridgewell>
Or does the animation just being a thenable cause the exploit?
19:51
<Justin Ridgewell>
This affects Mathieu Hofman's preferred solution to delay thenable access, if just being a thenable is the problem then this solution will not solve that case.
19:53
<mgaudet>
it definitely had exploit code in it; but the problem was where the code ran (synchronously at a point not forseen)
19:55
<mgaudet>
Now, IIRC that one did not require newborn objects, and thus would probably not have been fixed by our mitigations for newborn objects that have been discussed. Not paged in at the moment tho
19:55
<Mathieu Hofman>
Afaik the problem is almost always with synchronous then get operations
19:56
<mgaudet>
Object.defineProperty(Object.prototype, 'then', {
    get: function () {
      if (this.toString() == "[object Animation]") {

is the snippet from the simplified test acse

19:56
<Justin Ridgewell>
So it is something like get then() { exploit here; return () => {} }
19:57
<Mathieu Hofman>
And yeah from what I read, the object was available to userland before. And an own then would have worked (even though the exploit code used an object prototype version)
19:57
<mgaudet>
Yep
19:58
<Mathieu Hofman>
There is a write up somewhere about that CVE
19:58
<Justin Ridgewell>
Is it still possible to trigger the exploit with something like then() { exploit here; }?
19:58
<Mathieu Hofman>
Not it had to be a `get then`
19:58
<Mathieu Hofman>
(it could have been a proxy installed as the prototype too)
19:59
<mgaudet>
https://www.welivesecurity.com/en/eset-research/romcom-exploits-firefox-and-windows-zero-days-in-the-wild/
19:59
<mgaudet>
Oh wait that's not the writeup
20:00
<mgaudet>
Oh no it's in there, just needed to scroll futher
20:00
<Justin Ridgewell>
(Matrix needs to add a profile image cropper and stop telling people I'm changing my pic)
20:01
<Justin Ridgewell>
Thanks for the link!
20:33
<Justin Ridgewell>
That link also links to https://dimitrifourny.github.io/2024/11/14/firefox-animation-cve-2024-9680.html, which provides the full exploit
21:12
<Justin Ridgewell>

So if we do this:

1. Safely inspect obj and prototype chain for `.then`
    1. If safe, fulfill now and exit
2. Assert: not safe
3. Delay 1 tick
4. get `.then`
5. If `.then` is not a function, fulfill and exit
// Note: we used to delay 1 tick here
6. Call(then, onFulfilled, onRejected)

That would fix the sync interleaving of C++ and JS code, wouldn't impact normal objects, and would keep the overall ticks for thenables the same

21:16
<Justin Ridgewell>
But it would break Svelte, so everything would need to call the new Safe capability instead.