Can we change promise resolution behaviour to reduce security issues

[mgaudet]

What is the issue with the Web IDL Standard?

Hi WebIDL Maintainers,

I'm working on a proposal at TC39 right now (currently named Thenable Curtailment, but needs a better name eventually). The goal of this proposal is to enable consumers of ECM262 to handle 'thenables' with more safety.

The current version of the proposal proposes adding an algorithm, currently named MaybeDeferredPromiseResolve which basically does the PromiseResolve steps, unless the value being resolved is (or could be) a 'thenable', in which case it will stop the promise from resolving to any other values, but waits until the microtask queue is drained again to actually run the synchronous steps.

The reason I've been pursuing this is that there's a number of security bugs which happen in web browsers when an algorithm resolves a promise with a value, which ends up unexpectedly running script due to Object.protoytpe.then causing any webIDL value to be able to trigger thenable behaviour after a native value is converted to a JS object.

I have some evidence that this is plausibly 'mostly' web-compatible (and am aware more detailed testing will be required). This proposal is now at Stage 2 of the TC39 process. I'm hoping that I can get interested parties to think in detail about places they could imagine this going wrong if we were to replace the WebIDL resolve steps with MaybeDeferredPromiseResolve.

This would have avoided a number of browser security vulnerabilities over the years, and I am reasonably convinced that something can be done to improve the browser security posture here, and hopefully with minimal breakage. It's notable that because of how 'thenables' are defined, it's relatively rare to see the deferral be needed, and I've not seen (yet!) any code which is doing this WebIDL resolve with the intention of doing sane things... basically, to a first approximation I've only ever seen the definition of then on Object.prototype or other IDL prototypes in exploit code.

[mgaudet]

Actually more accurately it defers if any part of the algorithm could run user code (e.g. resolving a Proxy, resolving something with a getter for the constructor slot etc)

[annevk]

It would be interesting to have some example APIs that are impacted by this. Maybe it is everything that takes Promise<T> because that implicitly also takes T? But we already run JS at the IDL boundary so that seems like a case where maybe you don't need the delay.

[mgaudet]

Concretely it would be anything which uses the WebIDL resolve steps. The problem isn't so much that the IDL is actively 'wrong' so much as it is that it's very easy for implementations to not realize that resolving a promise runs script basically any time.

If we made this change we actually could guarantee that resolving a promise never ran script at the cost of -some- promise reactions happening in later ticks.

[mgaudet]

So spec verbiage, like the 'pause' steps here

Resolve animation’s current ready promise with animation.

is the kind of language that gets impacted

[annevk]

So you're saying that if the Animation instance was turned into a thenable and then you invoke its currentTime setter with some value, the thenable would end up running? Seems plausible that it's supposed to work that way, but I wonder if we have test coverage for that and if all implementations adhere to that. (The API is a bit unusual in that you already have access to this so why resolve with it, but I guess that doesn't matter at this point.)

[mgaudet]

Not just a specific instance, but anything with the then property on the prototype chain. e.g. exploits will frequently define a then on Object.prototype. Animation is a good example, and has been hit a few times, but there are many places where this has tripped up developers of engines, and basically I don't think being able to synchronously run script any time any promise is resolved inside of spec algorithms is doing anyone any favours.

[mgaudet]

As to test coverage... there is some, but I would be deeply unsurprised to discover that it's heavily un-covered.

I should also emphasize: There's a benefit to -specification authors- here too. It's equally easy or a specification to become incoherent in light of thenables; ECMA262 has has this happen, and Streams made updates to deal with this.