Newly discovered data access breach in Win10 UWP (Metro, “Store”) apps

Topic

New Reply

There’s a bug in the UWP API that lets appropriately programmed apps look at all of your data. Günter Born says: (The malicious UWP) app is not limite
[See the full post at: Newly discovered data access breach in Win10 UWP (Metro, “Store”) apps]

4 users thanked author for this post.

Fred, GreatAndPowerfulTech, PhotM, lanceboil

Reply | Quote

Replies

Well, that tears it. Even if Microsoft fixes the bug, I’ll never move to Win10 whatever. Neither Home nor Pro! Yes, I know it will be fixed… but what’s to stop some coder from breaking it again? It’s always been a matter of trust, but MS just lost mine for good when it comes to Windows 10. As long as they don’t break Win8.1 before 2023… bugs start popping up after January 2020, then Linux Mint, here I come!

Bought a refurbished Windows 10 64-bit, currently updated to 22H2. Have broke the AC adapter cord going to the 8.1 machine, but before that, coaxed it into charging. Need to buy new adapter if wish to continue using it.
Wild Bill Rides Again...

4 users thanked author for this post.

johnf, HiFlyer, lurks about, Charlie

Reply | Quote

The store process means that apps are vetted so isn’t this a theoretical attack rather than one we will see in reality?  It’s like the iPhone bugs that they say “first you have to jailbreak the device”…. well yeah….

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

HiFlyer

Reply | Quote

This isn’t theoretical if Microsoft vetting isn’t reliable, and Microsoft patching all but guarantees that it isn’t.

1 user thanked author for this post.

Fred

Reply | Quote

I’ll see if I can find it but I recall a stat that indicated that the Windows store apps actually had less malicious apps than Apple and Android.  Vetting was indeed very good.

Susan Bradley Patch Lady/Prudent patcher

2 users thanked author for this post.

rc primak, HiFlyer

Reply | Quote

The store process means that apps are vetted…

Apparently they vet as good as they test patches link…

1 user thanked author for this post.

WildBill

Reply | Quote

What I understood was the problem is UWP apps were granted extensive file reading (writing?) privileges even when the developer did not invoke them or request them. Thus it sounds like a carefully crafted app could harvest files from anywhere on the box and send them to their mothership. How practical this mode would be; I do not know.

1 user thanked author for this post.

rc primak

Reply | Quote

No, the developer has to invoke the “broadFileSystemAccess” capability AND “supply additional descriptions of why your app needs this capability, and how it intends to use it” to Microsoft if it’s a Store app:

https://docs.microsoft.com/en-us/windows/uwp/files/file-access-permissions#accessing-additional-locations

Reply | Quote

You do realize that this “security breach” only allows UWP apps to do the same thing that standard windows apps from Windows 7 or 8 can already do? Without asking? Always?

1 user thanked author for this post.

b

Reply | Quote

Surely not! Windows 10 is the most secure version of Windows, is it not?

Thanks for the info, Woody.

2 users thanked author for this post.

lurks about, Fred

Reply | Quote

Ha Ha Ha – whew, I needed a good laugh!  If you have to ask – well you know.

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

Reply | Quote

And the hits keep on coming, lol.

Reply | Quote

woody wrote:

There’s a bug in the UWP API that lets appropriately programmed apps look at all of your data.

But there are unlikely to be any such apps (apart from Microsoft’s App Installer and Diagnostics Data Viewer) because;

If you submit an app to the Store that declares this capability, you will need to supply additional descriptions of why your app needs this capability, and how it intends to use it.
Docs / Windows / UWP / Develop / Files, folders, and libraries / File access permissions

And the capability can be disabled per device, per user or per app.

As for the app crash on 1809; that sounds like a programmer error:

Some capabilities provide apps with access to a sensitive resource. These resources are considered sensitive because they can access the user’s personal data or cost the user money. Privacy settings, managed by the Settings app, let the user dynamically control access to sensitive resources. Thus, it’s important that your app doesn’t assume a sensitive resource is always available.
Docs / Windows / UWP / Develop / Packaging apps / App capability declarations

1 user thanked author for this post.

rc primak

Reply | Quote

There are definitely nuances. In this case, it appears as if the app did NOT come from the Store.

1 user thanked author for this post.

rc primak

Reply | Quote

… so, let’s see…

1. UWP apps from outside the Store have direct filesystem access on by default in previous versions of Windows 10, but off by default in 1809. The bug is that the permission dialog doesn’t display automatically on first instance of the specific app requiring this permission.

2. UWP apps that need direct filesystem access and don’t have it, throw an exception that defaults to crashing the app unless caught. The permission state can change while app is running and takes effect immediately.

Now, unless there’s something even weirder going on, surely the user’s UWP apps still run in the normal user context and thus only have at most as much capability as the user’s non-UWP processes, thus not causing any inherent extra risk just due to being UWP? Such as in this case with a business-specific internal app, apparently…?

What I find potentially somewhat risky is the unexpected state change, which logically might prevent the app from saving its data to disk, thus having the potential for data loss. This is not markedly different from non-UWP apps running into an unexpected permissions problem at file open time but might differ for files that were already open, or does the UWP platform prevent continuously open files or something?

 

Not going into whatever may be going on with the Store – the “vetting” processes would reduce risks but not eliminate.

Reply | Quote

… hm, it seems that the “broad filesystem access” privacy settings entry just isn’t there at all in at least W10 1709…

Now, from https://stackoverflow.com/questions/49728846/uwp-c-sharp-folderpicker-without-dialog and elsewhere, broad filesystem access was supposed to either not exist or default to off in older versions.

Anyone know which versions are vulnerable, then? From context I’d guess at least 1803 but could go way back…

 

 

Reply | Quote

Looks to me like only 1803 (not earlier versions) could possibly have been regarded as vulnerable, and 1809 is not.

But the guy who discovered the bug has now updated his blog entry, and I’m not convinced that he ever considered it to be exploitable:

Update: There has been a bit of misunderstanding on how this works. The broadFileSystemAccess is a restricted capability that an application could be granted, it is not an API. As a developer as well, I have to opt-in to using the capability. Any application in the store with the capability goes through extra verification by the Store team before any user gets it and the user is aware they are granting the application the permission to use the capability as well.
Important information about the new capability of broadFileSystemAccess in UWP apps

Reply | Quote

Fixed:

Addresses a privacy issue with apps that obtain the BroadFileSystemAccess capability without a user’s consent.

January 15, 2019—KB4480976 (OS Build 17134.556)

Reply | Quote