#Apple webkit Patch
#Apple webkit code

For example, in January 2020 Chrome fixed that IDBRequest::DispatchEventInternal changed state in IndexedDB objects based on untrusted events. Monitoring fixes in other platforms who have similar implementations of code.Memory Tagging could potentially prevent this use-after-free.What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? Check whether tasks that take place in threads other than the origin thread use raw references or pointers.įound variants: N/A Structural improvements.Check whether other dispatchEvent functions change state based on non-trusted (custom/script-generated) events.Part of an exploit chain? The Next Steps Variant analysisĪreas/approach for variant analysis (and why): (The terms exploit primitive, exploit strategy, exploit technique, and exploit flow are defined here.)

#Apple webkit Patch

The patch included adding the template to CrossThreadTask::createCrossThreadTask for callees that are a derived class of ThreadSafeRefCounted. In this case, the use-after-free was on the IDBDatabase object.

In March 2019, what seems to be a similar bug was found in WebKit.

In December 2019, what seems to be a similar bug was found in Chrome by ClusterFuzz:.

(Historical/present/future) context of bug: It is also possible though that the attackers found the vulnerability after seeing the similar Chrome & WebKit bugs. The trigger for this vulnerability uses all common patterns that would be known to most fuzzers. This bug was most likely found via fuzzing.

#Apple webkit code

Thoughts on how this vuln might have been found (fuzzing, code auditing, variant analysis, etc.): This is done by changing the templates to use ThreadSafeRefCountedBase instead of ThreadSafeRefCounted. In CrossThreadTask::createCrossThreadTask the template is modified to ensure that the callee object, in this case the IDBOpenDBRequest, is a RefPtr and therefore protected, rather than being a raw reference.In IDBRequest::dispatchEvent a check is added to only change the state of the request if the event is trusted, i.e.Therefore #2 with the raw reference was used. While the intention was that an IDBOpenDBRequest callee would use template #1, the RefPtr, #2 was actually used because IDBOpenDBRequest is not derived from ThreadSafeRefCounted, it's actually derived from ThreadSafeRefCounted. IDBRequest is a derived class from ThreadSafeRefCounted ( IDBRequest.h#L63). IDBOpenDBRequest is a derived class from IDBRequest ( IDBOpenDBRequest.h#元5). To trigger this vulnerability, we're using a callee object of IDBOpenDBRequest. Arguments > CrossThreadTask createCrossThreadTask ( T & callee, void ( T ::* method )( Parameters. Template, T >:: value, int >:: type = 0, typename.