Serious Chrome zero-day

Re:Serious Chrome zero-day by ErikCorry on Thursday March 07, 2019 @04:01PM (#19332382)

Not so sure. I haven't worked on this code for a while and have no non-public knowledge of the bug, but ArrayBufferBuilder does not inherit from any of the GCed base classes, and has the USING_FAST_MALLOC macro which is used for non-GC classes. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

The ArrayBuffer itself also uses reference counters rather than the GC base classes from Oilpan. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

[ Parent | on HN ]

Re:Serious Chrome zero-day by duneroadrunner on Thursday March 07, 2019 @06:46PM (#19333822)

ArrayBufferBuilder isn't, but DOMArrayBuffer seems to be a GC managed type [1], right? And, before the patch, the DOMArrayBuffer held a "refcounting pointer" potentially targeting raw_data_'s reference counted ArrayBuffer, right? I don't see any immediately apparent use-after-free with this, so I assume raw_data_'s ArrayBuffer is being messed with elsewhere? As someone who worked on the code, do you have an idea/hunch about where the invalid memory access actually occurs?

https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5...

[ Parent | on HN ]

Re:Serious Chrome zero-day by ErikCorry on Friday March 08, 2019 @02:42AM (#19335859)

Yes, DOMArrayBuffer inherits via ScriptWrappable from GarbageCollectedFinalized<> so it's on the GCed heap. I don't understand the UAF yet, I'm hoping someone will write a blog post on it later :-).

[ Parent | on HN ]