For a hint at how the bug works, see this <a href="https://issuetracker.google.com/issues/180526528" rel="nofollow">https://issuetracker.google.com/issues/180526528</a> (more details coming soon™)<p>From <a href="https://twitter.com/David3141593/status/1636979466860744704" rel="nofollow">https://twitter.com/David3141593/status/1636979466860744704</a><p>Also: you [can] do a basic check with tools like exiftool - it will report "Warning: [minor] Trailer data after PNG IEND chunk" on vulnerable images.<p>From: <a href="https://twitter.com/David3141593/status/1636981307891671041" rel="nofollow">https://twitter.com/David3141593/status/1636981307891671041</a>
The fact this wasnt triaged as a security bug is unforgivable <a href="https://issuetracker.google.com/issues/180526528" rel="nofollow">https://issuetracker.google.com/issues/180526528</a>
These types of issues are exactly why whenever it’s sensitive, I screenshot, crop/edit, then screenshot the crop’d/edited screenshot. There’s other possible issues than this bug (like iOS’s non-destructive edits by default), so it’s better to be safe than sorry.
I don't see any sort of background at all on how it's working. There's metadata in the image that helps reconstruct the original? Or something about how Discord does the attachment, or?<p>Ah, one commenter offered this:<p><i>"It looks like when the edits make the PNG smaller it saves the original number of bytes, overflowing its own buffer and leaving a bunch of unintended IDAT chunks to find :). Did you talk to Google about this before taking to twitter though?"</i><p><a href="https://twitter.com/Bottersnike237/status/1636892723012665344" rel="nofollow">https://twitter.com/Bottersnike237/status/163689272301266534...</a>
Little detail on how this works. I initially thought it's based on thumbnails, but the high quality of the recovered image and the damage at the beginning makes me think it's something else.