Non avendo accesso sorgente a Windows è difficile dire qualcosa che non sia speculazione. Quel disclaimer a parte, ecco cosa sono stato in grado di raccogliere leggendo su questo:
Controllo dell'account utente crea due token di sicurezza all'accesso: il token elevato contenente le appartenenze al gruppo completo dell'utente e il token limitato che ha l'appartenenza al gruppo "Amministratori" eliminato. Ogni token contiene un ID univoco localmente distinto (LUID) che identifica la sessione di accesso. Sono due sessioni di accesso separate e distinte.
A partire da Windows 2000 Server SP2, le unità mappate (che sono rappresentate come collegamenti simbolici nello spazio dei nomi del gestore oggetti) sono taggate con il LUID del token che le ha create (puoi trovare alcuni riferimenti Microsoft a questo comportamento in questo articolo di KBase e puoi scopri di più sulla meccanica della funzione in questo post sul blog ). L'essenza della funzionalità è che le unità mappate create da una sessione di accesso non sono accessibili a un'altra sessione di accesso.
Impostazione di EnableLinkedConnections valore attiva un comportamento nel servizio LanmanWorkstation e nel sottosistema di sicurezza LSA (LSASS.EXE) per indurre LSA a copiare le unità mappate da uno dei token degli utenti nel contesto dell'altro token. Ciò consente alle unità mappate con il token elevato di essere visibili al token limitato e al contrario. Non vi è alcuna peculiarità del comportamento di questa funzionalità rispetto al dominio rispetto a un ambiente non di dominio. Se i tuoi utenti sono in esecuzione con account "Amministratore" in un ambiente non di dominio, i loro token con restrizioni e token elevati, per impostazione predefinita, avranno mappature di unità indipendenti.
In termini di vulnerabilità, la documentazione ufficiale di Microsoft sembra mancare. Ho trovato un commento e una risposta di un dipendente Microsoft che mi chiedeva delle potenziali vulnerabilità in una conversazione sull'UAC del 2007. Dato che la risposta arriva da Jon Schwartz, che all'epoca era intitolato "UAC Architect", avrei tendono a considerare credibile la sua risposta. Ecco l'essenza della sua risposta alla seguente inchiesta: "... Non ho trovato alcuna informazione per descrivere ciò che sta realmente accadendo tecnicamente o se questo apre qualche tipo di scappatoia UAC. Puoi commentare?"
Tecnicamente, apre una piccola lacuna poiché il malware non elevato può ora "pre-seeding" una lettera di unità + mappatura nel contesto elevato - che dovrebbe essere a basso rischio a meno che non si finisca con qualcosa che è specificamente su misura per il proprio ambiente.
Personalmente, non riesco a pensare a un modo per "sfruttare" questa scappatoia, nella misura in cui "seeding" del token elevato con una mappatura di unità richiederebbe comunque all'utente di elevare ed eseguire effettivamente qualcosa di dannoso da quella mappatura di unità "seminata". Non sono un ricercatore di sicurezza, tuttavia, e forse non mi sto avvicinando a questo con una buona mentalità per inventare potenziali exploit.
Ho evitato di utilizzare il valore EnableLinkedConnections nei siti dei miei clienti continuando la tendenza che abbiamo iniziato quando i clienti hanno iniziato a distribuire Windows NT 4.0, consentendo agli utenti di accedere con account utente limitati. Per anni ha funzionato bene e continua a funzionare bene in Windows 7.