Proposal: Curtailing the power of "Thenables"

Matthew Gaudet, Mozilla

https://github.com/mgaudet/proposal-thennable-curtailment

Reminder: What are Thenables

• Objects with then property are “thenables”, and treated specially in Promise code
• Why? For compatibility with pre-standard promise libraries

​

What’s the problem here?

Basically: It is easy for implementers of web-specifications, engines and specification writers to forget that this behaviour exists, and accidentally introduce user-controlled execution in places it wasn’t expected:

For example: calling Promise.resolve on a newly created WebIDL dictionary type?

Seems safe?

Oops. Dictionaries convert to objects with [[Prototype]] set to Object.prototype – accidental user code execution

​

What’s the problem here?

Result: CVE after CVE

• CVE-2024-43357 on the specification.
• Out of bound access in ReadableStream::Close
• CVE-2021-21206: Chrome Use-After-Free in Animations
• CVE-2024-9086
• And more – frankly, I didn’t look that hard.

​

Stage 0 to 1 Ask: Can we do anything here?

CVE-2024-43357 Fixes

During remediation of CVE-2024-43357 (The Spec CVE) a couple fixes were proposed that helped here:

1. Make Object.prototype exotically reject "then" properties. Change the [[DefineOwnProperty]] MOP operation on Object.prototype to silently no-op when the property key is "then".
2. Make some promise resolve functions not respect thenables. Exclude certain internal resolution functions to not respect thenables.

A Possible Third Path

I would propose a third solution:

• Specification defined prototypes gain a new internal slot [[InternalProto]]
• The lookup for the then property changes from Get to GetNonInternal, a new specification AO which walks the prototype chain, but stops as soon as it encounters a prototype with the [[InternalProto]] internal slot.

Some Advantages

1. In my opinion a more harmonious design
2. Can be integrated into WebIDL – Change WebIDL spec to make IDL defined prototypes [[InternalProto]]
3. Avoids making Object.prototype exotic

Does this solve everything?

Nope. This is a mitigation, an attempt to make easy-to-make errors safer. It does not address the whole class of “thenable” problems.

Compatibility

In preparation for this proposal I added some telemetry to Firefox to see what roughly we could expect as far as problems go.

(If this goes to Stage 1 I would likely add telemetry for “Holder is Object.prototype”)

Other solutions welcome!

Stage 0 to 1 isn’t about “I have a solution”, it’s about problem identification.

I’m interested in more discussion, other solutions etc.

Stage 1?