Una falla de seguridad acaba de ser encontrada en Windows 10S. Los detalles han sido revelados por el Proyecto Zero de Google. Esto luego de que Microsoft no emitiera un parche dentro del plazo de revelación de 90 días.
La vulnerabilidad es conocida como «WLDP CLSID policy .NET COM Instantiation UMCI Bypass». La misma se describe como de gravedad media. Y permite la ejecución de código arbitrario en sistemas con Device Guard habilitado.
El hecho de que el problema afecte a Windows 10 S es algo embarazoso para Microsoft. Sobre todo considerando que esta versión particular de su sistema operativo se presenta al público como «optimizada para seguridad y rendimiento superior».
En un principio, se informó a Microsoft del fallo de seguridad en enero de este año. Seguidamente fue se indicó que el mismo no se arreglaría (o no se podía arreglar). Luego, el Martes de Parche del mes de abril, Microsoft solicitó una extensión de 14 días, pero esto fue denegado.
La empresa solicitó una vez más una extensión y señaló que Redstone 4 solucionará el problema. No obstante, Project Zero señaló que esto «no se consideraría un parche ampliamente disponible según las condiciones de divulgación». Y de ahí la divulgación del problema de seguridad.
La falla de seguridad en Windows 10S según Project Zero
La entrada Project Zero para la falla de seguridad explica el problema de la siguiente manera: “La política de bloqueo de la clase COM de WLDP contiene una lista de 8 a 50 objetos codificados que los motores de secuencias de comandos pueden crear instancias. Excluir los problemas relacionados con la búsqueda del CLSID correcto (como el abuso de TreatAs presentado anteriormente caso 40189)”.
Project Zero sigue explicando que lo anterior no debería ser un problema importante. Incluso si puede escribir en el registro para registrar una DLL existente bajo uno de los CLSID COM permitidos. Esto ya que una implementación COM bien comportada debe comparar el CLSID pasado a DllGetObject con su lista interna de objetos conocidos.
Resulta que .NET no es una de estas implementaciones COM de buen comportamiento. Cuando se crea una instancia de un objeto COM .NET, el CLSID pasado a DllGetClassObject de mscoree solo se usa para buscar la información de registro en HKCR. En este punto, al menos en función de las pruebas, el CLSID se descarta y se crea el objeto .NET.
Más sobre el fallo de seguridad
Las informaciones suministradas por ProjectZero indican que el fallo de seguridad tiene un impacto directo en la política de clase. Esto ya que permite a un atacante agregar claves de registro (incluso a HKCU) que cargarían una clase visible de COM arbitraria bajo uno de los CLSID permitidos. Como a .NET no le importa si el tipo de .NET tiene ese GUID específico, puede usarlo para iniciar la ejecución de código arbitrario al abusar de algo como DotNetToJScript.
Una prueba de concepto está disponible, pero existen factores atenuantes. Así lo explica, un usuario llamado Forshaw: «No es un problema que pueda explotarse de forma remota, ni es una escalada de privilegios. Un atacante tendría que tener un código ejecutándose en la máquina para instalar las entradas de registro necesarias para explotar este problema. Aunque esto podría ser a través de un RCE como una vulnerabilidad en Edge».