Se ha identificado una vulnerabilidad crítica (CVE-2021-43527) en el conjunto de bibliotecas criptográficas NSS (Network Security Services) desarrollado por Mozilla, que puede conducir a la ejecución de código de atacante al procesar firmas digitales DSA o RSA-PSS especificadas mediante el Método de codificación DER (Reglas de codificación distinguidas). El problema, cuyo nombre en código es BigSig, se resuelve en NSS 3.73 y NSS ESR 3.68.1. Las actualizaciones de paquetes en distribuciones están disponibles para Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD. Aún no hay actualizaciones disponibles para Fedora.
El problema ocurre 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 puede aparecer en varias aplicaciones cliente y servidor que admiten 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 a proyectos como Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Certificate System, mod_nss para el servidor Apache http, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition. Sin embargo, la vulnerabilidad no aparece en Firefox, Thunderbird y Tor Browser, que utilizan una biblioteca mozilla::pkix separada, también incluida en NSS, para la verificación. Los navegadores basados en Chromium (a menos que estén construidos específicamente con NSS), que usaron NSS hasta 2015, pero luego cambiaron a BoringSSL, tampoco se ven afectados por el problema.
La vulnerabilidad se debe a un error en el código de verificación del certificado en la función vfy_CreateContext del archivo secvfy.c. El error ocurre tanto cuando el cliente lee un 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 el búfer al módulo PKCS #11. Durante el procesamiento posterior, el tamaño se verifica incorrectamente para las firmas DSA y RSA-PSS, lo que provoca un desbordamiento del búfer asignado para la estructura VFYContextStr si el tamaño de la firma digital excede los 16384 bits (se asignan 2048 bytes para el búfer, pero no se comprueba que la firma pueda ser mayor) ).
El código que contiene la vulnerabilidad se remonta a 2003, pero no representó una amenaza hasta una refactorización realizada en 2012. En 2017, se cometió el mismo error al implementar el soporte RSA-PSS. Para llevar a cabo un ataque, no se requiere la generación intensiva de recursos de ciertas claves para obtener los datos necesarios, ya que el desbordamiento ocurre en la etapa previa a la verificación de la exactitud de la firma digital. La parte de los datos que va más allá de los límites se escribe en un área de memoria que contiene punteros a funciones, lo que simplifica la creación de exploits que funcionen.
La vulnerabilidad fue descubierta por investigadores de Google Project Zero mientras experimentaban con nuevos métodos de prueba de fuzzing y es una buena demostración de cómo las vulnerabilidades triviales pueden pasar desapercibidas durante mucho tiempo en un proyecto conocido y ampliamente probado:
- El código NSS lo mantiene un equipo de seguridad experimentado que utiliza técnicas de prueba y análisis de errores de última generación. Existen varios programas que pagan recompensas importantes por identificar vulnerabilidades en NSS.
- NSS fue uno de los primeros proyectos en unirse a la iniciativa oss-fuzz de Google y también se probó en el sistema de prueba fuzz basado en libFuzzer de Mozilla.
- El código de la biblioteca ha sido verificado muchas veces en varios analizadores estáticos, incluso siendo monitoreado por el servicio Coverity desde 2008.
- Hasta 2015, NSS se usaba en Google Chrome y el equipo de Google lo verificaba de forma independiente de Mozilla (desde 2015, Chrome cambió a BoringSSL, pero la compatibilidad con el puerto basado en NSS permanece).
Los principales problemas por los que el problema pasó desapercibido durante mucho tiempo:
- La biblioteca modular NSS y las pruebas de fuzzing no se llevaron a cabo en su conjunto, sino a nivel de componentes individuales. Por ejemplo, el código para decodificar DER y procesar certificados se verificó por separado; durante la fuzzing, se podría haber obtenido un certificado que conduciría 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 revelarse.
- Durante las pruebas de fuzzing, se establecieron restricciones estrictas en el tamaño de salida (10000 bytes) en ausencia de restricciones similares en NSS (muchas estructuras en modo normal podrían tener un tamaño de más de 10000 bytes, por lo que se requirieron más datos de entrada para identificar problemas) . Para una verificación completa, el límite debería haber sido 224-1 bytes (16 MB), que corresponde al tamaño máximo de certificado permitido en TLS.
- Concepto erróneo sobre la cobertura del código de prueba difusa. El código vulnerable se probó activamente, pero utilizando fuzzers que no pudieron generar los datos de entrada necesarios. Por ejemplo, fuzzer tls_server_target utilizó un conjunto predefinido de certificados listos para usar, que limitó la verificación del código de verificación del certificado solo a mensajes TLS y cambios de estado del protocolo.
Fuente: opennet.ru