[HN Gopher] Windows Snipping Tool is vulnerable to Acropalypse too
___________________________________________________________________
Windows Snipping Tool is vulnerable to Acropalypse too
Author : tambourine_man
Score : 170 points
Date : 2023-03-21 18:03 UTC (4 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| dang wrote:
| Recent and related:
|
| _Exploiting aCropalypse: Recovering truncated PNGs_ -
| https://news.ycombinator.com/item?id=35208721 - March 2023 (71
| comments)
|
| _Acropalypse: a vulnerability in Google 's screenshot editing
| tool_ - https://news.ycombinator.com/item?id=35207787 - March
| 2023 (44 comments)
| eviks wrote:
| yet another example of stellar s engineering from yet another s
| engineering giant
| world2vec wrote:
| This is beyond scary. I have no idea how my screenshots I took
| and cropped with Snipping Tool and send to someone: at work, at
| home, across multiple machines and accounts.
| easrng wrote:
| Keep in mind this only applies if you took the screenshot,
| saved, cropped it, and then saved again to the same file.
| world2vec wrote:
| I am aware after reading the whole thread but still, I think
| I've done it countless times over the years.
| sp332 wrote:
| Well yeah, why would I keep an uncropped version around? It
| seemed safer to save over the one I didn't want.
|
| Edit: I guess I don't usially _save_ before cropping a
| screenshot. But it 's not something I really thought about
| before either.
| dendrite9 wrote:
| Isn't that the default on Android phones if you screenshot
| then crop. As opposed to screenshot, then open it and crop.
|
| I tend to use the rectangular option in the snipping tool as
| a way to be certain that I won't forget to crop important
| info. Both of these make me think I need to check my process
| and see if it is relevant.
| mizaru wrote:
| It applies if you choose to "overwrite" any file that is
| larger than the generated PNG data.
| nickthegreek wrote:
| My normal workflow is use snipping tool, it opens in editor,
| crop, save. This is for sure safe?
| SketchySeaBeast wrote:
| It seems like the problem is that if you use the snipping
| tool to save to a file that already exists it only modifies
| as much of the file as is required so that the new image
| you saved is visible - the rest of the file's data is
| preserved. The problem is saving to a file with more
| information than the cropped information requires - the
| original images information "overflow" isn't removed. So if
| you're saving to a new file it's fine, there's no extra
| information.
| ChuckNorris89 wrote:
| _> Keep in mind this only applies if you took the screenshot,
| saved, cropped it, and then saved again to the same file_
|
| Wait, don't we all do this? _:looks around horrified:_
| basch wrote:
| My stubbornness to relearn and move away from
| "printscreen+winkey+r+mspaint+enter+select+Ctenophora+c" pays
| off. I don't know what it is about snipping tools (and I use
| sharex too" but I always find myself going back to paint, as
| the tools feel like they get in the way.
| hermitdev wrote:
| Try alt+printscreen. It'll only capture the active window
| instead of your full desktop.
| smackeyacky wrote:
| Our security people disabled the PrtScn key, so our only
| way of doing a screen shot is the snipping tool. It is very
| frustrating.
| [deleted]
| basch wrote:
| I do if I want the window. Crops are something else.
| froggit wrote:
| I've always used "prtscn+paint" as well. I've tried various
| on other ways and I'll usually be like "that's kinda cool,
| maybe I'll try that." Next time I need a screenshot it'll
| already be pasted in paint far before it occurs to me "i
| think i forgot something, guess it wasn't important."
| alpb wrote:
| Note that this is not the "Snipping tool" but the "Snip & Sketch"
| (win+shift+s?) Though, I'm not able to reproduce it myself.
| lazerl0rd wrote:
| Snipping Tool used to have this "feature" whereby any drawing
| performed on a screenshot would be animated as an overlay (this
| was only visible in the UWP Photos app at the time). Funnily
| enough, that's the first thing that came to mind when I heard of
| Acropalypse.
| recursive wrote:
| What's this about? I just tried the repro (Snip, save, crop,
| save). Nothing obvious was amiss. The file looks ok. What's the
| vulnerability here?
| Retr0id wrote:
| Further context:
| https://www.da.vidbuchanan.co.uk/blog/exploiting-acropalypse...
|
| You should notice that the file size didn't actually get any
| smaller after you cropped it. The full-size image file is not
| truncated before the cropped version is written. The left-
| behind data can be recovered.
| omoikane wrote:
| The root cause seem to be an open mode which opens the
| original file for writing without truncation, but writing to
| the original file directly in the first place seemed
| precarious. The software I use tend to write to a temporary
| file first and then do a rename to replace the original file.
|
| The bit about recovering LZ77 stream without the prefix
| sounds very useful as a data recovery tool.
| fwlr wrote:
| 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 wrote:
| 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 :)
| CSMastermind wrote:
| 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
| Retr0id wrote:
| > 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
| fwlr wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| phendrenad2 wrote:
| Not sure if this person is being deliberately vague/obtuse, but
| it's unclear if this affects you if you save each screenshot as a
| new file, or only if you do the strange "overwrite existing file"
| thing the OP did.
| kccqzy wrote:
| Overwriting existing file is strange now? This is just victim-
| blaming for the incompetence of software engineers. As a user
| there's nothing wrong with overwriting an existing file.
| phendrenad2 wrote:
| Calling something unusual behavior, which is unusual, is
| "victim blaming"? Stop tilting at windmills.
| olliej wrote:
| They're not being vague - they're saying a specific issue named
| "acropalypse" applies.
|
| Originally acropalypse was a specific library, but the bug
| itself is "saving data over an existing file does not replace
| the existing file".
|
| > only if you do the strange "overwrite existing file" thing
| the OP did
|
| Overwriting an existing file is literally the most common case:
| it's what happens when you say "save" instead of "save as...".
| Hansenq wrote:
| Is Mac's Preview app susceptible to this bug too? Right now it
| seems only confirmed for Pixel phones and Windows Snipping Tool,
| but I use Preview and I haven't seen anyone confirm or deny it
| for that one.
| Retr0id wrote:
| I've heard multiple people say Preview (and the macos
| screenshot tools) are safe.
| windows2020 wrote:
| This does not apply to the original Snipping Tool (the one that's
| 'moving...').
|
| New iterations of classic Snipping Tool require more clicks and
| the implementation is worse too.
| TrianguloY wrote:
| My workflow is to press the PrintScreen -> snip&sketch opens ->
| draw a rectangle (two corners) -> paste where necessary.
|
| Or alternatively press the notification -> draw something ->
| control+c -> close then paste.
|
| I rarely save as file, no need, but I guess I've sometimes do it
| so I need to be careful.
| whoopdedo wrote:
| This reminds me of the early binary DOC file format that was
| essentially a dump of Word's working memory. You could find all
| sorts of leaked data in the slack space between text chunks.
| Sometimes from other processes since `malloc` doesn't zero
| memory. I think there were a few instances of people being caught
| doing bad things because of identifying information in a Word
| DOC.
|
| But why is this even happening? The standard procedure to
| overwrite a file is to save to a temporary file first so an error
| that occurs during the write won't damage the existing file. Are
| they really doing an in-place write and how does that affect the
| shadow copy if you wanted to restore the previous version of the
| file?
| iggldiggl wrote:
| > The standard procedure to overwrite a file is to save to a
| temporary file first
|
| ... which on the other hand has the annoying side effect of
| wrecking hard links.
| TazeTSchnitzel wrote:
| And various metadata!
| Retr0id wrote:
| It feels like a lot of "things everyone knows" are slowly
| getting lost over time, as developers work at higher and higher
| levels of abstraction without deep knowledge of the layers
| beneath them (which is of course the whole point of
| abstractions, but they're never perfect)
|
| Being a true "full stack" engineer is a superpower when it
| comes to performance optimisation, or vulnerability research.
| doubled112 wrote:
| I wanted to be a programmer as a kid, but eventually found it
| boring and switched to administering systems.
|
| Knowing how code works on systems IS a super power.
| saagarjha wrote:
| Eh, that's not really true. Adding abstraction allows for
| providing APIs that can handle cases like these correctly.
| For example, Apple provides a very capable versioning system
| for files that does "the right thing", which in this case
| would create a new file for reliability.
| Retr0id wrote:
| Sure, abstractions aren't inherently evil, but bad ones
| are. The abstraction you described sounds like a sensible
| one, which couldn't have been designed without a deep
| understanding of the system as a whole (or at the very
| least, the adjacent layers).
| izzydata wrote:
| The wordage "acropalypse" and this image chosen makes it seem
| like doing this is going to somehow break your computer. It is a
| bad vulnerability, but not that bad.
| [deleted]
| 323 wrote:
| This is worse than breaking your computer.
|
| Plenty of people send images around after cropping out
| sensitive parts.
| Retr0id wrote:
| The image chosen is not generic glitch-art, it is the unedited
| output of my image recovery exploit script. That's just what it
| looks like.
| jeffbee wrote:
| Saving a cropped image as an original with an edit list strikes
| me as a completely obvious and normal thing to do. It's an
| affordance that allows the user to go back and un-crop things. If
| you undertook a field survey you would find users who were glad
| for this feature and I imagine zero users who had been harmed by
| it.
|
| I don't understand all the brouhaha.
| devnullbrain wrote:
| >and I imagine zero users who had been harmed by it.
|
| Because it's a zero day!
|
| You can't imagine someone cropping out banking information,
| identifying information in anonymous contexts, confidential
| information?
| creatonez wrote:
| This is not an undo feature. And if it were, it wouldn't be
| what an end user expects out of a .png file, but rather a .psd
| or .xcf file.
| pavon wrote:
| That isn't what is happening in either the original bug for the
| Google Pixel Markup tool or this bug in the Windows Snipping
| Tool. What is happening is that the software is overwriting the
| original image with the new one, but not truncating the file,
| so if the new compressed image data is smaller than the old,
| the remainder of the old image still exists at the end of the
| file.
|
| This data is not made available to the user to uncrop the data
| at a later time, so it provides no benefit to the user, just
| risk of privacy violations.
| olliej wrote:
| > I don't understand all the brouhaha.
|
| Which you should take as a "maybe I have misunderstood the
| issue".
|
| This is not an edit list, or the ability to undo operations.
| The problem is you have an existing file ("foo.png" or
| whatever): oooooooooo
|
| then you make a new file with this data in memory:
| nnnnn
|
| This could be something like you opened the original foo.png
| file and made a change that results in the file shrinking, or
| it could be some completely unrelated data. Now you save this
| as foo.png and the editing program assumes opening a file for
| writing will erase the old data and writes out the new data.
| The end result is you have this file:
| nnnnnooooo
|
| e.g. the tail of the old file is still present in the file
| data. It turns out it's possible to recover the pixel data from
| those tail bytes, in spite of losing the compression state.
|
| Now the assumption that writing over an existing file will
| truncate/erase the original file is reasonable. That's the
| default behavior of most file IO APIs. I don't know what the
| windows app is doing, but the original android bug was an API
| that takes a mode string copied from posix's fopen, in which
| "w" means "open for writing, and erase any existing file", but
| then later on made an undocumented change that made opening a
| file with "w" no longer erase existing files.
| saagarjha wrote:
| Thank you for describing the sounds I made when I first heard
| this vulnerability described to me.
| Retr0id wrote:
| If you don't want to just take my word for it, there's some 3rd
| party confirmation and further analysis in this thread
| https://twitter.com/wdormann/status/1638235267919233024
|
| I'll have a windows-compatible PoC up at some point, might wait a
| little bit just to mitigate the 0day-ness heh
| nashashmi wrote:
| Not able to reproduce this. I'm not sure if anything remains
| after the iend. But the file size does become smaller. I have
| windows 10.
|
| Edit: tried this with snip and sketch. Also tried it with
| snipping tool. Fwiw, the latter results in a smaller file size.
| _trampeltier wrote:
| Yesterday I tryed to make PDFs smaller by "save as" or "print
| as PDF". They just got larger each time (up to 3x larger).
| basch wrote:
| Sounds like you rasterized the pdfs.
| Retr0id wrote:
| win10 snipping tool is not vulnerable, but "snip and sketch"
| is.
|
| > Fwiw, the latter results in a smaller file size.
|
| Implying the former does not result in smaller file size? If
| so, you've reproduced the vuln.
| TheJoeMan wrote:
| On W10 I'm prompted every time I use Snipping tool to "try
| snip and sketch" instead. I wonder if they'll pull this
| message with the vulnerability?
| zamadatix wrote:
| It seems more likely they would patch the issue in Snip and
| Sketch than patch the message.
| HALtheWise wrote:
| This would have been avoided if the PNG format (or at least one
| commonly used editor) required that the data filled the whole
| file, or rendered extra junk when there was extra data at the
| end.
| ProgramMax wrote:
| The PNG spec actually has wording to disallow data past the
| end. https://w3c.github.io/PNG-spec/#15FileConformance "3. No
| chunks or other content follow the IEND chunk."
|
| (I'm the PNG spec chair and also the person who discovered
| Snipping Tool is vulnerable.)
| Retr0id wrote:
| However, it also says:
|
| > The PNG decoder has to determine whether a syntax error is
| fatal (unrecoverable) or not, depending on its requirements
| and the situation. For example, most decoders can ignore an
| invalid IEND
|
| It doesn't explicitly mention what decoders should do on
| encountering data _after_ IEND, but The general philosophy
| for _decoders_ seems to be that errors should be handled
| gracefully where possible, even if the file is technically
| malformed (which is maybe something that could be clarified
| or expanded upon?)
| [deleted]
| gjsman-1000 wrote:
| Like he says on Twitter - was this deliberate? Doesn't _seem_
| like it yet, and there 's no proof of it, but it's pretty scary.
| There's excellent plausible deniability, and the law enforcement
| benefits could be substantial.
| Syonyk wrote:
| I was just about to ask, "Is this still coincidence, or have we
| jumped straight to enemy action?"
|
| That _two different tools_ fail in the same, "surface level
| invisible" but mighty convenient, and "Whoopsie, file
| operations are hard!" way... raises some interesting questions.
|
| Mostly, "What else of this nature is present in all our modern
| operating systems?" Because this sort of failure sure looks an
| awful lot like the "Underhanded C" contest from 2008:
| http://www.underhanded-c.org/_page_id_17.html Redact an image,
| while leaking a lot of information in the process to someone
| who "knows the trick."
|
| > _This is an excellent example of the contest's philosophy:
| make the code extremely simple, innocent, obvious, and wrong._
| pdntspa wrote:
| Unbelievable, I can't understand how people haven't noticed that.
| "Wow I crop an image and it doesnt get smaller WTF???"
|
| Man if I ran Windows 11 to think I might be the one who stumbled
| on this 0-day first....
| malka wrote:
| Most of the time theses images don't end up in the file system.
| They are going to the clipboard and then copied to a chat or
| imgur
| e4e5 wrote:
| But in this case it's luckily not vulnerable
| TonyTrapp wrote:
| Apparently Discord and probably other platforms don't
| remove the excess data at the end of the file. Maybe they
| will start doing that now. But for all the existing cropped
| screenshots out there, it definitely means that there is a
| vulnerability.
| shawnz wrote:
| Does the system clipboard API also preserve the excess
| data, though?
| rs999gti wrote:
| > Unbelievable, I can't understand how people haven't noticed
| that. "Wow I crop an image and it doesnt get smaller WTF???"
|
| Most people are not super techie computer users.
| [deleted]
| pdntspa wrote:
| Yeah, it's pathetic.
|
| Still... you don't need MOST people. You need ONE, with a
| blog or a youtube account. And it took how long?
| asdff wrote:
| Every techie person I know who deals with windows has not
| dared to move to windows 11 so far, so I'm not too to
| surprised. I looked it up and the data matches my anecdote,
| only 18% of windows users are on 11, almost 70% on windows
| 10.
|
| https://www.extremetech.com/computing/342819-windows-11-gai
| n...
| escapecharacter wrote:
| Compression ratios vary between different tools, I wouldn't
| expect an image file size to scale at all smoothly with its
| resolution
| pdntspa wrote:
| Yes, but that is not going to explain how a large crop
| eliminating 90% of the image area is not going to shrink the
| filesize more than a little bit
| legrande wrote:
| Got sent a few .PSDs (Photoshop format) and there was some
| artifacts which looked like they weren't intended for the
| recipient. Of course, this is part of the .PSD format and not a
| privacy issue _per se_. Just be careful sending .PSDs in an
| e-mail with stuff in them you don 't want the recipient to see.
| SAI_Peregrinus wrote:
| Photoshop has a checkbox to "delete cropped pixels", if
| unchecked using the crop tool again will show the entire
| original image. It also stores an undo history, so even with
| "delete cropped pixels" you can just undo the crop.
| ffhhj wrote:
| Wait until they find that censored parts of an image can be
| restored by AI.
| ribosometronome wrote:
| Restored or imagined?
| alex7734 wrote:
| You need to take a screenshot, save it, crop it and then resave
| over the same file.
|
| I mean it's bad, but... who does that?
|
| EDIT: It also happens if you take a completely different
| screenshot and just save over (overwrite) another (bigger) image.
| That's worse, but still not that common IMHO.
| 323 wrote:
| > who does that?
|
| Programmers do it all day ... with text files.
|
| Would you say the same thing if when you deleted some code it
| would actually still be there at the end of the file, after two
| pages of spaces?
|
| When you delete something and save it in a "final" format (like
| a PNG), you expect nothing which was deleted to be there.
| hn92726819 wrote:
| I don't think the comment was about expected behavior. It's
| about who would be suspetible to this. Saving text files is
| fine all the time, you're right. They're saying, how often do
| people perform the steps in that order?
| [deleted]
| Retr0id wrote:
| It's a relatively uncommon scenario, granted, but when you
| multiply those odds by the number of screenshots that get
| shared on a daily basis, it's pretty bad imho.
| pavon wrote:
| It is extremely common for me to realize I don't like the
| screenshot I took, and to save the replacement over the
| original file. It is pretty common for me to be more selective
| about what is in the replacement, and hence for it to be
| smaller than the original triggering this bug.
| olliej wrote:
| I would say that's the common case?
|
| 1. Take screenshot
|
| 2. Open screenshot
|
| 3. Edit screenshot
|
| 4. Save screenshot
|
| I don't think that "Save As..." the common case.
___________________________________________________________________
(page generated 2023-03-21 23:00 UTC)