When people ask for security holes as features: Non-administrators reading other users’ stuff

Via the suggestion box, Aaron Lerch asks whether a non-administrator can retrieve/evaluate environment variables as they would appear for another user.

This falls into the category of asking for a security hole as a feature, specifically an information disclosure security hole, because you are extracting information from a user's private data which has security access controls that do not grant everybody access. Generally speaking, users have full access to their data, as does the operating system itself, but nobody else. Administrators can get access to the data by taking ownership and modifying the ACL or using security overrides like Se­Debug­Privilege, but that's the general idea. And certainly, unprivileged users don't have access to the data from other unprivileged users.

The way to get a user's initial environment variables is to call the Create­Environment­Block function, passing the token of the user you are interested in. Note that it's more than just scraping the registry, because you also have to take into account group policy objects and the possibility that the information in the registry is incorrect because it is a stale cached roaming profile.

Comments (14)
  1. dartme18 says:

    Dear Mr. Raymond,

      I have an off-topic question for the Suggestion Box, but can’t find a functional Suggestion Box.  It seems the original one, the second one and the third one are closed for comments, and I can’t find any others.  Could you perhaps add a link from the words "suggestion box" in your post above (words 3 and 4 of the body of the message)?



  2. David Walker says:

    Did you bother to read the end of the "suggestion box" topic?  

    The suggestion boxes are closed because there

    is a huge backlog that Raymond is working from.  You’ll have to be patient; a new one may open eventually.

    Although, the topic itself lists Raymond’s guess that the box will reopen in "early 2010".  Now that it IS early 2010, Raymond could perhaps update that estimate.  Or not; it’s his blog.  :-)

  3. Alexandre Grigoriev says:

    Environment variables are evil. Those that are set system-wide by ISVs. And the most evil is PATH. ISVs stick their stuff in there mindlessly, even though it’s not required or can be easily made unnecessary.

  4. Joseph Koss says:


    I wouldnt say that PATH’s are evil. Its fine when USERS rely on path settings ("I want to launch FOO and I can’t be bothered to describe its location) but its evil when PROGRAMS rely on path settings ("I’m a lazy programmer that needs to launch FOO but cant be bothered to find FOO’s location")

  5. Gabe says:

    In the case of the original question, though, the bulk of the answer doesn’t apply. Aaron thought he wanted non-admin access to environment variables for other users so he could delete their log files. Odds are that LocalService wouldn’t have access to their log files anyway, so he would want to run his service as LocalSystem. At that point he is an administrator and should be able to get other users’ environment variables.

    Of course that probably doesn’t change the answer very much. Even as LocalSystem he’s still going to need the user’s token to get their environment variables.

  6. Alexandre Grigoriev says:

    @Joseph Koss:

    See HKLMSOFTWAREMicrosoftWindowsCurrentVersionApp Paths

  7. Dave says:

    @Alexandre, read the last paragraph of the post. Besides, the App Paths key is deprecated, replaced by CSIDL values, which itself has been deprecated and replaced by KNOWNFOLDERID values.

  8. Alexandre Grigoriev says:


    The most recent SDK documentation http://msdn.microsoft.com/en-us/library/ee872121(VS.85).aspx doesn’t say App Paths is deprecated. CSIDL values and KNOWNFORDERID are completely different animal.

  9. MarkKB says:

    @Dave: I think you’re thinking about HKLMSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders and HKCUHKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders. Not the same thing.

    App Paths is basically a place where apps can register their location so other apps can find them easily. If there’s an API for it apart from via the Registry, I’m certainly not aware of it.

  10. admin>non-admin says:

    It’s ok that non-admins cannot do this. But when not even a admin/root user can do stuff (like retrieving a user’s profile directory) there’s a problem. Then you have to read it from registry and hope that windows n+1 doesn’t change it’s logic.

    GetUserProfileDirectory() should have a parameter, Sid, so admins can get user’s directories.

  11. John says:

    @admin: I think the point is that you can only be sure the (possibly roaming) profile is valid if the user is logged in, thus the parameter is a token instead of a sid.  What would you do with the path if you could get it without the user being logged in?  If you read something, the data could be stale (not a big deal, I guess); if you write something, you could cause data loss (definitely a big deal).

  12. admin<non-admin says:

    I want to delete the data because the user is removed from AD!

  13. admin says:

    And you think I havn’t tried that API?

    DeleteProfile() is broken by design (I think Russinovich blogged about the details). Files doesn’t get deleted by this API. Profiles in registry doesn’t get unmounted and erased by this API.

Comments are closed.