January 13th, 2020

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

Raymond Chen
Raymond Chen

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

 

Category
Old New Thing
Topics
Other

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

7 comments

Discussion is closed. Login to edit/delete existing comments.

Newest
Newest Popular Oldest
  • Michael Dunn

    Ever thought of going into advertising?

  • cheong00

    For some reason, the WindowsApps folder is the first location that I immediately think of when reading the first half of article.

  • Harold H

    >”%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)

    • Me Gusta

      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...

      Read more
    • Stefan Kanthak

      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.

      Read more
  • Kalle Niemitalo

    On Windows 10 version 1909, %PROGRAMFILES%\WindowsApps has a fancy conditional ACE: (XA;;0x1200a9;;;BU;(Exists WIN://SYSAPPID))

    The PowerShell command also shows several packages under C:\Windows\SystemApps, which is enumerable by BUILTIN\Users without conditions.

    • James Forshaw

      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.

Read next