La exageración de Curl Bug se desvanece después de la revelación del parche

La exageración de Curl Bug se desvanece después de la revelación del parche

La exageración de Curl Bug se desvanece después del parche que revela la inteligencia de datos de PlatoBlockchain. Búsqueda vertical. Ai.

Desde hace días, la comunidad de ciberseguridad ha esperado ansiosamente la gran revelación sobre dos fallas de seguridad que, según el fundador de curl, Daniel Stenberg, incluían una que probablemente era "la peor falla de seguridad de curl en mucho tiempo".

Curl es una herramienta de resolución de proxy de código abierto que se utiliza como "intermediario" para transferir archivos entre varios protocolos, que está presente literalmente en miles de millones de instancias de aplicaciones. La sugerencia de una falla masiva en la biblioteca de código abierto evocó recuerdos de la catastrófica falla de log4j a partir de 2021. Como le preocupaba Alex Ilgayev, jefe de investigación de seguridad de Cycode, “la vulnerabilidad en la biblioteca curl podría resultar más desafiante que el incidente de Log4j hace dos años”.

Pero siguiendo lo de hoy presentación de parches y detalles de errores, ninguna vulnerabilidad estuvo a la altura de las expectativas.

Impactando un número limitado de implementaciones de Curl

El primer vuln, un falla de desbordamiento del buffer basado en montón rastreado bajo CVE-2023-38545, se le asignó una calificación de “alta” debido al potencial de corrupción de datos o incluso ejecución remota de código (RCE). El problema radica en la transferencia de proxy SOCKS5, según el aviso.

"Cuando se le pide a curl que pase el nombre de host al proxy SOCKS5 para permitir que resuelva la dirección en lugar de que lo haga el propio curl, la longitud máxima que puede tener el nombre de host es de 255 bytes", afirma el aviso. "Si se detecta que el nombre de host tiene más de 255 bytes, curl cambia a la resolución de nombres local y en su lugar pasa la dirección resuelta solo al proxy".

El error podría permitir que se entregue un valor incorrecto durante el protocolo de enlace SOCKS5.

“Debido a un error, la variable local que significa 'dejar que el host resuelva el nombre' podría obtener el valor incorrecto durante un protocolo de enlace SOCKS5 lento y, contrariamente a la intención, copiar el nombre de host demasiado largo al búfer de destino en lugar de copiar solo el dirección resuelta allí”, agrega el aviso.

Sin embargo, la designación de alta gravedad solo se aplica a una fracción de las implementaciones, afirma el experto en ciberseguridad Jake Williams.

"Esto es sólo de alta gravedad en circunstancias muy limitadas", dice Williams. “Creo que es simplemente una cuestión que cuando tienes una vulnerabilidad en la biblioteca, sabes cómo se está utilizando la biblioteca. Hay que asignar el CVE asumiendo el peor de los casos para su implementación”.

El segundo error de curl, rastreado bajo CVE-2023-38546, es una falla de inyección de cookies de baja gravedad que solo afecta a la biblioteca libcurl, no al curl en sí.

"Creo que este es un problema mayor para los dispositivos y dispositivos de seguridad (que obtienen contenido no confiable y a menudo usan curl bajo el capó)", dijo Andy Hornegold en un comunicado en reacción a la publicación de los detalles del error curl. "No veo que sea un gran problema para el uso independiente".

Peligros de promocionar una solución

Más allá de la acidez de estómago para los equipos de ciberseguridad, promocionar una solución antes de que se publiquen los detalles técnicos puede brindar una victoria fácil a los actores de amenazas. En este caso, Williams señala que RedHat actualizó su registro de cambios antes del lanzamiento oficial de curl, lo que podría haber brindado a los ciberatacantes información importante sobre objetivos sin parches, si la vulnerabilidad hubiera sido tan peligrosa como se suponía anteriormente.

De hecho, Mike McGuire de Synopsys vio los peligros de la atención intensificada en la actualización de curl y escribió sobre ello en un blog el 9 de octubre.

"A pesar de no tener detalles adicionales sobre la vulnerabilidad, los actores de amenazas sin duda comenzarán intentos de explotación", escribió McGuire. "Además, no es raro que los atacantes publiquen versiones 'reparadas' falsas de un proyecto plagado de malware para aprovecharse de los equipos que luchan por parchear el software vulnerable".

Sello de tiempo:

Mas de Lectura oscura