Fig. 1. Contusionada, pero no rota. La calculadora de Windows, cuyo código se publicó recientemente en Github , resultó ser una de las dos aplicaciones probadas que no se bloquearon y no se opusieron al difusor de mensajes de ventana desarrollado en 2000. Tamaño de ventana especialmente ampliado para mostrar artefactos difusos

Es hora de que la segunda parte de nuestros esfuerzos pruebe técnicas antiguas de fuzzing en sistemas modernos. Si te perdiste, aquí está la primera parte . Esta vez, probaremos las técnicas de fuzzing de Windows 10 del artículo "Investigación empírica de la confiabilidad de las aplicaciones de Windows NT que usan pruebas aleatorias" (también conocido como "NT Fuzzing Report") de Justin Forrester y Barton Miller, publicado en 2000.

Los investigadores probaron 33 aplicaciones de Windows NT y una versión anterior de Windows 2000 para determinar la susceptibilidad a mensajes de ventana distorsionados y eventos aleatorios de mouse y teclado. Desde que el Dr. Miller publicó el código de fuzzer, utilizamos exactamente las mismas herramientas que los autores originales para buscar errores en las aplicaciones modernas de Windows.

Los resultados son casi idénticos: hace 19 años, el 100% de las aplicaciones probadas se bloquearon o se bloquearon cuando encontraron mensajes de ventana distorsionados. Hoy, el mismo fuzzer dejó caer o colgó el 93% de las aplicaciones probadas. Solo dos se pusieron de pie, incluido nuestro viejo amigo Calculadora (Fig. 1). También encontramos un error (pero no un problema de seguridad) en Windows.

Una breve introducción a Windows

Entonces, ¿qué son los mensajes de ventana y por qué hacen que un programa se bloquee?

Las aplicaciones de la GUI de Windows están controladas por eventos: movimientos del mouse, pulsaciones de botones, pulsaciones de teclas, etc. Una aplicación controlada por eventos no hará nada hasta que reciba un evento. Una vez que se recibe un evento, la aplicación realiza la acción en función del evento y luego espera otros eventos. ¿Te suena familiar? Esta arquitectura ha recibido una segunda vida en plataformas como node.js.

Los mensajes de ventana son un método de notificación de eventos de Windows . Cada uno de ellos tiene un código numérico asociado con un evento específico . Cada mensaje tiene uno o más parámetros, que por convención se llaman lParam y wParam . Definen información más detallada sobre el evento. Ejemplos de dicha información son las coordenadas del movimiento del mouse, qué tecla se presiona o qué texto mostrar en la ventana. Estos mensajes pueden ser enviados por el propio programa, el sistema operativo u otros programas. Pueden llegar en cualquier momento y en cualquier orden y deben ser procesados ​​por la aplicación en el lado receptor.

Implicaciones de seguridad

Antes de Windows Vista, un proceso de bajos privilegios podría enviar un mensaje a un proceso de altos privilegios. Usando la combinación correcta de mensajes, puede ejecutar código en ese proceso. En Vista, estos "ataques subversivos" estaban en gran medida protegidos por UIPI y al aislar los servicios del sistema en una sesión separada.

Es improbable que el procesamiento incorrecto de los mensajes de la ventana afecte la seguridad de los sistemas Windows modernos por dos razones. Primero, los mensajes de ventana no se pueden enviar a través de la red. En segundo lugar, bloquear una aplicación o ejecutar código en el mismo nivel de privilegio no es muy útil para un atacante. Probablemente, era obvio para los autores del informe fuzz NT. No hacen declaraciones de seguridad, pero señalan correctamente que las fallas en el procesamiento de los mensajes de la ventana implican una falta de pruebas rigurosas.

Hay algunas áreas donde la ejecución de código con los mismos privilegios puede comprometer la seguridad. Algunas aplicaciones combinan varias primitivas de seguridad para crear un nivel de privilegio artificial que no se encontró originalmente en el sistema operativo. Un ejemplo típico es un sandbox para renderizar en un navegador. Los fabricantes de navegadores son conscientes de estos problemas y han tomado medidas para abordarlos . Otro ejemplo son los productos antivirus. Allí, el panel de control funciona con privilegios normales, pero está aislado de otros módulos antivirus.

Metodología de prueba

Para difuminar todas las aplicaciones en el conjunto de pruebas, utilizamos el mismo código central y la misma técnica de difuminación descrita en el informe inicial de NT. En particular, en los modos SendMessage y PostMessage , fazzer utilizó tres iteraciones de 500,000 mensajes con 42 semillas y tres iteraciones de 500,000 mensajes con 1,337 semillas. Los resultados aparecieron después de realizar solo una iteración de cada método.

Perdimos la entrada aleatoria del mouse y el teclado debido a limitaciones de tiempo y al deseo de centrarnos únicamente en los mensajes de la ventana. También alentamos a aquellos que desean repetir las pruebas y confirmar los resultados.

Trampas

Para fuzzer en Windows 10 tuvo que hacer dos cambios menores. Primero, adáptelo para una plataforma de 64 bits. El segundo cambio permitió al fuzzer seleccionar un identificador de ventana específico utilizando el argumento de la línea de comando. Difuminar un descriptor específico es una solución rápida a la difuminación de las aplicaciones de la Plataforma universal de Windows (UWP) . El programa original se centra en las ventanas difusas que pertenecen a un determinado proceso, pero todas las aplicaciones UWP muestran su interfaz de usuario a través del mismo proceso (Fig. 2). Esto significa que el fuzzer no se puede dirigir a la ventana principal de la aplicación UWP.


Fig. 2. En la plataforma UWP, todas las aplicaciones pertenecen a un proceso ( ApplicationFrameHost.exe ). Para difuminar estas aplicaciones, tuve que cambiar el fuzzer NT original y dirigirlo a identificadores de ventana específicos

Hubo una falla grave en la modificación del fuzzer: los valores elegidos para las dos fuentes principales de entrada aleatoria, los argumentos lParam y wParam para SendMessage y PostMessage , están limitados a enteros de 16 bits. Ambos argumentos son de 32 bits en Windows de 32 bits y 64 bits en Windows de 64 bits. El problema ocurre en Fuzz.cpp , donde wParam lParam y wParam :

  wParam = (UINT) rand(); lParam = (LONG) rand(); 

La función rand () devuelve un número en el rango [0, 2 ¹⁶ ], que limita en gran medida el conjunto de valores probados. Guardamos este error intencionalmente durante las pruebas para que los resultados coincidan con precisión con el trabajo original.

Aplicaciones probadas

En el informe original de NT, se probaron 33 programas. Solo tenemos 28, porque solo se usa una versión de cada programa para las pruebas. El ecosistema de software de Windows ha cambiado significativamente desde 2000, aunque sorprendentemente, muchas cosas permanecen sin cambios. El conjunto de aplicaciones de Microsoft Office contiene los mismos programas que en las pruebas originales. Netscape Communicator se ha convertido en Firefox. Adobe Acrobat ha cambiado su nombre a Adobe Reader, pero sigue siendo válido. Incluso Winamp lanzó un nuevo lanzamiento en 2018, que permite una comparación justa con el informe original. Sin embargo, algunos programas obsoletos tuvieron que ser reemplazados. Vea a continuación una lista de cambios y razones para ellos:

• Reproductor de CD Player Windows Media Player: la funcionalidad del reproductor de CD se incluye en el nuevo programa.
  
• Eudora ⇨ Windows Mail: Qualcomm ahora se ocupa de chips en lugar de clientes de correo electrónico. Como Eudora ya no existe, se ha probado el cliente de correo predeterminado de Windows.
  
• Command AntiVirus ⇨ Avast Free Edition: Command AntiVirus ya no está disponible. Ha sido reemplazado por Avast como el antivirus de terceros más popular.
  
• GSView ⇨ Fotos: GSView ya no es compatible. Fue reemplazado con el visor de fotos predeterminado de Windows.
  
• JavaWorkshop Net NetBeans IDE: JavaWorkshop IDE ya no es compatible. NetBeans parece una buena alternativa gratuita que coincide con el espíritu de lo que debe verificarse.
  
• CRT seguro ⇨ BitVise SSH: CRT seguro todavía existe, pero se requiere un formulario web muy largo para descargar la versión de prueba. BitVise SSH ofreció un arranque rápido.
  
• Telnet ⇨ Putty: la aplicación telnet todavía existe en Windows, pero ahora es una aplicación de consola. Para difuminar la GUI, la reemplazamos con Putty, el popular emulador de terminal de código abierto para Windows.
  
• Encontramos Freecell y Solitaire en la Colección de Solitarios de Microsoft del catálogo de aplicaciones de la Tienda de Aplicaciones de Windows.

La versión específica de la aplicación se muestra en la tabla de resultados. Todo el fuzzing se llevó a cabo en un sistema de 64 bits Windows 10 Pro versión 1809 (compilación 17763.253).

Resultados

Como se mencionó en el informe original, los resultados no deben verse como vulnerabilidades de seguridad, sino como un indicador de la confiabilidad y calidad del software.

"Finalmente, nuestros resultados forman un punto de partida cuantitativo desde el cual juzgar la mejora relativa en la confiabilidad del software".

- Del "Estudio empírico de la confiabilidad de aplicaciones de Windows NT mediante pruebas aleatorias" por Justin Forrester y Barton Miller

Los números no son particularmente alentadores, aunque la situación está mejorando. En el informe inicial de NT, todas las aplicaciones se bloquearon o se bloquearon en fuzzing. Ahora dos programas: la calculadora y Avast Antivirus, sobrevivieron a la eliminación gradual de los mensajes de la ventana sin consecuencias negativas. Elogiamos a los equipos de Avast y Windows Calculator por su enfoque a los mensajes de ventana erróneos. El equipo de Calculator se ha ganado un respeto adicional por abrir el código fuente y demostrar cómo crear una aplicación UWP de alta calidad. Consulte la tabla 1 para ver todos los resultados difusos, junto con la versión específica del software utilizado.

Tabla 1. Resultados de reproducir el fuzzing original en Windows 10. Después de 19 años, casi todas las aplicaciones aún no manejan correctamente los mensajes de ventana distorsionados

Error de Windows?

Desafortunadamente, prevaleció la curiosidad y tuvimos que hacer una excepción. Parecía que varias aplicaciones no relacionadas se vieron afectadas por un problema común. La depuración mostró que el problema está relacionado con el mensaje WM_DEVICECHANGE . Cuando el fuzzer envió este mensaje, incluso la aplicación más simple cayó: HelloWorld, el ejemplo oficial de la API de Windows (Fig. 3).


Fig. 3. HelloWorld.exe de 32 bits se bloquea al recibir un mensaje de ventana de fuzzer. Esto no debería suceder, ya que el programa es completamente simple. Se entiende que el problema está en algún lugar de Windows

Después de la caída de HelloWorld, nos dimos cuenta de inmediato de que el problema afecta solo a las aplicaciones de 32 bits, pero no a las de 64 bits. Algunas depuraciones rápidas mostraron que el bloqueo se produce en wow64win.dll, una capa de compatibilidad de aplicaciones de 32 bits para 64 bits . Mi análisis superficial (y posiblemente incorrecto) del problema lleva a la conclusión de que la función wow64win.dll!whcbfnINDEVICECHANGE considera a wParam como un puntero a la estructura DEV_BROADCAST_HANDLE64 en el programa de destino. La función convierte esta estructura a la estructura DEV_BROADCAST_HANDLE32 para compatibilidad con aplicaciones de 32 bits. La falla ocurre porque el valor de wParam generado por el fuzzer indica memoria no válida.

Tratar a wParam como un puntero local es una mala idea, aunque probablemente fue una decisión de diseño deliberada para que las notificaciones de dispositivos extraíbles funcionen con aplicaciones heredadas de Windows de 32 bits. Pero todavía está mal que pueda bloquear otra aplicación sin ningún problema. Reportamos el problema a MSRC, aunque el límite de seguridad no se cruzó. Confirmaron que el error no era un problema de seguridad. Esperamos ver una solución para este extraño problema generalmente aceptado en una versión futura de Windows.

Conclusión

Los mensajes de Windows se subestiman y, a menudo, se ignoran como entradas poco confiables para los programas de Windows. Incluso 19 años después de que apareciera el primer difusor de mensajes de ventana de código abierto, el 93% de las aplicaciones probadas todavía se congelan o bloquean cuando se inicia el mismo programa. Pero es alentador que algunas aplicaciones hagan frente con gracia a esta entrada distorsionada: esto significa que algunas organizaciones tienen marcos y conocimiento institucional para evitar tales errores.

Por supuesto, el fuzzer se puede mejorar de muchas maneras, pero incluso el método más simple bloqueó el 93% de las aplicaciones. Quizás, en algunos casos, los mensajes de ventana incluso cruzan la frontera de seguridad real. Si explora esta área, esperamos que comparta los hallazgos.