Manipulación de datos

La manipulación de datos es una amenaza para los controladores, pero una amenaza grave para los controladores de filtro del sistema de archivos y del sistema de archivos. Para todos los controladores, existe una amenaza potencial de que cualquier estructura de control compartida entre los componentes de modo usuario y modo kernel pueda modificarse mediante el componente de modo de usuario mientras el componente del modo kernel la usa. El sistema de archivos y los controladores de filtro son especialmente vulnerables a esta clase de ataque porque tienen una fuerte dependencia de METHOD_NEITHER tipos de transferencia de datos que acceden directamente al búfer del usuario a través de su dirección virtual. E/S rápida también accede directamente a los búferes en modo de usuario sin formato. El riesgo aquí es que un controlador podría usar estos datos mientras la aplicación modifica los datos. Normalmente, un controlador intenta protegerse contra esto validando los datos. Sin embargo, la validación de datos solo funciona si los datos no pueden cambiar después de que se hayan validado.

En el caso de los controladores de filtro del sistema de archivos y del sistema de archivos, hay numerosas operaciones IOCTL y FSCTL que se usan para transferir información entre las aplicaciones en modo de usuario y los distintos controladores de modo kernel. Además, es bastante habitual que estos controladores tengan operaciones privadas IOCTL y FSCTL que también transfieran información de control y datos entre los servicios en modo de usuario y sus controladores en modo kernel.

Inherente a este modelo de diseño es una suposición de que solo el servicio o la aplicación del controlador aprovecharán su interfaz. Este tipo de diseño e implementación está en riesgo por los siguientes motivos:

• Una aplicación malintencionada podría enviar un búfer válido al controlador y, a continuación, modificar los datos en un intento de sondear y encontrar los puntos débiles del controlador.

• Los errores dentro de la aplicación de control podrían hacer que el contenido de los datos de un búfer de control no sea válido. Por ejemplo, una región de control basada en pila podría no ser válida si una excepción cambiara el flujo de control y provocara una reutilización de la región de pila.

La protección contra esta categoría de problemas requiere vigilancia constante en términos de la implementación. Los búferes deben encontrarse en memoria no volátil (solo kernel o memoria de solo lectura) antes de validarse. Si el búfer contiene referencias a otros búferes o estructuras de control, también deben encontrarse en memoria no volátil antes de que se validen.

Los desarrolladores también deben tener en cuenta que IOCTL mediante el envío fastIoDeviceControl pasará datos en búferes de usuario sin procesar. Por lo tanto, los controladores que implementan la versión rápida de E/S para ICTLs deben tomar los pasos adecuados para evitar problemas.

Tenga en cuenta que validar los datos por sí solo no es suficiente. Por ejemplo, una llamada correcta a ProbeForWrite podría indicar que un búfer es válido, pero los cambios posteriores en el espacio de direcciones de la aplicación podrían provocar que ese estado cambie. La aplicación podría finalizar, por ejemplo, antes de que el controlador realmente use el búfer directamente. Por lo tanto, el controlador debe protegerse frente a cualquier cambio dentro del espacio de direcciones de la aplicación. Normalmente, esto se hace mediante el control estructurado de excepciones mediante __try y __except en torno a cualquier código que acceda directamente a una dirección de búfer de usuario.