Vulnerabilidad de ASP.NET CVE-2008-5100 (bypass de firma de ensamblaje): ¿hay alguna solución?

Por lo que yo entiendo, este CVE es un error. El nombre seguro es básicamente una firma en la DLL, y la clave pública se identifica con la " token de clave pública ", que es un hash SHA-1 de la clave truncada a 64 bits . La funcionalidad principal del "nombre fuerte" es evitar choques cuando varios desarrolladores, que no se conocen entre sí, publican diferentes DLL con el mismo nombre.

También se supone que los nombres fuertes son compatibles con un marco de integridad de código: una aplicación dada hará referencia a una DLL por nombre, versión y token de clave pública; El archivo DLL coincidente se encontrará en Caché de ensamblados global . Un atacante malvado podría intentar cargar en la GAC una DLL maliciosa con el mismo nombre que una DLL genuina, esperando que otra aplicación (iniciada por otro usuario) cargue his DLL en lugar de la correcta. Para hacerlo, ya que la aplicación contiene el "token de clave pública", el atacante tendrá que firmar su DLL malvado con una clave que coincida con el token de clave pública, y que el token de clave pública sea hash criptográfico , no puede.

El CVE-2008-5100 trata principalmente de que alguien se da cuenta de que las firmas en DLL se verifican cuando se instala la DLL en el GAC, no cuando se carga desde el GAC. Esto tiene sentido: el GAC está protegido de alteraciones arbitrarias por el sistema operativo. Por lo tanto, si la DLL era buena en la entrada, sigue siendo buena después. O, más precisamente, para modificar una DLL que se ha instalado en el GAC, necesita amplios derechos administrativos que hacen que todo esto sea discutible: si tiene ese poder, entonces ya posee la máquina de todas las formas posibles. Esto explica el silencio ensordecedor de la Web sobre este CVE: no es un problema . Es como afirmar que una cerradura que se puede abrir desde el interior de una casa es una vulnerabilidad de seguridad, porque un ladrón que ya está en la casa podría abrir la puerta y dejar que ... los ladrones Adelante ? Mira, cuando uso una analogía sin el velo de la jerga técnica, todo se vuelve ridículo.

Por lo tanto, el informe del escáner no es apropiado. Tu problema es encontrar la manera correcta de callarlo. Mi recomendación sería no usar un "escáner de seguridad" que hace esos informes estúpidos.

Ahora, si miramos los detalles, hay algo "subóptimo" en este negocio de "Nombre fuerte"; Es decir, el hash se trunca a 64 bits. Esto significa que la resistencia a preimágenes es 2 ⁶⁴ , que es alta pero todavía alcanzable tecnológicamente (un esfuerzo de esa magnitud se ha hecho públicamente al menos una vez (aparentemente, se ha iniciado un segundo esfuerzo de ese tipo en varias universidades para resolver el registro discreto en una curva elíptica de 128 bits, que se concluirá dentro de un estimado diez años). Un atacante podría intentar generar una clave pública que coincida con el token de clave pública utilizado para una DLL específica; si tiene éxito, entonces puede crear una DLL falsa que será aceptada por las aplicaciones, y para esto solo necesitaría un acceso "normal" al GAC (aún no es una preocupación si ningún atacante potencial puede abrir una sesión de usuario normal en sus máquinas) ).

La producción de 2 ⁶⁴ pares de claves RSA es costosa (no tanto como lo creerías porque el atacante puede generar claves no válidas, pero aún así caras) así que dudo que este ataque sea muy práctico, pero el margen de seguridad es bastante bajo.

Sólo quería añadir:

  

Esta vulnerabilidad tiene una puntuación de CVSS de 10.0, lo que la hace equivalente a la peor vulnerabilidad posible jamás encontrada.

Definitivamente no siempre puedes asumir eso. No todas las vulnerabilidades de CVSS 10 son iguales ... algunas son mucho, mucho más graves que otras. Honestamente, es muy difícil asignar un valor numérico plano a una vulnerabilidad.