A severe privacy flaw named 'acropalypse' has also been found to affect the Windows Snipping Tool, allowing people to partially recover content that was edited out of an image.
Last week, security researchers David Buchanan and Simon Aarons discovered that a bug in Google Pixel's Markup Tool caused the original image data to be retained even if it was edited or cropped out.
This flaw poses a significant privacy concern as if a user shares a picture, such as a credit card with a redacted number or revealing photos with the face removed, it may be possible to partially recover the original photo.
To illustrate this bug, the researchers launched an online acropalypse screenshot recovery utility that would attempt to recover edited images created on Google Pixel.
Windows 11 Snipping tool affected too
Today, software engineer Chris Blume confirmed that the ‘acropalypse’ privacy flaw also affects the Windows 11 Snipping Tool.
When opening a file in the Windows 11 Snipping Tool and overwriting an existing file, instead of truncating any unused data, it leaves the unused data behind, allowing it to be partially recovered.
Vulnerability expert Will Dormann also confirmed the Windows 11 Snipping Tool flaw, and with Dormann's help, BleepingComputer confirmed the issue as well.
To test this, we opened an existing PNG file in the Windows 11 Snipping Tool, cropped it (can also edit or mark it up), and then saved the changes to the original file. The original and cropped images are illustrated below.
Source: BleepingComputer
While the cropped image now contains far less data than the original one, the file sizes for the original image file (office-screenshot-original.png) and cropped image file (office-screenshot.png) are the same, as seen below.
Source: BleepingComputer
The PNG file specification requires that a PNG image file always ends with an 'IEND' data chunk, with any data added after it being ignored by image editors and viewers.
For example, below is the original screenshot that I took of Microsoft's site. As you can see, the file ends with an IEND and contains no data after it.
Source: BleepingComputer
However, using the Windows 11 Snipping Tool to overwrite the original image with the cropped version, the program did not correctly truncate the unused data, and it remains after the IEND data chunk.
Source: BleepingComputer
Opening the file in an image viewer just displays the cropped image, as anything after the first IEND is ignored.
However, this untruncated data can be used to partially recreate the original image, potentially allowing sensitive portions to be revealed.
While the researcher's online acropalypse screenshot recovery app does not currently work with Windows files, Buchanan shared a Python script with BleepingComputer that can be used to recover Windows files.
Using this script, BleepingComputer successfully recovered a portion of the image, as shown below.
Source: BleepingComputer
This was not a complete recovery of the original image, and you may be wondering why this is a privacy risk.
Imagine that you took a screenshot of a sensitive spreadsheet, confidential documents, or even a nude picture, and cropped out sensitive information or parts of the image.
Even if you can't fully recover the original image, someone could recover sensitive information you would not want to go public.
It should also be noted that not all PNG files, such as optimized PNGs, are affected by this flaw.
"Your original PNG was saved with a single zlib block (common for "optimised" PNGs) but actual screenshots are saved with multiple zlib blocks (which my exploit requires)," Buchanan explained to BleepingComputer.
BleepingComputer also found that if you open an untruncated PNG file in an image editor, such as Photoshop, and save it to another file, the unused data at the end will be stripped off, making it no longer recoverable.
Finally, the Windows 11 Snipping Tool also performs the same behavior with JPG files, leaving data untruncated if overwritten. However, Buchanan told BleepingComputer that his exploit does not currently work on JPGs, but could be possible.
Microsoft told BleepingComputer that they are aware of the reports and are looking into them.
"We are aware of these reports and are investigating. We will take action as needed to help keep customers protected," a Microsoft spokesperson told BleepingComputer.
Comments
tech_engineer - 1 year ago
"Bugs of a feather flock together"...
They find the same bugs everywhere now ( https://www.bleepingcomputer.com/news/security/google-pixel-flaw-allowed-recovery-of-redacted-cropped-images/ )
h_b_s - 1 year ago
It's a relatively common mistake in programming to ignore sanitizing the file slack. The question is whether all the programmers that are doing this are making the same assumption: replacing the file just leaves unimportant garbage behind, they're all using similar reference libraries that make the same mistake, or the same programmer made the mistake at one place then moved on to the other and made the same mistake again.
I mean, arguably this isn't even a mistake as far as the JPG and PNG file layout specification is concerned. It's only when the file slack has sensitive data that this can become a potential issue and only when people are looking at the data in a raw format. If this is a problem, then it should be pointed out that most file systems basically do the same thing. They unlink the file data from the directory structure on deletion, but the data itself is still available unaltered until such time as the file system overwrites it, which has no time limit so the orphaned data can remain indefinitely for a simple forensic examination and recovery.
Edit to add: reasonably sure Android and Snip tool aren't the only ones doing that with PNG and JPG files. I've seen other programs leave the on disk file size unaltered after shrinking or cropping images... problem is I can't remember which ones right now.
YetAnotherReader - 1 year ago
Isn’t it the same with PDF documents? If I’m correct, changes are added to the document and the parts they replace are marked as deleted but stay in the document.
h_b_s - 1 year ago
The difference being PDF's file history is intended. With this ridiculously named oversight in coding, ideally you'd decrease the size of the file after shrinking, cropping, or whatever by moving the file back over itself on save. It's the process pointed out on other forums used for safely overwriting files in an OS agnostic method.
I have trouble crediting this particular flaw as anything other than sloppy coding practices that may or may not result in a data leak - usually it won't. If people are concerned about these kinds of side channel info disclosure channels that aren't actually bugs more like occasional unintended consequences, then there are much bigger fish to fry. There's already a large number of 'gotchas' to be aware of in information redaction. Some are (mis)features like exact GPS location metadata or document history. Some are intended because of performance issues like the aforementioned file system file deletions not actually deleting anything, but have obvious data leakage implications. Sometimes it's unintended consequences with regulatory document retention rules. Others are just from sloppy assumptions in coding a program like the article's topic information leakage. Sometimes that's even deliberate - like in the case of MP3 metadata (read the MP3 spec and history, music metadata tags aren't part of the file spec it's 3rd party add-on that became a de facto standard). It's not just these two programs that fail to clear the end of file slack after a requested overwrite. All data forensic pros know to look for just these kinds of data fragments when searching for evidence on filesystems because they can be relevant to the case and may reveal intentionally hidden data.
rsocol - 1 year ago
The bug is now fixed, see https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28303. Make sure you apply the update from the Microsoft Store.