Note: the base problem for me is to be able to access a network share that I (Win 7 admin user) have set up when I run an elevated program. Normally the elevated program will not have access to my non-elevated network shares.
According to Microsoft the registry setting EnableLinkedConnections will allow elevated processes to access the network share of the currently logged in (non-elevated) explorer process.
This explanation makes some sense:
[…] When you’re a member of the
Administrators group and you log in,
your account is busted down to a
non-privileged user by UAC. This
running context is completely separate
from the context you get when you
right-click Command Prompt and launch
as an administrator. As you’ll
probably have noticed, network drives
connected in one context are not
visible in the other. […]
This forum thread asks about the vulnerabilities opened by this setting. The answer given links to an article about disabling UAC prompts (or so I understand).
The question now is, what does the registry setting EnableLinkedConnections do or allow on a Windows 7 system, given that we are not running in a domain environment.
Edit: One thing that I'm specifically interested in is whether this setting only affects the (visibility of) network drives or whether it has any other implications.
Best Answer
Not having source access to Windows it's difficult to say anything that isn't speculation. That disclaimer aside, here's what I've been able to glean by reading up on this:
UAC creates two security tokens on logon: the elevated token containing the user's full group memberships, and the restricted token which has membership of the "Administrators" group stripped out. Each token contains a distinct locally unique ID (LUID) that identifies the logon session. They are two separate and distinct logon sessions.
Starting in Windows 2000 Server SP2, mapped drives (which are represented as symlinks in the object manager namespace) are tagged with the LUID of the token that created them (you can find some Microsoft references to this behavior in this KBase article, and you can learn more about the mechanics of the feature in this blog posting). The gist of the feature is that mapped drives created by one logon session are not accessible to another logon session.
Setting the EnableLinkedConnections value triggers a behaviour in the LanmanWorkstation service and the LSA security subsystem (LSASS.EXE) to cause LSA to copy drives mapped from by either one of the users' tokens into the context of the other token. This allows drives mapped with the elevated token to be visible to the restricted token and the converse. There isn't any peculiarity of the behavior of this feature w/ respect to a domain versus non-domain environment. If your users are running with "Administrator" accounts in a non-domain environment their restricted tokens and elevated tokens, by default, will have independent drive mappings.
In terms of vulnerabilty, official documentation from Microsoft seems to be lacking. I did find a comment and a response from a Microsoft employee asking about the potential vulnerabilities in a conversation about UAC from 2007. Given that the answer comes from Jon Schwartz, who, at the time, was titled "UAC Architect", I'd tend to consider his answer having credibility. Here's the gist of his answer to the following inquiry: "...I have not found any information to describe what is actually happening technically or if this opens any kind of UAC loopholes. Can you comment?"
Personally, I can't think of a way to "exploit" this loophole, insofar as "seeding" the elevated token with a drive mapping would still require the user to actually elevate and execute something malicious from that "seeded" drive mapping. I'm not a security researcher, though, and I may not be approaching this with a good mind-set to come up with potential exploits.
I've dodged using the EnableLinkedConnections value in my Customer sites by continuing the trend that we began when Customers started deploying Windows NT 4.0-- having users logon with limited user accounts. That's worked well for us for years and continues to work well in Windows 7.