colmmacc/cve-2022-3602Análisis técnico en profundidad y anti-POC para CVE-2022-3602, un desbordamiento de búfer de punycode en OpenSSL 3.0.x, con scripts de reproducción, análisis de pila y evaluación de mitigaciones del compilador.
Este documento y repositorio es un informe técnico de CVE−2022-3602, un problema de desbordamiento de búfer en punycode dentro de OpenSSL. Es un «anti-POC» (el problema no parece explotable) pensado para quienes mantienen sus propias compilaciones de OpenSSL y para los mantenedores de compiladores.
Hay un CVE separado en la misma versión, CVE-2022-3786, que también provoca desbordamientos de búfer, pero en ese caso un atacante no puede controlar el contenido. Aquí no hay reproducción para ese problema, pero ese problema puede provocar una denegación de servicio debido a una caída.
Las caídas y los desbordamientos de búfer nunca son buenos y, si estás usando OpenSSL 3.0.x, es prudente actualizar lo antes posible.
No dudes en informar de cualquier error u omisión mediante GitHub issues o pull-requests.
Hay un error off-by-one en la forma en que ossl_punycode_decode maneja la decodificación punycode que da como resultado un desbordamiento de 4 bytes. Este problema solo es alcanzable cuando OpenSSL procesa una cadena de certificados y requiere dos condiciones. En primer lugar, un certificado CA o intermedio de una cadena debe contener un campo name-constraint que use punycode.
nameConstraints = permitted;email:xn-maccrthaigh-n7a.com
En segundo lugar, el certificado hoja debe contener un campo otherName de SubjectAlternateName (SAN) que especifique una cadena SmtpUTF8Mailbox.
otherName = 1.3.6.1.5.5.7.8.9;UTF8:[email protected]
Al activarse, el punycode del campo nameConstraints, pero no el del campo otherName, será procesado por el análisis de punycode vulnerable de OpenSSL.
David Benjamin y Matt Caswell determinaron que la comprobación de nameConstraint se produce después de la validación ordinaria de la cadena de certificados y de la verificación de firmas. Para la mayoría de las aplicaciones, esto significa que el problema no se puede activar con un certificado autofirmado o una cadena no válida.
Ten en cuenta que las aplicaciones s_client y s_server de openssl están pensadas para depuración y no detienen el procesamiento cuando una cadena no es válida.
Una CA o un intermedio de confianza tendrá que contener la carga maliciosa y también tendrá que haber firmado el certificado hoja que activa el problema.
Puede haber algunos entornos en los que las partes no confiables sean las CA o los intermedios, por ejemplo un servicio de hosting que admita CA privadas proporcionadas por el cliente, pero esto no es común.
Para muchas aplicaciones, la respuesta será «no», debido a cómo el compilador ha dispuesto la pila y a la presencia de otras protecciones como stack canaries / stack cookies, relleno, PIE, FORTIFY_SOURCE.
El problema sí provoca un desbordamiento de 32 bits en la pila. Esto no es suficiente para ejecutar directamente shellcode, pero puede ser suficiente para alterar el flujo de control de una aplicación. Por ejemplo, saltar a shellcode incrustado en una cadena de certificados X509 puede ser posible si estos datos también se copian en la pila en una ubicación ejecutable.
En todas las plataformas Linux que he probado, el desbordamiento ocurre en el relleno y es inofensivo. En teoría, un compilador puede distribuir las variables de modo que el desbordamiento ocurra en una de las otras variables de la función ossl_a2ulabel.
Dependiendo de la inserción en línea (inlining), la lista completa de variables presentes es:
outptr, inptr, size, result, tmpptr, delta, seed, utfsize
y ninguna me parece que ofrezca una vía obvia para la escalada de privilegios o un control interesante.
He adjuntado un tarball con herramientas que se pueden usar para crear reproducciones y desbordamientos con el mayor control posible sobre los cuatro bytes. La cadena de reproducción de referencia (xn--ww90271...aaaa) desborda los cuatro bytes con los valores 0xFF 0x0F 0x0F 0x0F. Si eso no hace fallar una aplicación, es posible (¿probable?) que esa aplicación no sea vulnerable.
El script de shell run-poc se puede usar para generar una cadena de certificados maliciosa. Un certificado CA malicioso se genera a partir de ca.cnf, y un certificado hoja desencadenante se genera a partir de leaf.cnf.
El certificado CA usa la siguiente carga de referencia:
xn--ww902716aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Se puede usar un script de Python para generar otras cadenas punycode para diferentes cargas.
Al ejecutarse, run-poc lanzará un cliente y un servidor openssl e intentará explotar el problema diez veces.
Un OpenSSL vulnerable probablemente fallará. Eso no significa que la versión de OpenSSL sea vulnerable a un RCE, ya que los stack canaries y las protecciones de stack cookies también suelen provocar una caída (más segura) de la aplicación. Ten en cuenta también que esto no cambia en nada la gravedad del otro CVE de la misma versión.
Obtener un control casi total de los cuatro bytes de desbordamiento es sorprendentemente delicado y requiere explotar el decodificador de punycode de OpenSSL con punycode no estándar / no válido. El tarball adjunto contiene un script que puede construir una cadena que maneja ese matiz. A continuación se explica cómo funciona.
El problema de seguridad está en ossl_punycode_decode()
int ossl_punycode_decode(const char *pEncoded, const size_t enc_len,
unsigned int *pDecoded, unsigned int *pout_length)
ossl_punycode_decode se invoca desde ossl_a2ulabel. El búfer pEncoded es un búfer de tamaño más o menos arbitrario que proviene de una cadena de certificados X509. Es la parte que viene después de cualquier "xn--" en un campo nameConstraint. Consulta la [reproduction] para ver cómo reproducir una cadena de certificados de este tipo.
pDecoded es un array de unsigned int con tamaño LABEL_BUF_SIZE. LABEL_BUF_SIZE es 512 y, en la mayoría de las plataformas, un unsigned int tendrá 4 bytes de ancho. Por lo tanto, en la mayoría de las plataformas, pDecoded tiene una longitud de 2048 bytes.
Dentro de ossl_punycode_decode(), el quid del problema es esta comprobación de longitud incorrecta:
if (written_out > max_out)
max_out corresponde a *pout_length, que siempre es 512. Y written_out lleva la cuenta de cuántos unsigned int se han escrito en pDecoded. Debido a que written_out se incrementa después, solo tras escribir, esta comprobación defectuosa permite escribir 513 unsigned int en pDecoded. El resultado final se parece a esto ...
pDecoded = [ ... , 'X , 'Y' , 'Z' ] 'P'
// Indices 509 510 511
Aquí, según la convención de C, los índices están basados en cero, por lo que la ranura número 511 es el elemento 512 del array. 'P' es una carga de cuatro bytes que se ha colocado fuera de los límites, más allá del espacio asignado en la pila para el búfer buf en ossl_a2ulabel(), que es a lo que apunta pDecoded.