it-swarm-es.com

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

¿Cuáles son algunas formas de mitigar los problemas de tiempo de verificación a tiempo de uso que se aplican a los permisos de Windows?

Ejemplo:

  1. El usuario final se agrega al grupo de administradores locales para instalar software, impresoras, etc.
  2. La cuenta del usuario se elimina del grupo de administradores mientras el usuario está conectado.
    • El cambio en los permisos no se aplicará hasta el próximo inicio de sesión del usuario.
  3. El usuario, con los derechos de administrador aún aplicados, se agrega de nuevo al grupo de administradores antes de cerrar la sesión, revertiendo la eliminación.
  4. La próxima vez que el usuario inicie sesión, seguirá teniendo permisos de administrador hasta que se eliminen (y permanezcan) de nuevo.

Aparte de solo no otorgar derechos de administrador a los usuarios finales en primer lugar (solución obvia), o por cualquier otro medio que requiera acciones específicas del usuario final, ¿cuáles son algunas de las formas en que se muestra el escenario anterior (o similar Problemas de TOCTTOU inherentes a Windows) se pueden prevenir?

9
Iszi

Repare Windows (o sus propias aplicaciones, cuando corresponda; en su ejemplo, necesitaría reparar Windows). La vulnerabilidad TOCTOU solo se puede abordar sin 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 lo busca no significa que no exista cuando vaya a usarlo.

Específicamente para este ejemplo: los servicios de autorización de Mac OS X no verifican 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 usarlo, por lo que la ventana para una vulnerabilidad 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ó conseguir un trabajo en Microsoft y se le asignó la tarea de corregir este error. Encuentra (estoy inventando la API con fines de argumento, pero así es como funcionaría) que cuando un usuario inicia sesión, el administrador de sesiones hace securityContext = GetUserAccountControlsContext(); que copia los derechos del usuario de la base de datos central o servicio de directorio para que la sesión pueda consultarlo.

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

La solución es eliminar la adquisición inicial del contexto. Cambie las pruebas de IsUserAuthorizedForAction(action, context) para llamar a GetUserAccountControlsContext() a sí mismas. El resultado debe no almacenarse en caché, pero debe buscarse de nuevo en cada llamada. Esto deja dos problemas pendientes:

  1. Cuando se realiza la verificación de habilitación de la interfaz de usuario, el usuario no está autorizado, pero lo estará en algún momento posterior. Puede solucionar este problema observando los cambios en el contexto de seguridad, o aceptarlo como una pequeña molestia que se producirá con poca frecuencia.
  2. Cuando se realiza la verificación de habilitación de la interfaz de usuario, el usuario está autorizado, pero cuando 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 suficientes privilegios para hacer lo que necesita.
4
user185

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 concede privilegios administrativos a un usuario, ya está, no volverá a conseguirlos.
Como usted dice, el usuario puede volver a agregarse a sí mismo al grupo de Administradores ... Pero en realidad hay muchas, muchas otras formas en las que puede asegurarse de mantener sus privilegios, mientras todavía tiene los que sería difícil eliminarlo, incluso si tenía 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 Administrador y habilítela. (Como no lo usas, ¿verdad?, nunca lo sabrías ...)
O cree otro grupo, hágalo oculto y agréguelo como miembro de Administradores.
O simplemente configure algún servicio de Windows, o MSTask, etc., ejecutándose como LOCALSYSTEM.
O instale algún tipo de rootkit.

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

Podría continuar, pero espero haber 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 ( Problema realmente difícil) en general.

Como dijiste, no concedas privilegios de administrador a los usuarios finales. Hay otras soluciones que les permiten instalar programas.

4
AviD

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, existen formas mucho mejores de permitir que un usuario instale una aplicación. En Server 2003 y Windows XP, puede utilizar la política de instalación de software de directiva de grupo, que permite a un usuario instalar software de una lista blanca.

0
surfasb