¿Cómo se pueden mitigar las vulnerabilidades de TOCTTOU dentro del sistema operativo Windows?

Corrija Windows (o sus propias aplicaciones, donde corresponda, en su ejemplo, tendría que arreglar Windows). La vulnerabilidad de TOCTOU solo se puede solucionar al no separar la verificación del uso. Un ejemplo mucho más común en las aplicaciones que he visto: archivos temporales (sí, la gente todavía se equivoca). El hecho de que un archivo no exista cuando se mire no significa que no existirá cuando vaya a usarlo.

Específico a este ejemplo: los servicios de autorización de Mac OS X no comprueban qué privilegios tiene cuando inicia sesión. Averigua si puede adquirir un derecho en el momento de la adquisición . En una aplicación bien diseñada, el componente privilegiado examina si tiene el derecho al usar , por lo que la ventana para una vulnerabilidad de TOCTOU es limitada. No es cero: podría adquirir un derecho, revocar ese derecho y luego pasar el contexto de seguridad que ya obtuve al componente privilegiado, pero hay un límite de tiempo para eso.

Entonces, digamos que logró obtener un trabajo en Microsoft, y le encargaron solucionar este error. Usted encuentra (estoy inventando la API para fines de argumento, pero así es como funcionaría) que cuando un usuario inicia sesión, el administrador de sesión hace securityContext = GetUserAccountControlsContext(); , que copia los derechos del usuario desde la base de datos central o el servicio de directorio. la sesión puede referirse a ella.

Más adelante, encontrará que el código para administrar los derechos de usuario llama a IsUserAuthorizedForAction(kMakeUserAdminAction, securityContext); para descubrir si la IU para hacerse administrador debe estar habilitada. Cuando hace clic en el botón, MakeUserAdmin(user) también llama a la misma comprobación, con el mismo contexto de seguridad.

La solución es eliminar la adquisición inicial del contexto. Cambie las pruebas para IsUserAuthorizedForAction(action, context) para llamar a GetUserAccountControlsContext() a ellos mismos. El resultado debe no ser almacenado en caché, pero debe consultarse nuevamente en cada llamada. Esto deja dos problemas pendientes:

1. Cuando se realiza la verificación de habilitación de UI, el usuario no está autorizado, pero lo hace más adelante. Puede solucionar este problema observando los cambios en el contexto de seguridad, o aceptarlo como una pequeña molestia que ocurrirá con poca frecuencia.
2. Cuando se realiza la verificación de habilitación de UI, el usuario está autorizado, pero en el momento en que hace clic en el botón no está autorizado. Esto se maneja por el hecho de que MakeUserAdmin() prueba el contexto de seguridad (actualizado). Debería lanzar una excepción si no puede obtener privilegios suficientes para hacer lo que necesita.

Sin responder realmente a la pregunta declarada, quiero abordar su ejemplo dado, porque creo que en realidad solo está tratando de resolver ese problema, y no el problema genérico.

Una vez que le otorga privilegios administrativos a un usuario, ya no está listo para volver a liberarlos. Como usted dice, el usuario solo puede volver a agregarse al grupo de Administradores ... Pero en realidad hay muchas, muchas otras formas en que puede hacerlo para asegurarse de que mantiene sus privilegios, mientras que todavía tiene el privilegio, por lo que sería difícil presione para eliminarlo, incluso si tiene activada la auditoría completa y completa del sistema.

Por ejemplo, puede crear otro usuario y agregarlo a los administradores.
O restablezca la contraseña en el Administrador y habilítela. (Ya que no lo usas, ¿verdad? , nunca lo sabrías ...)
O cree otro grupo, ocúltelo y agréguelo como miembro de Administradores.
O, simplemente configure algún Servicio de Windows, o MSTask, etc., ejecutando como LOCALSYSTEM.
O instalar un poco de rootkit.

Por supuesto, la auditoría del sistema realmente no ayudará, ya que el Administrador puede apagarlo fácilmente, temporalmente ...

Podría continuar, pero espero que ya haya demostrado mi punto ... TOC-TOU es no su problema aquí, es otorgar privilegios administrativos temporales (no es realmente posible), o tal vez tratar con Administradores maliciosos (Really Hard Problem) en general.

Como ha dicho, no otorgue privilegios de administrador a los usuarios finales. Hay otras soluciones para permitirles instalar programas.

Esta es una de esas situaciones en las que el método es intrínsecamente inseguro, ya que no sigue un modelo de privilegios mínimos.

En lo que respecta a Windows, hay formas mucho mejores de permitir que un usuario instale una aplicación. Bajo Server 2003 y Windows XP, puede usar la política de instalación de software de directiva de grupo, que le permite a un usuario instalar software de una lista blanca.