Não tendo acesso ao Windows, é difícil dizer qualquer coisa que não seja especulação. Esse aviso de lado, eis o que consegui ler lendo isto:
O UAC cria dois tokens de segurança no logon: o token elevado que contém as associações de grupo completas do usuário, e o token restrito que tem a participação do grupo" Administradores "removida. Cada token contém um ID exclusivo local exclusivo (LUID) que identifica a sessão de logon. São duas sessões de logon separadas e distintas.
A partir do Windows 2000 Server SP2, as unidades mapeadas (que são representadas como links simbólicos no namespace do gerenciador de objetos) são marcadas com o LUID do token que as criou (você pode encontrar algumas referências da Microsoft a esse comportamento neste artigo do KBase , e você pode aprender mais sobre a mecânica do recurso nesta postagem de blog ). A essência do recurso é que as unidades mapeadas criadas por uma sessão de logon não estão acessíveis para outra sessão de logon.
A configuração do valor EnableLinkedConnections aciona um comportamento no serviço LanmanWorkstation e no subsistema de segurança LSA (LSASS.EXE) para fazer com que o LSA copie unidades mapeadas por um dos tokens dos usuários no contexto do outro token. Isso permite que as unidades mapeadas com o token elevado fiquem visíveis para o token restrito e para o inverso. Não há qualquer peculiaridade do comportamento desse recurso com relação a um ambiente de domínio versus ambiente não-domínio. Se os usuários estiverem executando com contas de "Administrador" em um ambiente sem domínio, seus tokens restritos e tokens elevados terão, por padrão, mapeamentos de unidade independentes.
Em termos de vulnerabilidade, a documentação oficial da Microsoft parece estar faltando. Eu encontrei um comentário e uma resposta de um funcionário da Microsoft perguntando sobre as potenciais vulnerabilidades em uma conversa sobre o UAC a partir de 2007. Dado que o resposta vem de Jon Schwartz, que, na época, foi intitulado "UAC Architect", eu tendem a considerar sua resposta com credibilidade. Aqui está a essência de sua resposta para a seguinte pergunta: "... eu não encontrei nenhuma informação para descrever o que está realmente acontecendo tecnicamente ou se isso abrir algum tipo de brecha no UAC. Você pode comentar?"
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.
Pessoalmente, não consigo pensar em uma maneira de "explorar" essa lacuna, na medida em que "semear" o token elevado com um mapeamento de unidade ainda exigiria que o usuário realmente elevasse e executasse algo malicioso dessa unidade "semeada" mapeamento. Eu não sou um pesquisador de segurança, no entanto, e talvez eu não esteja me aproximando disso com uma boa mentalidade para desenvolver explorações em potencial.
Desviei-me usando o valor EnableLinkedConnections em meus sites de clientes, continuando a tendência que começamos quando os clientes começaram a implantar o Windows NT 4.0 - fazendo com que os usuários fizessem logon com contas de usuário limitadas. Isso funciona bem para nós há anos e continua a funcionar bem no Windows 7.