Come mitigare le vulnerabilità di TOCTTOU all'interno del sistema operativo Windows?

Correggi Windows (o le tue applicazioni, dove applicabile) nel tuo esempio avresti bisogno di riparare Windows). La vulnerabilità TOCTOU può essere risolta solo non separando il controllo dall'utilizzo. Un esempio molto più comune nelle applicazioni che ho visto: file temporanei (sì, la gente continua a sbagliare). Solo perché un file non esiste quando guardi non significa che non esisterà quando lo userai.

Specifico per questo esempio: i servizi di autorizzazione di Mac OS X non controllano i privilegi che hai quando accedi. Scoprono se puoi acquisire un giusto al momento dell'acquisizione . In un'applicazione ben progettata, il componente privilegiato esamina se si ha il diritto all'utilizzo , quindi la finestra per una vulnerabilità TOCTOU è limitata. Non è zero: potrei acquisire un diritto, farlo revocare correttamente, quindi passare il contesto di sicurezza che ho già acquisito nel componente privilegiato, ma c'è un limite di tempo.

Quindi, diciamo che sei riuscito a farti un lavoro in Microsoft, e che sei stato incaricato di correggere questo bug. Si scopre (sto preparando l'API per scopi di discussione, ma è così che funzionerebbe) che quando un utente accede, il gestore della sessione fa securityContext = GetUserAccountControlsContext(); che copia i diritti dell'utente dal database centrale o dal servizio directory in modo tale la sessione può riferirsi ad essa.

Successivamente, si scopre che il codice per la gestione dei diritti utente chiama IsUserAuthorizedForAction(kMakeUserAdminAction, securityContext); per scoprire se l'interfaccia utente per farsi l'amministratore deve essere abilitata. Quando fa clic sul pulsante, MakeUserAdmin(user) anche chiama lo stesso controllo, con lo stesso contesto di sicurezza.

La correzione è di rimuovere l'acquisizione iniziale del contesto. Cambia i test per IsUserAuthorizedForAction(action, context) per chiamare GetUserAccountControlsContext() . Il risultato dovrebbe non essere memorizzato nella cache, ma dovrebbe essere ricercato di nuovo ad ogni chiamata. Questo lascia due problemi in sospeso:

1. Al termine del controllo di attivazione dell'interfaccia utente, l'utente non è autorizzato, ma lo diventa in un secondo momento. Puoi risolvere questo problema osservando le modifiche al contesto di sicurezza o accettandolo come un leggero fastidio che si verificherà di rado.
2. Al termine del controllo di attivazione dell'interfaccia utente, l'utente è autorizzato, ma quando fa clic sul pulsante non è autorizzato. Questo è gestito dal fatto che MakeUserAdmin() verifica il contesto di sicurezza (aggiornato). Dovrebbe generare un'eccezione se non può effettivamente ottenere privilegi sufficienti per fare ciò di cui ha bisogno.

Senza rispondere effettivamente alla domanda dichiarata, voglio affrontare il tuo esempio dato - perché penso che in realtà stai solo cercando di risolvere quel problema, e non il problema generico.

Una volta concessi i privilegi di amministratore a un utente, con cui è stato fatto, non li ritroverete mai più.
Come dici tu, l'utente può semplicemente aggiungersi al gruppo degli amministratori ... Ma ci sono molti, molti altri modi in cui può fare in modo che mantenga i suoi privilegi, mentre ha ancora il privilegio, così che tu possa essere duro premuto per rimuoverlo, anche se si è verificato il completo e completo controllo del sistema attivato.

Ad esempio, può creare un altro utente e aggiungerlo agli amministratori.
O reimpostare la password su Administrator e abilitarla. (Dal momento che non lo usi, giusto ?? , non lo sapresti mai ...)
Oppure crea un altro gruppo, rendilo nascosto e aggiungilo come membro degli amministratori.
Oppure, è sufficiente configurare alcuni servizi di Windows, o MSTask ecc., In esecuzione come LOCALSYSTEM.
O installa qualche sorta di rootkit.

Ovviamente il sistema di auditing non sarà di grande aiuto, dal momento che e Admin può facilmente spegnerlo, temporaneamente ...

Potrei andare avanti, ma spero di aver già dimostrato il mio punto ... TOC-TOU è non il tuo problema qui, sta concedendo privilegi amministrativi temporanei (non proprio possibili), o forse trattando con amministratori malintenzionati (Really Hard Problem) in generale.

Come hai detto, non concedere i privilegi di amministratore agli utenti finali. Esistono altre soluzioni che consentono loro di installare programmi.

Questa è una di quelle situazioni in cui il metodo è intrinsecamente insicuro, poiché non segue un modello di privilegi minimi.

Per quanto riguarda Windows, ci sono molti modi migliori per consentire a un utente di installare un'applicazione. In Server 2003 e Windows XP, è possibile utilizzare il criterio Installa software criteri di gruppo, che consente a un utente di installare il software da una whitelist.