3 ms·

So, Acropalypse is “people use image snipping and markup tools to redact images, but those tools often allow the unredacted images to be recovered”? Yeah, that’

by fwlr 4y ago

So, Acropalypse is “people use image snipping and markup tools to redact images, but those tools often allow the unredacted images to be recovered”? Yeah, that’s a pretty big violation of the implicit expectations of users.

Retr0id 4y ago
To be more specific "acropalypse" refers to any image editor which does not truncate the original file before overwriting it with the edited version, leading to portions of the original being recoverable by an adversary. It originally referred to a specific vulnerability in the Markup app found on Google Pixel devices (CVE-2023-21036), but apparently now includes other unrelated apps. Source: It was me who came up with the name :)
- fwlr 4y ago
  Oh, that’s actually way worse than I thought! It’s not that these apps have some kind of undo feature or are aiming for non-destructive editing, and that’s not what users expect - the apps actually are attempting to perform redaction and they’re poorly implemented. Kudos on the name by the way, I love a good tight pun name for a vulnerability.
  - olliej 4y ago
    I can't speak for this windows tool, but for the android image editor the editor _was_ doing the correct thing. Then the underlying IO library changed in breaking way (and diverged from other APIs using the same mode strings) to not truncate when opening existing files.
    - HALtheWise 4y ago
      The API was (accidentally?) changed long before the Android tool was written, if I understand correctly. Depending on your point of view, that means it's either a poorly designed and documented API, an incorrect API that doesn't match the documentation, or a testing failure during development of the app.
      - Retr0id 4y ago
        I think the API change came after the tool was written, but not by long (it's hard to be sure, since Markup is closed-source).
        HALtheWise 4y ago
        Thanks
- CSMastermind 4y ago
  Reminds me of the old Underhanded C competition where people deliberately tried to write undetectable but faulty code for image redaction: http://underhanded-c.org/_page_id_17.html http://underhanded-c.org/_page_id_17.html
  - Retr0id 4y ago
    > Accidentally appending the original data to the image file. This takes advantage of the fact that many image formats ignore extra cruft at the end. Wow, it's almost textbook
  - squeaky-clean 4y ago
    The 1st place winner for that year is still one of my favorite software programs ever
- 13of40 4y ago
  It would be interesting to see if any popular ZIP libraries have a similar issue. If you add a file that's already in the archive, for example, and the new one is larger, I could see it just sticking the new one at the end of the archive and appending a new central directory structure. Is the periodic reencoding of the huffman tree part of DEFLATE or in the PNG are they just using a sequence of separate DEFLATE structures appended together that each have their own huffman tree? If it's the former, you might be able to recover part of a ZIP archive entry that was reduced in size and written over the original version.

by fwlr 4y ago

Retr0id 4y ago

To be more specific "acropalypse" refers to any image editor which does not truncate the original file before overwriting it with the edited version, leading to portions of the original being recoverable by an adversary. It originally referred to a specific vulnerability in the Markup app found on Google Pixel devices (CVE-2023-21036), but apparently now includes other unrelated apps. Source: It was me who came up with the name :)

fwlr 4y ago
Oh, that’s actually way worse than I thought! It’s not that these apps have some kind of undo feature or are aiming for non-destructive editing, and that’s not what users expect - the apps actually are attempting to perform redaction and they’re poorly implemented. Kudos on the name by the way, I love a good tight pun name for a vulnerability.
- olliej 4y ago
  I can't speak for this windows tool, but for the android image editor the editor _was_ doing the correct thing. Then the underlying IO library changed in breaking way (and diverged from other APIs using the same mode strings) to not truncate when opening existing files.
  - HALtheWise 4y ago
    The API was (accidentally?) changed long before the Android tool was written, if I understand correctly. Depending on your point of view, that means it's either a poorly designed and documented API, an incorrect API that doesn't match the documentation, or a testing failure during development of the app.
    - Retr0id 4y ago
      I think the API change came after the tool was written, but not by long (it's hard to be sure, since Markup is closed-source).
      - HALtheWise 4y ago
        Thanks
CSMastermind 4y ago
Reminds me of the old Underhanded C competition where people deliberately tried to write undetectable but faulty code for image redaction: http://underhanded-c.org/_page_id_17.html http://underhanded-c.org/_page_id_17.html
- Retr0id 4y ago
  > Accidentally appending the original data to the image file. This takes advantage of the fact that many image formats ignore extra cruft at the end. Wow, it's almost textbook
- squeaky-clean 4y ago
  The 1st place winner for that year is still one of my favorite software programs ever
13of40 4y ago
It would be interesting to see if any popular ZIP libraries have a similar issue. If you add a file that's already in the archive, for example, and the new one is larger, I could see it just sticking the new one at the end of the archive and appending a new central directory structure. Is the periodic reencoding of the huffman tree part of DEFLATE or in the PNG are they just using a sequence of separate DEFLATE structures appended together that each have their own huffman tree? If it's the former, you might be able to recover part of a ZIP archive entry that was reduced in size and written over the original version.