Se dio a conocer la noticia sobre la identificación de una vulnerabilidad crítica (ya catalogada bajo CVE-2021-43527) en el conjunto de bibliotecas criptográficas NSS (Servicios de seguridad de red) de Mozilla que podría conducir a la ejecución de código malicioso al procesar firmas digitales DSA o RSA-PSS especificadas mediante la DER (Distinguido reglas de codificación).
El problema se manifiesta en aplicaciones que usan NSS para manejar firmas digitales CMS, S/MIME, PKCS#7 y PKCS#12, o al verificar certificados en implementaciones TLS, X.509, OCSP y CRL. La vulnerabilidad podría surgir en varias aplicaciones de cliente y servidor con soporte TLS, DTLS y S / MIME, clientes de correo electrónico y visores de PDF que utilizan la llamada NSS CERT_VerifyCertificate () para verificar firmas digitales.
LibreOffice, Evolution y Evince se mencionan como ejemplos de aplicaciones vulnerables. Potencialmente, el problema también puede afectar proyectos como Pidgin, Apache OpenOffice, Suricata, Curl, entre otros.
Al mismo tiempo, la vulnerabilidad no aparece en Firefox, Thunderbird y Tor Browser, que utilizan una biblioteca mozilla::pkix separada para la verificación, que también es parte de NSS. Los navegadores basados en Chrome (a menos que se hayan compilado específicamente con NSS), que usaron NSS hasta 2015, pero luego se transfirieron a BoringSSL, no se ven afectados por el problema.
La vulnerabilidad se debe a un error en el código de verificación de certificado en el vfy_CreateContext función del archivo secvfy.c. El error se manifiesta tanto cuando el cliente lee el certificado del servidor como cuando el servidor procesa los certificados del cliente.
Al verificar una firma digital codificada en DER, NSS decodifica la firma en un búfer de tamaño fijo y pasa este búfer al módulo PKCS # 11. Durante el procesamiento posterior, para las firmas DSA y RSA-PSS, el tamaño se verifica incorrectamente, lo que conduce a un desbordamiento del búfer asignado para la estructura VFYContextStr , si el tamaño de la firma digital supera los 16384 bits (se asignan 2048 bytes para el búfer, pero no se comprueba que la firma pueda ser más grande).
El código que contiene la vulnerabilidad se remonta a 2003, pero no representó una amenaza hasta la refactorización en 2012. En 2017, se cometió el mismo error al implementar el soporte RSA-PSS. Para llevar a cabo un ataque, no se requiere una generación intensiva en recursos de ciertas claves para obtener los datos necesarios, ya que el desbordamiento ocurre en la etapa previa a la verificación de la validez de la firma digital. La parte de los datos fuera de los límites se escribe en un área de memoria que contiene punteros de función, lo que facilita la creación de exploits de trabajo.
La vulnerabilidad fue identificada por investigadores de Google Project Zero durante experimentos con nuevos métodos de pruebas de fuzzing y es una buena demostración de cómo las vulnerabilidades triviales pueden pasar desapercibidas durante mucho tiempo en un proyecto conocido ampliamente probado.
En cuanto a los principales problemas por los que el problema pasó desapercibido durante mucho tiempo:
- La biblioteca de unidades NSS y las pruebas de fuzzing no se llevaron a cabo en su totalidad, sino a nivel de componentes individuales.
- Por ejemplo, el código para decodificar DER y procesar certificados se verificó por separado; en el curso del fuzzing, bien podría haberse obtenido un certificado, lo que llevó a la manifestación de la vulnerabilidad en cuestión, pero su verificación no alcanzó el código de verificación y el problema no se reveló.
- Durante las pruebas de fuzzing, se establecieron límites estrictos en el tamaño de la salida (10,000 bytes) en ausencia de tales limitaciones en NSS (muchas estructuras en modo normal podrían tener un tamaño de más de 10,000 bytes, por lo tanto, para identificar problemas, un mayor cantidad de datos de entrada necesarios). Para una verificación completa, el límite debería haber sido 2 24 -1 bytes (16 MB), que corresponde al tamaño máximo de un certificado permitido en TLS.
- Concepto erróneo sobre la cobertura del código mediante pruebas fuzzing. El código vulnerable se probó activamente, pero utilizando fuzers, que no pudieron generar los datos de entrada requeridos. Por ejemplo, fuzzer tls_server_target usó un conjunto predefinido de certificados listos para usar, que limitaban la verificación del código de verificación del certificado a solo mensajes TLS y cambios de estado del protocolo.
Finalmente, cabe mencionar que el problema con nombre en código BigSig se ha solucionado en NSS 3.73 y NSS ESR 3.68.1 y las actualizaciones de la solución en forma de paquete ya se han lanzado en las diferentes distribuciones: Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD, etc.
Si quieres conocer más al respecto, puedes consultar el siguiente enlace.