Privacy fail: Pictures cropped, redacted by Google Pixel phones can be recovered
(2023/03/20)
- Reference: 1679346783
- News link: https://www.theregister.co.uk/2023/03/20/google_pixel_acropalypse/
- Source link:
If you've owned a Google Pixel smartphone since the 3 series came out in 2018, bad news: any screenshot that you've cropped or redacted on your Pixel can be potentially restored without much fuss.
Reverse engineers Simon Aarons and David Buchanan, who found the bug and produced a proof-of-concept recovery tool, respectively, dubbed it [1]aCropalypse , and [2]noted "this bug is a bad one" for folks concerned about their privacy.
The flaw lies in how Google's image-editing app Markup, available for the Pixel line, truncates PNG files after they are edited – namely, it doesn't, Buchanan detailed in a [3]write-up over the weekend.
[4]
Essentially, if you use the app to crop out sensitive stuff from a screenshot, Google's code doesn't properly shrink the actual file, leaving the cropped-out portion lurking at the end of the data string, which can be potentially reconstructed. Even though you can't see the cropped out area in an image viewer, the data is still there in the file and can be possibly recovered.
[5]
[6]
That means if someone gets hold of your cropped image, they can try to recover the seemingly missing part. If the image was redacted by scribbling over certain areas, those areas may be visible in the restored picture. This is not great for privacy.
Google has patched aCropalypse, which Buchanan said will be tracked as [7]CVE-2023-21036 , in its [8]March Pixel security updates . That's all well and good going forward – now you can crop, redact, and share without fear your future images can be recovered – but there's no unsharing screenshots that are vulnerable to the exploit that you've already passed around, uploaded to Discord, etc.
[9]
Buchanan said Google hasn't issued a security advisory about the bug yet. We've asked the ad giant how it plans to handle notifying affected Pixel owners that they may have sensitive data floating around online, and we didn't hear back by press time.
T is for truncate, and it is not implied (in Android 10+)
Buchanan's write-up goes into considerable detail as to how he found what he believes to be the root cause of aCropalypse: a [10]silent change from Android 9 to Android 10 in which the OS-provided Java function [11]parseMode () now requires the argument "wt" when an app wishes to overwrite and truncate a file to a shorter length, not just "w".
In the past, "w" would truncate a file anyway; from Android 10, the function needs an explicit "wt". Google's Markup was still using "w" when it should have used "wt", so the truncation never happened on Android 10+, leaving previous image data at the end of the PNG file.
According to Aarons, "when you crop and save a screenshot, [Markup] overwrites the image with the new version, but leaves the rest of the original file in its place" because Markup isn't telling Android to truncate the file when writing changes to it.
(Technically speaking, parseMode() just converts a string describing the kind of access an app wants, eg "wt", into a bitmask to use with open() . parseMode() doesn't perform the actual file access, it helps the app prepare for it.)
[12]Signal goes Gaussian to take privacy to the next level: All your faces don't belong to us
[13]LowKey cool: This web app will tweak your photos to flummox facial-recognition systems, apparently
[14]Extreme photo-bombing: Bad ImageMagick bug puts countless websites at risk of hijacking
[15]eBay eBabe enigma explained: Microsoft bug blamed after topless model slings e-souk's emails at stunned Brits
"The end result is that the image file is opened without the [truncate] flag, so that when the cropped image is written, the original image is not truncated," Buchanan said. "If the new image file is smaller, the end of the original is left behind."
The bits of the file that were supposed to be truncated were found to be recoverable as images after doing some reverse-engineering of the zlib compression library's methodology, which Buchahan says he was able to do "after a few hours of fiddling around." The end result is a proof of concept that anyone with an affected Pixel device can [16]try out for themselves.
[17]
While you're at it, be sure to install the latest round of Android security updates, Pixel device or not.
What to make of it? If you have an affected Pixel device, and you've cropped or redacted screenshots and shared them, whoever has them can potentially recover that data. Once you've installed the update, future screenshots should be OK. ®
Get our [18]Tech Resources
[1] https://twitter.com/ItsSimonTime/status/1636857478263750656?s=20
[2] https://twitter.com/David3141593/status/1636979464688087040
[3] https://www.da.vidbuchanan.co.uk/blog/exploiting-acropalypse.html
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-21036
[8] https://source.android.com/docs/security/bulletin/pixel/2023-03-01
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://issuetracker.google.com/issues/180526528?pli=1
[11] https://developer.android.com/reference/android/os/ParcelFileDescriptor#parseMode(java.lang.String)
[12] https://www.theregister.com/2020/06/05/signal_blur_tool/
[13] https://www.theregister.com/2021/01/21/lowkey_facial_recognition/
[14] https://www.theregister.com/2016/05/03/imagemagick/
[15] https://www.theregister.com/2019/09/10/ebay_microsoft_bug/
[16] https://acropalypse.app/
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://whitepapers.theregister.com/
Reverse engineers Simon Aarons and David Buchanan, who found the bug and produced a proof-of-concept recovery tool, respectively, dubbed it [1]aCropalypse , and [2]noted "this bug is a bad one" for folks concerned about their privacy.
The flaw lies in how Google's image-editing app Markup, available for the Pixel line, truncates PNG files after they are edited – namely, it doesn't, Buchanan detailed in a [3]write-up over the weekend.
[4]
Essentially, if you use the app to crop out sensitive stuff from a screenshot, Google's code doesn't properly shrink the actual file, leaving the cropped-out portion lurking at the end of the data string, which can be potentially reconstructed. Even though you can't see the cropped out area in an image viewer, the data is still there in the file and can be possibly recovered.
[5]
[6]
That means if someone gets hold of your cropped image, they can try to recover the seemingly missing part. If the image was redacted by scribbling over certain areas, those areas may be visible in the restored picture. This is not great for privacy.
Google has patched aCropalypse, which Buchanan said will be tracked as [7]CVE-2023-21036 , in its [8]March Pixel security updates . That's all well and good going forward – now you can crop, redact, and share without fear your future images can be recovered – but there's no unsharing screenshots that are vulnerable to the exploit that you've already passed around, uploaded to Discord, etc.
[9]
Buchanan said Google hasn't issued a security advisory about the bug yet. We've asked the ad giant how it plans to handle notifying affected Pixel owners that they may have sensitive data floating around online, and we didn't hear back by press time.
T is for truncate, and it is not implied (in Android 10+)
Buchanan's write-up goes into considerable detail as to how he found what he believes to be the root cause of aCropalypse: a [10]silent change from Android 9 to Android 10 in which the OS-provided Java function [11]parseMode () now requires the argument "wt" when an app wishes to overwrite and truncate a file to a shorter length, not just "w".
In the past, "w" would truncate a file anyway; from Android 10, the function needs an explicit "wt". Google's Markup was still using "w" when it should have used "wt", so the truncation never happened on Android 10+, leaving previous image data at the end of the PNG file.
According to Aarons, "when you crop and save a screenshot, [Markup] overwrites the image with the new version, but leaves the rest of the original file in its place" because Markup isn't telling Android to truncate the file when writing changes to it.
(Technically speaking, parseMode() just converts a string describing the kind of access an app wants, eg "wt", into a bitmask to use with open() . parseMode() doesn't perform the actual file access, it helps the app prepare for it.)
[12]Signal goes Gaussian to take privacy to the next level: All your faces don't belong to us
[13]LowKey cool: This web app will tweak your photos to flummox facial-recognition systems, apparently
[14]Extreme photo-bombing: Bad ImageMagick bug puts countless websites at risk of hijacking
[15]eBay eBabe enigma explained: Microsoft bug blamed after topless model slings e-souk's emails at stunned Brits
"The end result is that the image file is opened without the [truncate] flag, so that when the cropped image is written, the original image is not truncated," Buchanan said. "If the new image file is smaller, the end of the original is left behind."
The bits of the file that were supposed to be truncated were found to be recoverable as images after doing some reverse-engineering of the zlib compression library's methodology, which Buchahan says he was able to do "after a few hours of fiddling around." The end result is a proof of concept that anyone with an affected Pixel device can [16]try out for themselves.
[17]
While you're at it, be sure to install the latest round of Android security updates, Pixel device or not.
What to make of it? If you have an affected Pixel device, and you've cropped or redacted screenshots and shared them, whoever has them can potentially recover that data. Once you've installed the update, future screenshots should be OK. ®
Get our [18]Tech Resources
[1] https://twitter.com/ItsSimonTime/status/1636857478263750656?s=20
[2] https://twitter.com/David3141593/status/1636979464688087040
[3] https://www.da.vidbuchanan.co.uk/blog/exploiting-acropalypse.html
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-21036
[8] https://source.android.com/docs/security/bulletin/pixel/2023-03-01
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://issuetracker.google.com/issues/180526528?pli=1
[11] https://developer.android.com/reference/android/os/ParcelFileDescriptor#parseMode(java.lang.String)
[12] https://www.theregister.com/2020/06/05/signal_blur_tool/
[13] https://www.theregister.com/2021/01/21/lowkey_facial_recognition/
[14] https://www.theregister.com/2016/05/03/imagemagick/
[15] https://www.theregister.com/2019/09/10/ebay_microsoft_bug/
[16] https://acropalypse.app/
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZBjljpSIC7hdW@XoHniCEwAAAIk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[18] https://whitepapers.theregister.com/
Hmmm
James O'Shea
I don't have this problem because:
1. I have an iPhone, not an Android
2. even if Apple is sufficiently stupid as to have a similar bug, I upload all (repeat, ALL) photos to one of my computers (Apple, Windows, Ubuntu, usually a Mac 'cause it's easiest) and DELETE THEM FROM THE BLOODY PHONE. All image manipulation is done on a desktop machine. I might, if I feel like it, stick any photos I want on the phone into something like Apple's Photos, which cloudifies stuff; I don't usually use Photos, in large part because I don't bloody trust cloudy crap. (Yes, the photos are automagically dropped into Photos ninth first place. Yes, I nuke 'em good from Photos. If the photos ain't on the bloody phone, or in the bloody cloud, they can't be bloody hacked.) At the current time I have exactly 15 photos on my two iPhones. Three of them are images used as wallpaper for the phones and an iPad, I didn't like the wallpaper which shipped with the iDevices.
3. if I had an Android I still wouldn't have this problem, see 2. above. I used to have an Android, a Very Long Time Ago. When I did have the Android, I'd feed photos (I didn't have many, the Android was shitty, had a bad camera and not much space and I didn't have it for long anyway) to Windows machines, work there, and delete from the phone. Mostly to conserve space, that thing was really short on storage.
Can someone explain to me why people keep lots of photos on phones and even do image manipulation there?
Re: Hmmm
Sandtitz
"Can someone explain to me why people keep lots of photos on phones and even do image manipulation there?"
Some people don't have a computer.
Some people may find the manipulation tools on the phone good enough.
Really??
a silent change from Android 9 to Android 10 in which the OS-provided Java function parseMode() now requires the argument "wt" when an app wishes to overwrite and truncate a file to a shorter length, not just "w".
You changed the operation parameters of an existing operator, one with a long legacy, and thought this was OK??! You should have put -t as a new option for NOT truncating, not change a known pattern of operation and then make a mandatory (-wt) to-use switch to get it back to the way it was for over a decade.
:shakes head: And you thought Google programmers were intelligent. I guess this proves that wrong.