It’s not a security vulnerability that users can access files that they have access to, even if the file is a little hard to find
If a user has access to a file, then they can access the file. That seems self-evident.
Putting that accessible thing in a hard-to-find place doesn’t make it inaccessible. It just makes it hard to find.
In Windows, you can put a file in a directory that the user does not have access to, but if the user can produce the name of the file, they can still access it. This works because Windows by default enables “bypass traversal checks”, which means that you can access anything you can name.
This technique is a useful trick if you want the user to be able to access something by name, but you don’t want to reveal what other nearby things are present but not accessible. You can read more about this scenario in this old Windows Confidential article.
In Windows, we sometimes make a directory non-enumerable despite having accessible contents in order to create an obstable to keep casual users away from places that they probably shouldn’t be going. For example, the %USERPROFILE%\Start Menu directory is a non-enumerable link to %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu. That link exists for backward compability, so that programs which hard-coded the string Start Menu (instead of using a function like SHGetÂSpecialÂFolderÂPath) would still land in the right place. But the directory is non-enumerable because we don’t want users browsing around in Explorer and clicking into that directory, thinking that it’s the recommended way to find their Start menu.
Similarly, the %PROGRAMFILES%\WindowsApps directory is non-enumerable to prevent users from browsing into it with Explorer and trying to double-click the programs in it. Double-clicking those programs won’t work, because they are UWP apps which execute in a special environment that needs to be set up first. Blocking enumeration prevents users from getting themselves into trouble. The programs themselves and their associated data files must still be readable, because when the program runs, it needs to be able to read those data files.
This means that if you can guess¹ the name of a subdirectory inside the WindowsApps directory, you can dive in and snoop around. There’s no security hole here. You always had access to those files. You just had to know where they were.
¹ And really, you don’t need to guess. PowerShell will tell you.
Get-AppxPackage | Select InstallLocation
Light
Dark
7 comments
On Windows 10 version 1909,
%PROGRAMFILES%\WindowsAppshas a fancy conditional ACE:(XA;;0x1200a9;;;BU;(Exists WIN://SYSAPPID))The PowerShell command also shows several packages under
C:\Windows\SystemApps, which is enumerable byBUILTIN\Userswithout conditions.Interestingly (or not) you can view the WindowsApps directory in a store application such as Paint.NET and go to the file dialog. This is because Desktop Bridge (and sandboxed UWP) applications have the WIN://SYSAPPID security attribute set which allows you to enumerate that directory. It’d be most obvious in the legacy File Manager that MS released, however I can’t seem to find a way of navigating to a hidden directory.
>”%PROGRAMFILES%\WindowsApps directory is non-enumerable to prevent users from browsing into it with Explorer and trying to double-click the programs in it. ”
I guess I must be doing it wrong
I pasted “%PROGRAMFILES%\WindowsApps” into explorer and had no problem. I was able to go into that directory, view everything and and I even deleted a few files, just to see if I could (I immediately restored them from the recycle bin)
Most probably you did wrong before: whenever you (try) to browse a non-enumerable directory like %PROGRAMFILES%\WindowsApps or %SYSTEMROOT%\Temp with File Explorer in a standard installation of Windows, i.e. under the qUACkery-controlled user account created during setup, you will be asked whether File Explorer should grant your user account permanent full access to this directory. See https://support.microsoft.com/en-us/help/950934/when-you-click-continue-for-folder-access-in-windows-explorer-your-use for this brain-dead behaviour.
The statement is slightly inaccurate, to be completely accurate it should be:
> “%PROGRAMFILES%\WindowsApps directory is non-enumerable by standard users”
Administrators can enumerate the directory, this means that if you open up a command prompt running as an administrator, navigate to this directory and use the dir command, it will list the contents of the directory.
I’m not sure how Explorer acts when you disable UAC too. Windows 10 uses a split token, but it will automatically link the admin token to the restricted token meaning that it can always elevate without going through the UAC prompting.
For some reason, the WindowsApps folder is the first location that I immediately think of when reading the first half of article.
Ever thought of going into advertising?