4 ms·

This is a blog post that seems to just be reporting on this tweet: https://twitter.com/justinschuh/status/1103087046661267456 https://twitter.com/justinschuh/st

This is a blog post that seems to just be reporting on this tweet: https://twitter.com/justinschuh/status/1103087046661267456 https://twitter.com/justinschuh/status/1103087046661267456 which in turn is referencing this new release from this past Friday: https://chromereleases.googleblog.com/2019/03/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2019/03/stable-channel... which seems to have been motivated by "CVE-2019-5786: Use-after-free in FileReader. Reported by Clement Lecigne of Google's Threat Analysis Group on 2019-02-27". That CVE is still reserved/non-public on the Mitre NVD though.

deusum 8y ago
Well done! That read was unpleasantly verbose.
saagarjha 8y ago
From the code referenced, it seems like this might be the commit that fixes this issue: https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449 https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0...
- loeg 8y ago
  Indeed, bug 936448 is a locked bug: https://bugs.chromium.org/p/chromium/issues/detail?id=936448 https://bugs.chromium.org/p/chromium/issues/detail?id=936448
- xfs 8y ago
  This interface raw_data_->ToArrayBuffer() sometimes returns a copy of its internal buffer and sometimes returns a smart pointer to its internal buffer. See https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.h#L63-L67 https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5... But DOMArrayBuffer::Create() here takes ownership of the memory from ToArrayBuffer(), so in the latter case of a smart pointer, the internal buffer of raw_data_ is immediately invalidated and its value becomes undefined after creating the DOMArrayBuffer. This is fine if file loading is finished at this point because raw_data_ is reset to nullptr, but if the load is partial, then the undefined value in raw_data_ will be reused to create another DOMArrayBuffer which is then accessible in javascript. Hence the use after free. I'll attribute the root cause of this bug to unclear memory ownership passing in interface design.
craftyguy 8y ago
And here we have a great example of an obvious, uh, violation of this HN guideline: > Please submit the original source. If a post reports on something found on another site, submit the latter. Clickbait blogspam, right to the top! Nice work HN!

deusum 8y ago

Well done! That read was unpleasantly verbose.

saagarjha 8y ago

From the code referenced, it seems like this might be the commit that fixes this issue: https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449 https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0...

loeg 8y ago
Indeed, bug 936448 is a locked bug: https://bugs.chromium.org/p/chromium/issues/detail?id=936448 https://bugs.chromium.org/p/chromium/issues/detail?id=936448
xfs 8y ago
This interface raw_data_->ToArrayBuffer() sometimes returns a copy of its internal buffer and sometimes returns a smart pointer to its internal buffer. See https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449/third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.h#L63-L67 https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5... But DOMArrayBuffer::Create() here takes ownership of the memory from ToArrayBuffer(), so in the latter case of a smart pointer, the internal buffer of raw_data_ is immediately invalidated and its value becomes undefined after creating the DOMArrayBuffer. This is fine if file loading is finished at this point because raw_data_ is reset to nullptr, but if the load is partial, then the undefined value in raw_data_ will be reused to create another DOMArrayBuffer which is then accessible in javascript. Hence the use after free. I'll attribute the root cause of this bug to unclear memory ownership passing in interface design.

craftyguy 8y ago

And here we have a great example of an obvious, uh, violation of this HN guideline: > Please submit the original source. If a post reports on something found on another site, submit the latter. Clickbait blogspam, right to the top! Nice work HN!