Thread by @sjmurdoch

I did a little digging to see why Windows Snip and Sketch leaves part of the old image in a file when you crop a screenshot, potentially disclosing sensitive information (Acropalypse). It looks like the new Windows Save File API is defective by design. Why do I say this?🧵 1/9

The old Win32 API for saving a file was (roughly) to show a file picker, get the filename the user selected, and then open the file. To open a file, the programmer must specify whether to overwrite the file or not, and example code usually does overwrite the file. 2/9

However, the new “more secure” Universal Windows Platform (UWP) sandboxes the file picker in a separate process, allowing neat features like capability-based access control. It returns a file handle which, if the selected file exists, will not overwrite the existing content! 3/9

Unless the programmer explicitly adds a line to truncate the file, the existing file’s content will be kept. If the data written is smaller than the size of the existing file, the old content will remain, resulting in puzzled StackOverflow posts, e.g. stackoverflow.com/questions/3584… 4/9

The documentation for FileSavePicker doesn’t mention the problem or truncate files in the example code. It is no surprise that the default behaviour of not truncating existing files is, therefore commonplace, despite being not what most people want. 5/9 learn.microsoft.com/en-us/uwp/api/…

For some formats, the resulting file will be detected as corrupt, and the bug will be recognised. However, software often follows Postel’s Law – “be conservative in what you send, be liberal in what you accept” and so quietly ignores the old data after the expected content. 6/9

The general lessons for this are not new, but bears repeating: secure defaults matter, including for APIs, and example code should be secure. Microsoft normally tries to do this, but something has obviously slipped through here. 7/9

Perhaps it is also time to move on from Postel’s Law. It was important for the growth of the Internet but is now becoming a liability. Rejecting invalid input can help identify problems earlier when they have had less opportunity to cause harm. 8/9

For more details about Acropalypse, see the post by @ItsSimonTime, who originally discovered it as affecting Google Pixel Markup

https://twitter.com/ItsSimonTime/status/1636857478263750656

and @David3141593 noting the problem with Snip and Sketch

https://twitter.com/David3141593/status/1638222624084951040

9/9

I installed Visual Studio and kept on digging. It looks like if you only use FileIO to manipulate the opened file, it is OK, but if want to do anything more interesting you have to open the file as a stream and then the vulnerable default behaviour is a problem. 10/n

For example, FileIO.WriteBytesAsync() truncates the stream before writing. This example is closely based on the Windows UWP demonstration code. 11/n

But if we change the code to open the stream and write to it through a DataWriter, it does not truncate the file before writing. 12/n

I don’t know what Windows is doing under the hood (as far as I know, this part is not open source), but we can look at Uno, which is designed to be compatible. This shows that the FileIO operations explicitly need to truncate the file before writing. 13/n github.com/unoplatform/un…

Overall I think my conclusions still hold. The example code works, but if modified in a way that should be expected, it is insecure. The API for opening a file selected by a picker will, by default, not overwrite an existing file, which is almost always not what is intended. 14/n

A safer API would be for the FileSavePicker to truncate existing files by default. Alternatively, OpenAsync() could have the option to open the stream for writing. Currently, it is only Read and ReadWrite, unlike the far richer Win32 CreateFile API. 15/n

As an aside, OpenAsync has a very anaemic API. Win32 CreateFile allows checking for an existing file before opening and setting security parameters. These steps are atomic with opening the file, but if UWP doesn’t support atomic operations could it cause race conditions? 16/n

I can see why programmers could be easily confused, even if they work for Microsoft. Here’s some documentation that presents the FileIO and OpenAsync as interchangeable approaches when only the former will safely truncate a file that already exists. 17/n learn.microsoft.com/en-us/windows/…

There might be a way to automatically scan for vulnerable behaviour using Process Monitor. If anyone is interested in trying, here's a starting point.

https://twitter.com/sjmurdoch/status/1639318794777640974?s=20