Does enabling EnableLinkedConnections pose a security risk?

Question

As shown Microsoft's TechNet, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token. Here's the gist of it:

Symptom

After you turn on User Account Control (UAC) in Windows Vista or Windows 7, programs may not be able to access some network locations. This problem may also occur when you use the command prompt to access a network location.

Cause

This problem occurs because UAC treats members of the Administrators group as standard users. Therefore, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token.

[...]When network shares are mapped, they are linked to the current logon session for the current process access token. This means that if a user uses the command prompt (cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token.

Resolution

Creating/setting the DWORD value of EnableLinkedConnections at the location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 1 and restarting the computer enables Windows Vista and Windows 7 to share network connections between the filtered access token and the full administrator access token.

I've already established that the workaround mentioned above works perfectly fine, fixing my problem. Now I'm wondering if doing so poses a security risk and, if so, what it is? I can live without this workaround but having it in place definitely makes my life easier.

Answer 1

I found an answer from Jon Schwartz, UAC Architect, which provided the following details:

Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user). This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping.

As for any vulnerabilities, Jon had this to say:

Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.

This is from 2007 and mostly applies to Windows Vista, though. I don't think much has changed since then. Since we are still using Windows 7, I should be fine, I guess.

Answer 2

Even after the changes you made to that registry key, UAC is supposed to notify you of any further changes that may occur on your machine. So theoretically, this helps you to prevent malware installation, but there are few scenarii you may think about:

1. Suppose you give access to a person you trust (let's say your brother but who's not that well informed as you about security issues) to that machine and he installs/runs a compromised application (malicious music file, PC game ...your brother will tend naturally to click Yes, Ok and type your password): the malware will then run with full administrator privileges.
2. Suppose your brothers surfs under your account the web and lands on a compromised server that will perform a drive-by download attack: that can lead to installing spyware/adware on your computer thanks to the vulnerabilities that may exist on your browser or the plugins you run on it, or even, in further steps, lead to malware installation without your consent/knowledge.
3. UAC is not that powerful: it helps but it is not perfectly secure. Attackers use lot of techniques to bypass UAC (such as exploiting DLL hijacking vulnerability): suppose yourself running an application that bypasses UAC: with the settings you did, the malware will have full privileges (may be you are interested for example to read this: Zero-Day Bypasses Windows UAC)

As a good safety practice, it is better to leave the administrators group management to its default to have only one conscious - about security- and skilled administrator at a time.