Profundización: Detección y corrección de vulnerabilidades de alta gravedad en libcurl/curl
Hace poco tiempo, las comunidades de seguridad y desarrollo fueron puestas sobre aviso con un aviso del desarrollador principal del proyecto curl, Daniel Stenberg, que dejó caer la desafortunada misiva de que una nueva versión de curl -distribuida el 11 de octubre- se lanzaba para solucionar dos vulnerabilidades de seguridad de gran impacto, una de las cuales describe como "probablemente el peor fallo de seguridad de curl en mucho tiempo".
Un postmortem en el blog de Stenberg señaló que las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en Heap, relacionada con un problema heredado con el protocolo proxy SOCKS5 en uso desde 2002.
Con su uso como una herramienta de línea de comandos que se remonta a 1998, curl es ampliamente considerado como un pilar fundamental de Internet. Con una historia tan larga y un uso tan extendido, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones para la ciberseguridad en general.
Este incidente comparte similitudes con el devastador ataque Log4Shell en Log4j, otra dependencia vulnerable que sigue siendo explotada casi dos años después.
>>> ¡Pon a prueba tus conocimientos ahora mismo con nuestra Misión curl!
La vulnerabilidad: Desbordamiento del búfer
El exploit se detalla bajo CVE-2023-38545, y afecta a las versiones de curl 7.69.0 hasta 8.3.0 inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en Heap, y los informes iniciales señalan que una explotación exitosa podría conducir a un ataque de ejecución remota de código (RCE) más devastador. Si bien este es un posible flujo de trabajo para un actor de amenaza, es un caso de uso raro en lugar de un hecho.
Tal vez la única salvación para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar a través de un proxy SOCKS5, que es un despliegue relativamente infrecuente.
Comparable al exploit curl, echemos un vistazo a este Buffer Overflow explainer:
Cuando se le dice a curl que use un proxy SOCKS5, pasará el nombre de host y hará que el proxy lo resuelva. Sin embargo, si el nombre de host supera el límite de 255 bytes, curl resolverá el nombre de host localmente (como se ve en el fragmento de código siguiente: fuente).
En caso de que se produzca un intercambio lento entre el cliente y el proxy, es posible que el nombre de host largo se copie en el búfer de memoria en lugar de la dirección resuelta (más corta). La porción de memoria asignada sólo permite un valor de 255 bytes, por lo que si recibe un valor que exceda este límite, los datos desbordarán los límites del buffer de memoria.
>>> Pruébalo tú mismo en esta misión jugable¡!
El desbordamiento del búfer es un poderoso vector de ataque, que puede ser frecuente en muchos lenguajes de programación heredados. En este caso concreto, la explotación dio paso a un ataque más grave y dañino en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco común y poco probable.
¿Cómo mitigar el riesgo de desbordamiento del búfer?
En esta etapa, la remediación de mayor prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido, que puede no ser necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, se requiere auditoría y posterior aplicación de parches.
En general, los fallos de desbordamiento de búfer pueden mitigarse utilizando un lenguaje seguro para la memoria como Rust, sin embargo, como es el caso de un proyecto tan extenso como curl, no es práctico portarlo a otro lenguaje o reescribirlo por capricho. Como Stenberg señala mientras discute el potencial para usar y soportar más dependencias escritas en lenguajes seguros para la memoria - o la alternativa de reemplazar gradualmente partes de curl poco a poco - "... el desarrollo está... ocurriendo actualmente a una velocidad casi glacial y muestra con dolorosa claridad los desafíos involucrados. curl permanecerá escrito en C en el futuro previsible". No es una empresa pequeña, y las implicaciones de seguridad son inmensas.
Los errores de seguridad pueden ocurrir y ocurrirán, y no siempre es posible confiar en que los escáneres y las pruebas detecten todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos fallos es el compromiso con la concienciación y la capacitación continuas en materia de seguridad.
¿Quiere saber más sobre cómo escribir código seguro y mitigar los riesgos?
Pruebe nuestro Heap Overflow gratis.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Entrenador de código seguro que le ayudará a mantenerse al día de las mejores prácticas de codificación segura.
.avif)
Las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en Heap, relacionada con un problema heredado con el protocolo proxy SOCKS5. Aprenda a encontrar y solucionar este tipo de vulnerabilidad con una misión jugable.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
Hace poco tiempo, las comunidades de seguridad y desarrollo fueron puestas sobre aviso con un aviso del desarrollador principal del proyecto curl, Daniel Stenberg, que dejó caer la desafortunada misiva de que una nueva versión de curl -distribuida el 11 de octubre- se lanzaba para solucionar dos vulnerabilidades de seguridad de gran impacto, una de las cuales describe como "probablemente el peor fallo de seguridad de curl en mucho tiempo".
Un postmortem en el blog de Stenberg señaló que las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en Heap, relacionada con un problema heredado con el protocolo proxy SOCKS5 en uso desde 2002.
Con su uso como una herramienta de línea de comandos que se remonta a 1998, curl es ampliamente considerado como un pilar fundamental de Internet. Con una historia tan larga y un uso tan extendido, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones para la ciberseguridad en general.
Este incidente comparte similitudes con el devastador ataque Log4Shell en Log4j, otra dependencia vulnerable que sigue siendo explotada casi dos años después.
>>> ¡Pon a prueba tus conocimientos ahora mismo con nuestra Misión curl!
La vulnerabilidad: Desbordamiento del búfer
El exploit se detalla bajo CVE-2023-38545, y afecta a las versiones de curl 7.69.0 hasta 8.3.0 inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en Heap, y los informes iniciales señalan que una explotación exitosa podría conducir a un ataque de ejecución remota de código (RCE) más devastador. Si bien este es un posible flujo de trabajo para un actor de amenaza, es un caso de uso raro en lugar de un hecho.
Tal vez la única salvación para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar a través de un proxy SOCKS5, que es un despliegue relativamente infrecuente.
Comparable al exploit curl, echemos un vistazo a este Buffer Overflow explainer:
Cuando se le dice a curl que use un proxy SOCKS5, pasará el nombre de host y hará que el proxy lo resuelva. Sin embargo, si el nombre de host supera el límite de 255 bytes, curl resolverá el nombre de host localmente (como se ve en el fragmento de código siguiente: fuente).
En caso de que se produzca un intercambio lento entre el cliente y el proxy, es posible que el nombre de host largo se copie en el búfer de memoria en lugar de la dirección resuelta (más corta). La porción de memoria asignada sólo permite un valor de 255 bytes, por lo que si recibe un valor que exceda este límite, los datos desbordarán los límites del buffer de memoria.
>>> Pruébalo tú mismo en esta misión jugable¡!
El desbordamiento del búfer es un poderoso vector de ataque, que puede ser frecuente en muchos lenguajes de programación heredados. En este caso concreto, la explotación dio paso a un ataque más grave y dañino en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco común y poco probable.
¿Cómo mitigar el riesgo de desbordamiento del búfer?
En esta etapa, la remediación de mayor prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido, que puede no ser necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, se requiere auditoría y posterior aplicación de parches.
En general, los fallos de desbordamiento de búfer pueden mitigarse utilizando un lenguaje seguro para la memoria como Rust, sin embargo, como es el caso de un proyecto tan extenso como curl, no es práctico portarlo a otro lenguaje o reescribirlo por capricho. Como Stenberg señala mientras discute el potencial para usar y soportar más dependencias escritas en lenguajes seguros para la memoria - o la alternativa de reemplazar gradualmente partes de curl poco a poco - "... el desarrollo está... ocurriendo actualmente a una velocidad casi glacial y muestra con dolorosa claridad los desafíos involucrados. curl permanecerá escrito en C en el futuro previsible". No es una empresa pequeña, y las implicaciones de seguridad son inmensas.
Los errores de seguridad pueden ocurrir y ocurrirán, y no siempre es posible confiar en que los escáneres y las pruebas detecten todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos fallos es el compromiso con la concienciación y la capacitación continuas en materia de seguridad.
¿Quiere saber más sobre cómo escribir código seguro y mitigar los riesgos?
Pruebe nuestro Heap Overflow gratis.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Entrenador de código seguro que le ayudará a mantenerse al día de las mejores prácticas de codificación segura.
Hace poco tiempo, las comunidades de seguridad y desarrollo fueron puestas sobre aviso con un aviso del desarrollador principal del proyecto curl, Daniel Stenberg, que dejó caer la desafortunada misiva de que una nueva versión de curl -distribuida el 11 de octubre- se lanzaba para solucionar dos vulnerabilidades de seguridad de gran impacto, una de las cuales describe como "probablemente el peor fallo de seguridad de curl en mucho tiempo".
Un postmortem en el blog de Stenberg señaló que las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en Heap, relacionada con un problema heredado con el protocolo proxy SOCKS5 en uso desde 2002.
Con su uso como una herramienta de línea de comandos que se remonta a 1998, curl es ampliamente considerado como un pilar fundamental de Internet. Con una historia tan larga y un uso tan extendido, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones para la ciberseguridad en general.
Este incidente comparte similitudes con el devastador ataque Log4Shell en Log4j, otra dependencia vulnerable que sigue siendo explotada casi dos años después.
>>> ¡Pon a prueba tus conocimientos ahora mismo con nuestra Misión curl!
La vulnerabilidad: Desbordamiento del búfer
El exploit se detalla bajo CVE-2023-38545, y afecta a las versiones de curl 7.69.0 hasta 8.3.0 inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en Heap, y los informes iniciales señalan que una explotación exitosa podría conducir a un ataque de ejecución remota de código (RCE) más devastador. Si bien este es un posible flujo de trabajo para un actor de amenaza, es un caso de uso raro en lugar de un hecho.
Tal vez la única salvación para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar a través de un proxy SOCKS5, que es un despliegue relativamente infrecuente.
Comparable al exploit curl, echemos un vistazo a este Buffer Overflow explainer:
Cuando se le dice a curl que use un proxy SOCKS5, pasará el nombre de host y hará que el proxy lo resuelva. Sin embargo, si el nombre de host supera el límite de 255 bytes, curl resolverá el nombre de host localmente (como se ve en el fragmento de código siguiente: fuente).
En caso de que se produzca un intercambio lento entre el cliente y el proxy, es posible que el nombre de host largo se copie en el búfer de memoria en lugar de la dirección resuelta (más corta). La porción de memoria asignada sólo permite un valor de 255 bytes, por lo que si recibe un valor que exceda este límite, los datos desbordarán los límites del buffer de memoria.
>>> Pruébalo tú mismo en esta misión jugable¡!
El desbordamiento del búfer es un poderoso vector de ataque, que puede ser frecuente en muchos lenguajes de programación heredados. En este caso concreto, la explotación dio paso a un ataque más grave y dañino en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco común y poco probable.
¿Cómo mitigar el riesgo de desbordamiento del búfer?
En esta etapa, la remediación de mayor prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido, que puede no ser necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, se requiere auditoría y posterior aplicación de parches.
En general, los fallos de desbordamiento de búfer pueden mitigarse utilizando un lenguaje seguro para la memoria como Rust, sin embargo, como es el caso de un proyecto tan extenso como curl, no es práctico portarlo a otro lenguaje o reescribirlo por capricho. Como Stenberg señala mientras discute el potencial para usar y soportar más dependencias escritas en lenguajes seguros para la memoria - o la alternativa de reemplazar gradualmente partes de curl poco a poco - "... el desarrollo está... ocurriendo actualmente a una velocidad casi glacial y muestra con dolorosa claridad los desafíos involucrados. curl permanecerá escrito en C en el futuro previsible". No es una empresa pequeña, y las implicaciones de seguridad son inmensas.
Los errores de seguridad pueden ocurrir y ocurrirán, y no siempre es posible confiar en que los escáneres y las pruebas detecten todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos fallos es el compromiso con la concienciación y la capacitación continuas en materia de seguridad.
¿Quiere saber más sobre cómo escribir código seguro y mitigar los riesgos?
Pruebe nuestro Heap Overflow gratis.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Entrenador de código seguro que le ayudará a mantenerse al día de las mejores prácticas de codificación segura.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
Hace poco tiempo, las comunidades de seguridad y desarrollo fueron puestas sobre aviso con un aviso del desarrollador principal del proyecto curl, Daniel Stenberg, que dejó caer la desafortunada misiva de que una nueva versión de curl -distribuida el 11 de octubre- se lanzaba para solucionar dos vulnerabilidades de seguridad de gran impacto, una de las cuales describe como "probablemente el peor fallo de seguridad de curl en mucho tiempo".
Un postmortem en el blog de Stenberg señaló que las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en Heap, relacionada con un problema heredado con el protocolo proxy SOCKS5 en uso desde 2002.
Con su uso como una herramienta de línea de comandos que se remonta a 1998, curl es ampliamente considerado como un pilar fundamental de Internet. Con una historia tan larga y un uso tan extendido, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones para la ciberseguridad en general.
Este incidente comparte similitudes con el devastador ataque Log4Shell en Log4j, otra dependencia vulnerable que sigue siendo explotada casi dos años después.
>>> ¡Pon a prueba tus conocimientos ahora mismo con nuestra Misión curl!
La vulnerabilidad: Desbordamiento del búfer
El exploit se detalla bajo CVE-2023-38545, y afecta a las versiones de curl 7.69.0 hasta 8.3.0 inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en Heap, y los informes iniciales señalan que una explotación exitosa podría conducir a un ataque de ejecución remota de código (RCE) más devastador. Si bien este es un posible flujo de trabajo para un actor de amenaza, es un caso de uso raro en lugar de un hecho.
Tal vez la única salvación para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar a través de un proxy SOCKS5, que es un despliegue relativamente infrecuente.
Comparable al exploit curl, echemos un vistazo a este Buffer Overflow explainer:
Cuando se le dice a curl que use un proxy SOCKS5, pasará el nombre de host y hará que el proxy lo resuelva. Sin embargo, si el nombre de host supera el límite de 255 bytes, curl resolverá el nombre de host localmente (como se ve en el fragmento de código siguiente: fuente).
En caso de que se produzca un intercambio lento entre el cliente y el proxy, es posible que el nombre de host largo se copie en el búfer de memoria en lugar de la dirección resuelta (más corta). La porción de memoria asignada sólo permite un valor de 255 bytes, por lo que si recibe un valor que exceda este límite, los datos desbordarán los límites del buffer de memoria.
>>> Pruébalo tú mismo en esta misión jugable¡!
El desbordamiento del búfer es un poderoso vector de ataque, que puede ser frecuente en muchos lenguajes de programación heredados. En este caso concreto, la explotación dio paso a un ataque más grave y dañino en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco común y poco probable.
¿Cómo mitigar el riesgo de desbordamiento del búfer?
En esta etapa, la remediación de mayor prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido, que puede no ser necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, se requiere auditoría y posterior aplicación de parches.
En general, los fallos de desbordamiento de búfer pueden mitigarse utilizando un lenguaje seguro para la memoria como Rust, sin embargo, como es el caso de un proyecto tan extenso como curl, no es práctico portarlo a otro lenguaje o reescribirlo por capricho. Como Stenberg señala mientras discute el potencial para usar y soportar más dependencias escritas en lenguajes seguros para la memoria - o la alternativa de reemplazar gradualmente partes de curl poco a poco - "... el desarrollo está... ocurriendo actualmente a una velocidad casi glacial y muestra con dolorosa claridad los desafíos involucrados. curl permanecerá escrito en C en el futuro previsible". No es una empresa pequeña, y las implicaciones de seguridad son inmensas.
Los errores de seguridad pueden ocurrir y ocurrirán, y no siempre es posible confiar en que los escáneres y las pruebas detecten todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos fallos es el compromiso con la concienciación y la capacitación continuas en materia de seguridad.
¿Quiere saber más sobre cómo escribir código seguro y mitigar los riesgos?
Pruebe nuestro Heap Overflow gratis.
Si está interesado en obtener más directrices de codificación gratuitas, consulte Entrenador de código seguro que le ayudará a mantenerse al día de las mejores prácticas de codificación segura.
Índice
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Temas y contenidos de la formación sobre código seguro
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
Ley de Resiliencia Cibernética (CRA) Vías de aprendizaje alineadas
SCW apoya la preparación para la Ley de Resiliencia Cibernética (CRA) con misiones alineadas con la CRA y colecciones de aprendizaje conceptual que ayudan a los equipos de desarrollo a crear habilidades de diseño seguro, SDLC y codificación segura alineadas con los principios de desarrollo seguro de la CRA.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
Recursos para empezar
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
La IA puede escribir y revisar código, pero los humanos siguen siendo los responsables del riesgo.
El lanzamiento de Claude Code Security por parte de Anthropic marca un punto de inflexión decisivo entre el desarrollo de software asistido por IA y el rápido avance de nuestro enfoque de la ciberseguridad moderna.