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
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Recursos para empezar
Cierre el círculo de las vulnerabilidades con Secure Code Warrior + HackerOne
Secure Code Warrior se complace en anunciar nuestra nueva integración con HackerOne, líder en soluciones de seguridad ofensiva. Juntos, estamos construyendo un ecosistema potente e integrado. HackerOne señala dónde se producen realmente las vulnerabilidades en entornos reales, exponiendo el "qué" y el "dónde" de los problemas de seguridad.
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
