Análisis profundo: búsqueda y corrección de vulnerabilidades de alta gravedad en libcurl/curl
Hace poco tiempo, las comunidades de seguridad y desarrollo recibieron un aviso del Proyecto curlsu desarrollador principal, Daniel Stenberg, quien dejó caer la desafortunada misiva que se publicó una nueva versión de curl, distribuida el 11 de octubre, para abordar dos vulnerabilidades de seguridad de alto impacto, una de las cuales describe como «probablemente la peor falla de seguridad de Curl en mucho tiempo».
UN autopsia 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 pilas, relacionada con un problema heredado con el protocolo de proxy SOCKS5, en uso desde 2002.
Con su uso como 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 generalizado, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones continuas para la seguridad cibernética 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 de búfer
El exploit se detalla en CVE-2023-38545, y afecta a las versiones 7.69.0 de curl y 8.3.0, inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en pilas, y los informes iniciales indican que una explotación exitosa podría provocar un ataque de ejecución remota de código (RCE) más devastador. Si bien se trata de un posible flujo de trabajo para un actor de amenazas, se trata de un caso de uso poco frecuente y no algo dado por hecho.
Quizás la única gracia salvadora para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar por un proxy SOCKS5, lo cual es un despliegue relativamente poco común.
Al igual que el exploit curl, echemos un vistazo a esta explicación sobre Buffer Overflow:
Cuando se le diga 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 siguiente fragmento de código: fuente).
En caso de que el enlace entre el cliente y el proxy sea lento, 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 parte de memoria asignada solo admite un valor de 255 bytes, por lo que si recibe un valor que supera este límite, los datos desbordarán los límites del búfer de memoria.
>>> Pruébelo usted mismo en este misión jugable!
El desbordamiento de búfer es un poderoso vector de ataque que puede prevalecer en muchos lenguajes de programación antiguos. En este caso concreto, la explotación dio paso a un ataque más grave y perjudicial en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco frecuente e improbable.
¿Cómo se puede mitigar el riesgo de desbordamiento de búfer?
En este momento, la solución de máxima prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido que puede que no sea necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, es necesaria la auditoría y la posterior aplicación de parches.
En general, los defectos de desbordamiento del búfer se pueden mitigar mediante el uso de un lenguaje que proteja la memoria, como Óxido, sin embargo, como es el caso de un proyecto extenso como curl, no es práctico migrarlo a otro idioma o reescribirlo por capricho. Como Stenberg notas mientras discutíamos la posibilidad de usar y soportar más dependencias escritas en lenguajes seguros para la memoria, o la alternativa de reemplazar gradualmente partes de curl de forma gradual, «... el desarrollo está... actualmente ocurriendo a una velocidad casi glacial y muestra con una claridad dolorosa los desafíos involucrados. Curl permanecerá escrito en C en un futuro próximo». 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 los escáneres y las pruebas para detectar todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos errores es el compromiso con la concienciación continua en materia de seguridad y el desarrollo de habilidades.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos?
Prueba nuestro Desafío Heap Overflow gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto 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 pilas, relacionada con un problema heredado con el protocolo de proxy SOCKS5. Descubre cómo encontrar y corregir este tipo de vulnerabilidad con una misión jugable.
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
Hace poco tiempo, las comunidades de seguridad y desarrollo recibieron un aviso del Proyecto curlsu desarrollador principal, Daniel Stenberg, quien dejó caer la desafortunada misiva que se publicó una nueva versión de curl, distribuida el 11 de octubre, para abordar dos vulnerabilidades de seguridad de alto impacto, una de las cuales describe como «probablemente la peor falla de seguridad de Curl en mucho tiempo».
UN autopsia 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 pilas, relacionada con un problema heredado con el protocolo de proxy SOCKS5, en uso desde 2002.
Con su uso como 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 generalizado, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones continuas para la seguridad cibernética 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 de búfer
El exploit se detalla en CVE-2023-38545, y afecta a las versiones 7.69.0 de curl y 8.3.0, inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en pilas, y los informes iniciales indican que una explotación exitosa podría provocar un ataque de ejecución remota de código (RCE) más devastador. Si bien se trata de un posible flujo de trabajo para un actor de amenazas, se trata de un caso de uso poco frecuente y no algo dado por hecho.
Quizás la única gracia salvadora para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar por un proxy SOCKS5, lo cual es un despliegue relativamente poco común.
Al igual que el exploit curl, echemos un vistazo a esta explicación sobre Buffer Overflow:
Cuando se le diga 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 siguiente fragmento de código: fuente).
En caso de que el enlace entre el cliente y el proxy sea lento, 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 parte de memoria asignada solo admite un valor de 255 bytes, por lo que si recibe un valor que supera este límite, los datos desbordarán los límites del búfer de memoria.
>>> Pruébelo usted mismo en este misión jugable!
El desbordamiento de búfer es un poderoso vector de ataque que puede prevalecer en muchos lenguajes de programación antiguos. En este caso concreto, la explotación dio paso a un ataque más grave y perjudicial en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco frecuente e improbable.
¿Cómo se puede mitigar el riesgo de desbordamiento de búfer?
En este momento, la solución de máxima prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido que puede que no sea necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, es necesaria la auditoría y la posterior aplicación de parches.
En general, los defectos de desbordamiento del búfer se pueden mitigar mediante el uso de un lenguaje que proteja la memoria, como Óxido, sin embargo, como es el caso de un proyecto extenso como curl, no es práctico migrarlo a otro idioma o reescribirlo por capricho. Como Stenberg notas mientras discutíamos la posibilidad de usar y soportar más dependencias escritas en lenguajes seguros para la memoria, o la alternativa de reemplazar gradualmente partes de curl de forma gradual, «... el desarrollo está... actualmente ocurriendo a una velocidad casi glacial y muestra con una claridad dolorosa los desafíos involucrados. Curl permanecerá escrito en C en un futuro próximo». 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 los escáneres y las pruebas para detectar todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos errores es el compromiso con la concienciación continua en materia de seguridad y el desarrollo de habilidades.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos?
Prueba nuestro Desafío Heap Overflow gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
Hace poco tiempo, las comunidades de seguridad y desarrollo recibieron un aviso del Proyecto curlsu desarrollador principal, Daniel Stenberg, quien dejó caer la desafortunada misiva que se publicó una nueva versión de curl, distribuida el 11 de octubre, para abordar dos vulnerabilidades de seguridad de alto impacto, una de las cuales describe como «probablemente la peor falla de seguridad de Curl en mucho tiempo».
UN autopsia 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 pilas, relacionada con un problema heredado con el protocolo de proxy SOCKS5, en uso desde 2002.
Con su uso como 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 generalizado, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones continuas para la seguridad cibernética 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 de búfer
El exploit se detalla en CVE-2023-38545, y afecta a las versiones 7.69.0 de curl y 8.3.0, inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en pilas, y los informes iniciales indican que una explotación exitosa podría provocar un ataque de ejecución remota de código (RCE) más devastador. Si bien se trata de un posible flujo de trabajo para un actor de amenazas, se trata de un caso de uso poco frecuente y no algo dado por hecho.
Quizás la única gracia salvadora para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar por un proxy SOCKS5, lo cual es un despliegue relativamente poco común.
Al igual que el exploit curl, echemos un vistazo a esta explicación sobre Buffer Overflow:
Cuando se le diga 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 siguiente fragmento de código: fuente).
En caso de que el enlace entre el cliente y el proxy sea lento, 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 parte de memoria asignada solo admite un valor de 255 bytes, por lo que si recibe un valor que supera este límite, los datos desbordarán los límites del búfer de memoria.
>>> Pruébelo usted mismo en este misión jugable!
El desbordamiento de búfer es un poderoso vector de ataque que puede prevalecer en muchos lenguajes de programación antiguos. En este caso concreto, la explotación dio paso a un ataque más grave y perjudicial en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco frecuente e improbable.
¿Cómo se puede mitigar el riesgo de desbordamiento de búfer?
En este momento, la solución de máxima prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido que puede que no sea necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, es necesaria la auditoría y la posterior aplicación de parches.
En general, los defectos de desbordamiento del búfer se pueden mitigar mediante el uso de un lenguaje que proteja la memoria, como Óxido, sin embargo, como es el caso de un proyecto extenso como curl, no es práctico migrarlo a otro idioma o reescribirlo por capricho. Como Stenberg notas mientras discutíamos la posibilidad de usar y soportar más dependencias escritas en lenguajes seguros para la memoria, o la alternativa de reemplazar gradualmente partes de curl de forma gradual, «... el desarrollo está... actualmente ocurriendo a una velocidad casi glacial y muestra con una claridad dolorosa los desafíos involucrados. Curl permanecerá escrito en C en un futuro próximo». 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 los escáneres y las pruebas para detectar todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos errores es el compromiso con la concienciación continua en materia de seguridad y el desarrollo de habilidades.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos?
Prueba nuestro Desafío Heap Overflow gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
報告書を見るデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
Hace poco tiempo, las comunidades de seguridad y desarrollo recibieron un aviso del Proyecto curlsu desarrollador principal, Daniel Stenberg, quien dejó caer la desafortunada misiva que se publicó una nueva versión de curl, distribuida el 11 de octubre, para abordar dos vulnerabilidades de seguridad de alto impacto, una de las cuales describe como «probablemente la peor falla de seguridad de Curl en mucho tiempo».
UN autopsia 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 pilas, relacionada con un problema heredado con el protocolo de proxy SOCKS5, en uso desde 2002.
Con su uso como 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 generalizado, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones continuas para la seguridad cibernética 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 de búfer
El exploit se detalla en CVE-2023-38545, y afecta a las versiones 7.69.0 de curl y 8.3.0, inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en pilas, y los informes iniciales indican que una explotación exitosa podría provocar un ataque de ejecución remota de código (RCE) más devastador. Si bien se trata de un posible flujo de trabajo para un actor de amenazas, se trata de un caso de uso poco frecuente y no algo dado por hecho.
Quizás la única gracia salvadora para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar por un proxy SOCKS5, lo cual es un despliegue relativamente poco común.
Al igual que el exploit curl, echemos un vistazo a esta explicación sobre Buffer Overflow:
Cuando se le diga 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 siguiente fragmento de código: fuente).
En caso de que el enlace entre el cliente y el proxy sea lento, 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 parte de memoria asignada solo admite un valor de 255 bytes, por lo que si recibe un valor que supera este límite, los datos desbordarán los límites del búfer de memoria.
>>> Pruébelo usted mismo en este misión jugable!
El desbordamiento de búfer es un poderoso vector de ataque que puede prevalecer en muchos lenguajes de programación antiguos. En este caso concreto, la explotación dio paso a un ataque más grave y perjudicial en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco frecuente e improbable.
¿Cómo se puede mitigar el riesgo de desbordamiento de búfer?
En este momento, la solución de máxima prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido que puede que no sea necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, es necesaria la auditoría y la posterior aplicación de parches.
En general, los defectos de desbordamiento del búfer se pueden mitigar mediante el uso de un lenguaje que proteja la memoria, como Óxido, sin embargo, como es el caso de un proyecto extenso como curl, no es práctico migrarlo a otro idioma o reescribirlo por capricho. Como Stenberg notas mientras discutíamos la posibilidad de usar y soportar más dependencias escritas en lenguajes seguros para la memoria, o la alternativa de reemplazar gradualmente partes de curl de forma gradual, «... el desarrollo está... actualmente ocurriendo a una velocidad casi glacial y muestra con una claridad dolorosa los desafíos involucrados. Curl permanecerá escrito en C en un futuro próximo». 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 los escáneres y las pruebas para detectar todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos errores es el compromiso con la concienciación continua en materia de seguridad y el desarrollo de habilidades.
¿Quiere obtener más información sobre cómo escribir código seguro y mitigar los riesgos?
Prueba nuestro Desafío Heap Overflow gratis.
Si estás interesado en obtener más pautas de codificación gratuitas, consulta Entrenador de código seguro para ayudarlo a mantenerse al tanto de las mejores prácticas de codificación segura.
%20(1).avif)
.avif)
