OpenSSL corrige dos fallos criptográficos de una sola línea

Hace poco más de una semana, los medios de comunicación se llenaron de noticias sobre un fallo potencialmente grave en la biblioteca criptográfica de uso generalizado OpenSSL.

Algunos titulares de tono dramático llegaron a describir el fallo como posiblemente “peor que Heartbleed”. Heartbleed, como recordarás, fue un error de fitrado de datos de gran repercusión que pasó desapercibido en OpenSSL durante varios años antes de salir a la luz en 2014.

De hecho, Heartbleed puede considerarse un excelente ejemplo de lo que posteriormente Naked Security denominaría en broma BWAIN, abreviatura de Bug With An Impressive Name (fallo con un nombre impresionante).

Esto ocurre cuando los descubridores de un fallo intentan maximizar su cobertura mediática con un nombre que favorezca las relaciones públicas, un logotipo, un sitio web dedicado e incluso, en un caso memorable, una melodía.

Heartbleed fue un fallo que expuso a muchísimos sitios web de cara al público a un tráfico malicioso que decía, de manera muy simplificada, “¡Oye! Dime que sigues ahí devolviendo este mensaje: RECIBIDO. Por cierto, devuelve el texto en un buffer de memoria de 64.000 bytes”.

Los servidores sin parches responderían con algo como: RECIBIDO [seguido de 64000 menos 5 bytes de lo que acabara de suceder seguido en la memoria, tal vez incluyendo peticiones web de otras personas o incluso contraseñas y claves privadas].

Como te puedes imaginar, una vez que se difundió la noticia de Heartbleed, los cibercriminales y los “investigadores” fanfarrones abusaron fácil, rápida y ampliamente del error.

Malo, pero no tanto

No creemos que estas últimas vulnerabilidades alcancen ese nivel de explotabilidad o peligro inmediato, pero definitivamente vale la pena parchearlos tan pronto como se pueda.

Curiosamente, los dos fallos corregidos en esta versión son lo que llamamos en el titular “de una sola línea”, lo que significa que cambiar o añadir una sola línea de código parchea cada uno de los errores.

De hecho, como veremos, uno de los parches implica el cambio de una sola instrucción de ensamblador, lo que en última instancia resulta en un solo bit cambiado en el código compilado.

Las vulnerabilidades son las siguientes:

• CVE-2022-2274: Desbordamiento de memoria en la exponenciación modular RSA. Afortunadamente, este fallo sólo existe para los ordenadores que soportan el conjunto de instrucciones especiales AVX512 de Intel, en las compilaciones de OpenSSL que incluyen código de propósito especial para estos chips. El programador debía copiar N enteros largos sin signo (normalmente de 32 o 64 bits cada uno), pero inadvertidamente copiaba N bits en su lugar. La solución consistía en dividir el número total de bits por el tamaño de cada entero sin signo, para calcular la cantidad correcta de datos a copiar.
• CVE-2022-2097: Fuga de datos en el cifrado AES-OCB. Al utilizar las instrucciones especiales de aceleración AES de Intel (ampliamente presentes en la mayoría de los procesadores Intel recientes), el programador debía cifrar N bloques de datos ejecutando un bucle de 1 a N, pero inadvertidamente lo ejecutó de 1 a N-1 en su lugar. Esto significa que el último bloque criptográfico (16 bytes) de un búfer de datos cifrados podría salir con el último bloque de datos siendo todavía el texto plano original.

Las correcciones son sencillas una vez que se sabe lo que se necesita:

El código de exponenciación modular convierte ahora un recuento de bits en un recuento de enteros, dividiendo el recuento de bits por el número de bytes en un entero multiplicado por 8 (el número de bits en un byte).

El código de cifrado AES-OCB utiliza ahora una prueba JBE (jump if below or equal to) al final de su bucle en lugar de JB (jump if below), que es el mismo tipo de cambio que alterar un bucle C para decir for (i = 1; i <= n; i++) {…} en lugar de for (i = 1; i < n; i++) {…}.

En el código compilado, esto cambia un solo bit de un solo byte, es decir, cambiando el valor del opcode binario 0111 0010 (saltar si es inferior) por el 0111 0100 (saltar si es inferior o igual).

Afortunadamente, no tenemos constancia  que el modo de cifrado especial AES-OCB se utilice de forma generalizada (su equivalente moderno es AES-GCM, si estás familiarizado con los muchos tipos de cifrado AES).

En particular, como señala el equipo de OpenSSL, “OpenSSL no admite suites de cifrado basadas en OCB para TLS y DTLS”, por lo que la seguridad de red de las conexiones SSL/TLS no se ve afectada por este fallo.

¿Qué hacer?

La versión 3.0 de OpenSSL está afectada por estos dos fallos, y se actualiza de la 3.0.4 a la 3.0.5.

La versión 1.1.1 de OpenSSL está afectada por el fallo de fuga de texto plano AES-OCB, y recibe una actualización de 1.1.1p a 1.1.1q.

De los dos fallos, el de exponenciación modular es el más grave.

Esto se debe a que el desbordamiento del búfer significa, en teoría, que algo tan fundamental como comprobar el certificado TLS de un sitio web antes de aceptar una conexión podría ser suficiente para desencadenar la ejecución remota de código (RCE).

Si estás utilizando OpenSSL 3 y realmente no puede actualizar stu código fuente, pero puedes recompilar el código fuente que ya estás utilizando, entonces una posible solución es reconstruir su OpenSSL actual utilizando el ajuste de configuración no-asm.

Tenga en cuenta que el equipo de OpenSSL no recomienda esto, porque elimina casi todas las funciones aceleradas por el ensamblador del código compilado, lo que, por lo tanto, puede ralentizarlo notablemente, pero eliminará por completo las instrucciones AVX512 no deseadas.

Para suprimir sólo el código AES-OCB dañino, puedes recompilar con el ajuste de configuración no-ocb, que debería ser una intervención inofensiva si no estás usando a sabiendas el modo OCB en tu propio software.

Pero la mejor solución es, como siempre: ¡Parchea pronto, parchea a menudo!