OneWindows
Google, a través de su Project Zero, ha revelado un agujero de seguridad de nivel moderado en Windows 10 S. Según lo explica en una publicación (con terminología bastante técnica), el equipo de seguridad encontró una vulnerabilidad que permite ejecutar código arbitrario en un dispositivo con Windows 10 S que posea UMCI (Integridad de código de modo usuario) activado, es decir, Device Guard funcionando.
Esta vulnerabilidad no se puede aprovechar remotamente, por lo que el atacante debe tener acceso físico al dispositivo y ejecutar el código para crear daño. Google explica que el problema no es grave si se han corregido las vulnerabilidades explotadas utilizando métodos de derivación, como la ejecución remota de código (RCE) en Edge.
La política de bloqueo de la clase COM de WLDP contiene una lista de 8 a 50 objetos codificados que permiten a los motores de secuencias de comandos puedan crear instancias. Esto 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, 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. Esto tiene un impacto directo en la política de clase, 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 .NET tiene ese GUID específico, puede usarlo para iniciar la ejecución de código arbitrario al abusar de algo como DotNetToJScript.
Google habría reportado el error a Microsoft el 19 de enero, pero la compañía no pudo solucionarlo antes del martes de parches del mes de abril. Redmond solicitó una extensión de 14 días para solventarlo, pero informó a Google que se implementará una solución para la acumulativa de mayo. Dado que este plazo también superó la fecha límite de gracia que utiliza el Project Zero (90 días), Google rechazó la solicitud de Microsoft y no otorgó los 14 días adicionales.
Posteriormente, Google avisó a Microsoft que el problema no es serio y que todavía hay otros métodos que la compañía aún no ha solucionado. La semana pasada, Redmond una vez más solicitó una extensión en la fecha límite alegando que se resolvería en la actualización de Redstone 4 (RS4), pero Google la rechazó diciendo que «no hay una fecha firme para la actualización, y que RS4 no se consideraría una parche ampliamente disponible de todos modos.»
