New vulnerability found in Google's Pixel screenshot markup application, allows for DATA RECOVERY/UNCENSORING of cropped/censored screenshots.

[iTzHard]

Summary

 

New vulnerability was discovered that allows for the uncensoring of cropped/censored screenshots taken by Pixel devices. The vulnerability affects photos edited through the Markup application used to edit screenshots on Pixel devices; screenshots posted on social media platforms are also affected.

 

Quotes

Quote

Introducing acropalypse: a serious privacy vulnerability in the Google Pixel's inbuilt screenshot editing tool, Markup, enabling partial recovery of the original, unedited image data of a cropped and/or redacted screenshot. A demo is now available at https://acropalypse.app/

 

My thoughts

Even though the the vulnerability was fixed in a recent security patch, the implications are still massive, as the risk isn't "impending" but rather retroactive, most if not all edited screenshots shared by Pixel users are at risk of getting de-censored and have private information extracted from.

 

Sources

 

 https://9to5google.com/2023/03/18/pixel-markup-screenshot-vulnerability/

 https://www.da.vidbuchanan.co.uk/blog/exploiting-acropalypse.html

[HenrySalayne]

Oof. The story is amazing. All comes down to a missing "t".

But why did nobody notice that cropping a screenshot doesn't change the file size?

[TetraSky]

Wow... How did Google manage to fck that one up. Leaves the rest of the original file in its place even after editing it... No one really noticed the file size not changing, eh.

Spoiler

 

Quote

Root Cause Analysis

The bug lies in closed-source Google-proprietary code so it's a bit hard to inspect, but after some patch-diffing I concluded that the root cause was due to this horrible bit of API "design": https://issuetracker.google.com/issues/180526528.

 

Google was passing "w" to a call to parseMode(), when they should've been passing "wt" (the t stands for truncation). This is an easy mistake, since similar APIs (like POSIX fopen) will truncate by default when you simply pass "w". Not only that, but previous Android releases had parseMode("w") truncate by default too! This change wasn't even documented until some time after the aforementioned bug report was made.

 

The end result is that the image file is opened without the O_TRUNC flag, so that when the cropped image is written, the original image is not truncated. If the new image file is smaller, the end of the original is left behind.

IMHO, the takeaway here is that API footguns should be treated as security vulnerabilities.

 

 

Thankfully it got patched, but it doesn't help all these images that were previously posted by Pixel users.

[LAwLz]

I love how some people comment on the tweet saying they use Pixel phones and this feature.

Because the first thing you should do when a vulnerability is discovered is broadcast "I am vulnerable" online.

 

 

I don't get how this can recover data under the black bar though. I get that it doesn't delete the cropped information, but surely the pixels "below" the black bar should be overwritten. JPEG doesn't, as far as I know, have any support for layers. Everything get smushed into the same "layer" when it gets encoded.

 

 

Edit: Okay I get it now. The reason why the card number was recoverable was because the image was cropped and the cropped image was written to the top of the file (the black area). The data for the part of the original image that contained the uncensored card was never overwritten since the new image was smaller.

If you just edited the image instead of cropping it then the number would not be recoverable.

 

In other words, you can't actually uncensor an image because you can't remove the censor. Once that data is written, the pixels "below" are destroyed. What you can do is restore the uncropped image which may contain the data that was overwritten in the "copy".

[Fasterthannothing]

20 minutes ago, LAwLz said:

I love how some people comment on the tweet saying they use Pixel phones and this feature.

Because the first thing you should do when a vulnerability is discovered is broadcast "I am vulnerable" online.

 

 

I don't get how this can recover data under the black bar though. I get that it doesn't delete the cropped information, but surely the pixels "below" the black bar should be overwritten. JPEG doesn't, as far as I know, have any support for layers. Everything get smushed into the same "layer" when it gets encoded.

 

 

Edit: Okay I get it now. The reason why the card number was recoverable was because the image was cropped and the cropped image was written to the top of the file (the black area). The data for the part of the original image that contained the uncensored card was never overwritten since the new image was smaller.

If you just edited the image instead of cropping it then the number would not be recoverable.

 

In other words, you can't actually uncensor an image because you can't remove the censor. Once that data is written, the pixels "below" are destroyed. What you can do is restore the uncropped image which may contain the data that was overwritten in the "copy".

So if I'm understand it right if they cropped the image first then edited they could recover the original picture. But if they edited then cropped it they would only see a larger sized image correct?

[HenrySalayne]

8 hours ago, LAwLz said:

Edit: Okay I get it now. The reason why the card number was recoverable was because the image was cropped and the cropped image was written to the top of the file (the black area). The data for the part of the original image that contained the uncensored card was never overwritten since the new image was smaller.

If you just edited the image instead of cropping it then the number would not be recoverable.

 

In other words, you can't actually uncensor an image because you can't remove the censor. Once that data is written, the pixels "below" are destroyed. What you can do is restore the uncropped image which may contain the data that was overwritten in the "copy".

A black bar also contains less data in a compressed image. So the new file will be smaller and the trailing edge of the file could contain the data.

[LAwLz]

9 hours ago, Fasterthannothing said:

So if I'm understand it right if they cropped the image first then edited they could recover the original picture. But if they edited then cropped it they would only see a larger sized image correct?

That's how I interpret it, yes. 

 

In the credit card example it wouldn't have been an issue if they censored it first, saved it, and then cropped it. Or well, it might still have been an issue because the rest of the picture might have other sensitive info in it. But you shouldn't be able to recover the blacked out part if those steps were followed. 

 

Something to keep in mind when going through old cropped photos. 

[HenrySalayne]

56 minutes ago, LAwLz said:

In the credit card example it wouldn't have been an issue if they censored it first, saved it, and then cropped it. Or well, it might still have been an issue because the rest of the picture might have other sensitive info in it. But you shouldn't be able to recover the blacked out part if those steps were followed. 

 

The full image has 1.92 MB, the one with a black bar has 1.23 MB. Censoring something, especially in the lower third could leave the uncensored part attached. So no, this is not only relevant for cropped images.

However, it is more likely, because why would you black out huge parts of the image and not simply cutting them off?

Edit: Or does it only happen for cropped images and not all images edited with the markup tool?

[Doobeedoo]

That's rather bad... they're slacking.

[LAwLz]

12 hours ago, HenrySalayne said:

 

The full image has 1.92 MB, the one with a black bar has 1.23 MB. Censoring something, especially in the lower third could leave the uncensored part attached. So no, this is not only relevant for cropped images.

However, it is more likely, because why would you black out huge parts of the image and not simply cutting them off?

Edit: Or does it only happen for cropped images and not all images edited with the markup tool?

My understanding is that it only happens with cropped images. That it doesn't actually delete the data that was cropped out. 

It doesn't really have anything to do with file sizes. That was only mentioned because it was a tell something was wrong. If you crop an image to be 1/4 the amount of pixels, it's weird if the file size barely changes. It should probably be at least half the size, but that didn't happen in this case which is why they discovered "holy crap, it doesn't delete the data that's suppose to be cropped out".

 

The other functions in markup tools seems to be fine. It's just the cropping that was broken. 

At least that's my understanding. 

[wanderingfool2]

On 3/19/2023 at 1:58 AM, HenrySalayne said:

The full image has 1.92 MB, the one with a black bar has 1.23 MB. Censoring something, especially in the lower third could leave the uncensored part attached. So no, this is not only relevant for cropped images.

However, it is more likely, because why would you black out huge parts of the image and not simply cutting them off?

Edit: Or does it only happen for cropped images and not all images edited with the markup tool?

The TL;DR of how this exploit works using a simple example is like this:

 

Image you have the following text, that is the "data" for the png

Quote

The quick brown fox jumps over the lazy dogs plus a bit extra.  Second sentence that will be the "cropped".  Also this is a third sentence to pad out the file.  Fourth sentence to pad out this

Now with the png format you specify how large the data chunk is (it doesn't assume how large the data chunk is).  So what is happening is when they are "cropping" they aren't delete the data, they are simply overwriting the beginning of the data..and still writing the entire data to disk.  So "cropping" the second sentence would look like this for the data.

 

Quote

Second sentence that will be the "cropped".[end of real data]s plus a bit extra. Second sentence that will be the "cropped".  Also this is a third sentence to pad out the file.  Fourth sentence to pad out this

So now if you modify the cropped/scaled image at all you will be editing only the beginning part.  There are a bunch of nuances with it, specifically with huffman encoding...but the above is approximately what happens.  Where the png header knows where the "data" should end, but they just tack on more data.  The fix for Google, based on the analysis blog is literally a 1 character fix. (adding a "t" so instead of "w" it's "wt")

 

It's actually quite a large oversight on Google's accord, for multiple reasons...aside from the obvious exposure it also means larger file sizes.  I'm surprised it wasn't spotted before, then again most people wouldn't really be noticing file sizes on Androids.

[HenrySalayne]

9 hours ago, LAwLz said:

The other functions in markup tools seems to be fine. It's just the cropping that was broken. 

At least that's my understanding. 

24 minutes ago, wanderingfool2 said:

The TL;DR of how this exploit works using a simple example is like this:

 

Image you have the following text, that is the "data" for the jpg

Now with the jpg format you specify how large the data chunk is (it doesn't assume how large the data chunk is).  So what is happening is when they are "cropping" they aren't delete the data, they are simply overwriting the beginning of the data..and still writing the entire data to disk.  So "cropping" the second sentence would look like this for the data.

 

So now if you modify the cropped/scaled image at all you will be editing only the beginning part.  There are a bunch of nuances with it, specifically with huffman encoding...but the above is approximately what happens.  Where the jpg header knows where the "data" should end, but they just tack on more data.  The fix for Google, based on the analysis blog is literally a 1 character fix. (adding a "t" so instead of "w" it's "wt")

 

It's actually quite a large oversight on Google's accord, for multiple reasons...aside from the obvious exposure it also means larger file sizes.  I'm surprised it wasn't spotted before, then again most people wouldn't really be noticing file sizes on Androids.

Which does not answer the question. The issue occurs while overwriting the file with the edited (new) version. The question remains if this is a general problem with Markup saving a file or just with the cropping feature in Markup.

I don't know why Markup would use individual methods to save files for different tools in the software.

 

[LAwLz]

23 minutes ago, HenrySalayne said:

Which does not answer the question. The issue occurs while overwriting the file with the edited (new) version. The question remains if this is a general problem with Markup saving a file or just with the cropping feature in Markup.

I don't know why Markup would use individual methods to save files for different tools in the software.

Oh, now I understand what you meant.

Yeah that's a fair point I didn't consider. My guess would be that the data is recover-able in that case as well if you censor by adding black at the end of the file instead of just cropping it. 

 

But my guess is that it would be discovered very quickly by someone since the "uncensored" picture would still be displayed, and someone would probably just assume it was a bug.

The issue with the cropped images is that they look like they are fine but aren't actually fine. In the example you created my guess is that it would look like nothing was censored at all and the user would think "huh, must be a big, I'll crop it instead".

[wanderingfool2]

45 minutes ago, HenrySalayne said:

Which does not answer the question. The issue occurs while overwriting the file with the edited (new) version. The question remains if this is a general problem with Markup saving a file or just with the cropping feature in Markup.

I don't know why Markup would use individual methods to save files for different tools in the software.

It's going to depend on how they called the API calls.  If they have a function that just handles the changes to the data, then yea everything would be included...if they called it for each operation then maybe...depends on how they called things.  I mean the issue appears to be that they changed the underlying API so that it doesn't truncate when it writes to a stream...instead you have to specify "wt".  So in theory any image that produces a smaller file size would contain information excess information...just in most cases it's not practical enough type of information. (assuming that they had an internal method which did the saving)

 

Like if you took an image and make it all black, it seems like Markup would likely leave behind quite a bit of information (as a solid black image is really small in terms of data required).   Practically though cropping would be the biggest culprit, as you have so much extra data.

 

Based on the write up, they actually had in the past used "w" to mean write and truncate the data, but switched it...so it's probably a fault of some legacy code they used to save or just someone not realizing the change at google.  They likely have a stream for the LZ77 data, which they write to.  Although I would suspect scaling wouldn't be affected by this (as they would have to change other areas on the jpg...but I could be wrong)

[Stark Odinson]

This the equivalent of censoring by turning the colour of the text to white to match the background colour in word.

[Mihle]

I remember that one time I edited a photo and saved it on my Samsung phone, only the edited one was viewable on gallery, but then there was a button to get back the original.

 

I am guessing it keeps the original saved but doesn't show it to you.

[Sauron]

On 3/18/2023 at 11:19 PM, LAwLz said:

If you just edited the image instead of cropping it then the number would not be recoverable.

 

In other words, you can't actually uncensor an image because you can't remove the censor. Once that data is written, the pixels "below" are destroyed. What you can do is restore the uncropped image which may contain the data that was overwritten in the "copy"

Still a pretty major oversight, even if it weren't for the privacy implications it's just sloppy to keep the full image data for no reason.

1 hour ago, Mihle said:

I remember that one time I edited a photo and saved it on my Samsung phone, only the edited one was viewable on gallery, but then there was a button to get back the original.

 

I am guessing it keeps the original saved but doesn't show it to you.

Not in this case, here the full original image cannot be recovered but some parts that weren't cropped can be.

[HenrySalayne]

1 hour ago, Mihle said:

I remember that one time I edited a photo and saved it on my Samsung phone, only the edited one was viewable on gallery, but then there was a button to get back the original.

 

I am guessing it keeps the original saved but doesn't show it to you.

If the "original image" (unedited) is still somewhere on your phone - ok.

If the "original image" is part of the file you are sending to other people - big oof!

The Acropalypse (I read "Acropolis" all the time) is about the latter. Parts of the picture (the parts you cut off) might still be in the image file. And then you send the image file to other people or upload it to a public space like this forum...

 

Maybe this clears up what the "new" file contains after it has been cropped. Obviously you will only see the "new" image, when you open this file, but the rest is still in there.

[wanderingfool2]

Edit:  Actually should be noted, appears to only affect PNG files.  Not jpg files.

 

6 hours ago, Sauron said:

Still a pretty major oversight, even if it weren't for the privacy implications it's just sloppy to keep the full image data for no reason.

I think this might be a bigger lesson in the "when making changes to an API, analyze if it makes sense to make the change and document it".  They didn't do either.

 

At least if the analysis is correct, the reason it was truncated is that prior to Android 10 parseMode("w") == parseMode("wt") was true (maybe was a design oversight originally).  Anyone writing using those functions would have the stream truncated...then they made the terrible move of making them distinct and the worse move of not documenting the change.  It's my belief a core function like this should not be changed without serious consideration to what the outcome will be as it produces quite a different result than before and is 100% easy to overlook.

 

Not sure if it's really blame Markup complete for this...if lets say if that piece of code was written prior to Android 10 and no one noticed the change (because after all these years the function behaved the same way and they didn't even bother documenting the change at the API level)

[HenrySalayne]

 

[wanderingfool2]

The Windows Snipping Tool I think is a lot less of an issue though, or rather it's a lot less likely to happen than on lets say a phone...you have to almost have to do it in a contrived way to get it to work.

 

Specifically the snipping tool just overwrites data to a file instead of truncating (it doesn't have anything to do with cropping actually).  While it's still bad, I would have a feeling that this would come about less often...as in this case if you snip, crop and save the image it will save it to the correct size.  If you Snip, save the image, crop and then save overtop of the image then it would be affected.  Maybe it's me, but lots of people I know just snip it before hand instead of saving the full screenshot first.

 

e.g. Create a text file and copy paste in "The quick brown fox jumps over the lazy dogs"...repeat until it's like 1 MB in size and rename it png.  Use the snipping tool to snip just a 10x10 pixel white space, then open the png file in a text editor and see the phrase.

 

So it's similar exploit but not really the same...I think less people would be affected by this as well given that it requires overwriting the file.  If you save it as something new, you aren't affected.  In the case of the Google crop issue though, it's more likely to take a screenshot edit it and share it.

[ProgramMax]

On 3/20/2023 at 11:43 AM, wanderingfool2 said:

Actually should be noted, appears to only affect PNG files.  Not jpg files.

Will Dormann demonstrated it working with jpegs, too.

The underlying concept of a non-truncated file makes it pretty generic.
I wouldn't be surprised if more of these show up.

[wanderingfool2]

5 hours ago, ProgramMax said:

Will Dormann demonstrated it working with jpegs, too.

The underlying concept of a non-truncated file makes it pretty generic.
I wouldn't be surprised if more of these show up.

Important not to conflate the snipping tool issue vs the Markup issue.

 

At the moment there has only been talk about png's and Markup, while it might also be jpg as well haven't heard about it being that yet.

 

The tweet you are referring to is Windows Snipping Tool, which my previous post goes over what has gone wrong in that case.

[LAwLz]

8 hours ago, wanderingfool2 said:

Specifically the snipping tool just overwrites data to a file instead of truncating (it doesn't have anything to do with cropping actually).  While it's still bad, I would have a feeling that this would come about less often...as in this case if you snip, crop and save the image it will save it to the correct size.  If you Snip, save the image, crop and then save overtop of the image then it would be affected.  Maybe it's me, but lots of people I know just snip it before hand instead of saving the full screenshot first.

I think a more likely scenario is that someone takes a snip with the snipping tool and then overwrites a different image by saving it with the same name. In such a scenario, you might be able to recover data from the old image that you thought was overwritten.

 

So let's say you have a 3MB image that is called "untitled.png". For example a big screenshot that you don't care about and don't intend to post, or a picture that was created by a completely different program (doesn't have to be from snipping tools).

You then take a snip with the snipping tool that ends up being 0.3MB in size and you decide to save that as "untitled.png" because you will be killing two birds with one stone. You think you "deleted" the original 3MB screenshot, and you saved the new snip in one go.

The issue is that you can recover ~90% of the old 3MB screenshot from the snip that you thought was only 0.3MB.

 

I think that's a more likely scenario than the one you described. As long as you overwrite an existing file with data from Snipping Tools, parts of the original data might be recoverable. Probably a less likely scenario than the Pixel markup issue, but still not great.

 

 

 

I wonder which other programs might be affected. I'd be surprised if it was just Snipping Tools and Markup.

[leadeater]

1 hour ago, LAwLz said:

I think a more likely scenario is that someone takes a snip with the snipping tool and then overwrites a different image by saving it with the same name. In such a scenario, you might be able to recover data from the old image that you thought was overwritten.

I've done that a few times, it's basically always because I'm not happy with the first snip and do it again but it's of the same thing just very slightly different.