El cielo no se está cayendo: los errores de OpenSSL revelados son graves pero no críticos

Los expertos en seguridad describieron dos vulnerabilidades muy esperadas que el equipo del Proyecto OpenSSL parchó el martes como problemas que deben abordarse rápidamente, pero que no necesariamente ameritan una respuesta de emergencia del tipo de abandono de todo lo demás.

El lanzamiento de la versión 3.0.7 de la biblioteca criptográfica utilizada casi en todas partes aborda dos vulnerabilidades de desbordamiento del búfer, que existen en las versiones 3.0.0 a 3.0.6 de OpenSSL.

Antes de la divulgación, los expertos en seguridad habían advertido que uno de los problemas, originally characterized as a “critical” remote code-execution issue, could present a Heartbleed-level, all-hands-on-deck problem. Thankfully, that doesn’t seem to be the case — and in disclosing the flaw, the OpenSSL project team said it had decided to downgrade the threat to “high” basado en comentarios de organizaciones que habían probado y analizado el error.

Un par de desbordamientos de búfer

El primer error (CVE-2022-3602) could indeed — under a specific set of circumstances — enable RCE, which originally led some security experts to worry that the flaw could have industry-wide repercussions. But it turns out that there are mitigating circumstances: For one, it’s difficult to exploit, as explained below. Also, not all systems are impacted.

Específicamente, sólo los navegadores que soportan OpenSSL 3.0.0 a 3.0.6, como Firefox e Internet Explorer, se ven afectados en este momento, según Mark Ellzey, investigador senior de seguridad de Censys; Google Chrome, el principal navegador de Internet, no se ha visto afectado.

“The impact is expected to be minimal due to the complexity of the attack and the limitations in how it can be carried out,” he says. “Organizations should brush up on their phishing training and keep an eye on threat intelligence sources to ensure they are prepared if they are targeted by an attack such as this.”

To boot, Alex Ilgayev, lead security researcher at Cycode, noted that the flaw can’t be exploited on certain Linux distributions; and, many modern OS platforms implement stack overflow protections to mitigate against threats like these in any event, Ilgayev says.

La segunda vulnerabilidad (CVE-2022-3786), que se descubrió mientras se desarrollaba una solución para la falla original, podría usarse para desencadenar condiciones de denegación de servicio (DoS). El equipo de OpenSSL evaluó la vulnerabilidad como de alta gravedad, pero descartó la posibilidad de que se utilizara para la explotación de RCE.

Ambas vulnerabilidades están vinculadas a una funcionalidad llamada Punycode para codificar nombres de dominio internacionalizados.

“Users of OpenSSL 3.0.0 – 3.0.6 are Se recomienda actualizar a 3.0.7 lo antes posible.,” the OpenSSL team said in a blog accompanying the bug disclosure and release of the new version of the cryptographic library. “If you obtain your copy of OpenSSL from your Operating System vendor or other third party then you should seek to obtain an updated version from them as soon as possible.”

Ni otro sangrado del corazón

La divulgación del error seguramente frenará, al menos por el momento, la preocupación generalizada desatada by the OpenSSL team’s notification last week of its then-impending bug disclosure. The description of the first flaw as being “critical,” in particular, had prompted several comparisons to 2014’s “Heartbleed” bug — the only other bug in OpenSSL to earn a critical rating. That bug (CVE-2014-0160) impacted a wide swathe of the Internet and even now has not be fully addressed at many organizations.

“Heartbleed was exposed by default on any software that used a vulnerable version of OpenSSL, and it was very easily exploitable by attackers to see cryptographic keys and passwords stored in server memory,” says Jonathan Knudsen, head of global research at Synopsys Cybersecurity Research Center. “The two vulnerabilities just reported in OpenSSL are serious but not of the same magnitude.”

OpenSSL Bugs Are Hard to Exploit…

Para explotar cualquiera de las nuevas fallas, los servidores vulnerables necesitarían solicitar autenticación de certificado del cliente, lo cual no es la norma, dice Knudsen. Y los clientes vulnerables necesitarían conectarse a un servidor malicioso, lo cual es un vector de ataque común y defendible, afirma.

“Nobody’s hair should be on fire about these two vulnerabilities, but they are serious and should be handled with appropriate speed and diligence,” he notes.

Mientras tanto, en una publicación de blog, SANS Internet Storm Center describió la actualización de OpenSSL como corregir un desbordamiento del búfer durante el proceso de verificación del certificado. Para que un exploit funcione, el certificado debería contener un nombre codificado en Punycode malicioso y la vulnerabilidad se activaría sólo después de que se verifique la cadena de certificados.

“An attacker first needs to be able to have a malicious certificate signed by a certificate authority the client trusts,” SANS ISC noted. “This does not appear to be exploitable against servers. For servers, this may be exploitable if the server requests a certificate from the client.”

Bottom line: The likelihood of exploitation is low since the vulnerability is complex to exploit, as is the flow and requirements to trigger it, Cycode’s Ilgayev says. Plus, it affects a relatively small number of systems, compared to those using pre-3.0 versions of OpenSSL.

…But Do Be Diligent

Al mismo tiempo, es importante tener en cuenta que en el pasado se han aprovechado vulnerabilidades difíciles de explotar, afirma Ilgayev, señalando un exploit sin clic que NSO Group desarrolló para una vulnerabilidad en iOS el año pasado.

“[Also], like the OpenSSL team says, there is ‘no way of knowing how every platform and compiler combination has arranged the buffers on the stack,’ and therefore remote code execution may still be possible on some platforms,” he cautions.

Y, de hecho, Ellzey describe un escenario de cómo los atacantes podrían explotar CVE-2022-3602, la falla que el equipo de OpenSSL había evaluado originalmente como crítica.

“An attacker would host a malicious server and attempt to get victims to authenticate to it with an application vulnerable to OpenSSL v3.x, potentially through traditional phishing tactics,” he says, although the scope is limited due to the exploit being predominantly client-side.

Vulnerabilidades como esta resaltan la importancia de tener una lista de materiales de software (SBOM) for every binary used, Ilgayev notes. “Looking at package managers is not enough as this library could be linked and compiled in various configurations that will affect the exploitability,” he says.