심층 분석: 심각도가 높은 libcurl/curl 취약성 발견 및 수정
Just a short time ago, the security and development communities were put on notice with an advisory from the curl Project’s lead developer, Daniel Stenberg, who dropped the unfortunate missive that a new version of curl - distributed October 11 - was released to address two high-impact security vulnerabilities, one of which he describes as "probably the worst curl security flaw in a long time."
A postmortem on Stenberg’s blog noted that affected versions of the curl library are susceptible to a Heap-based buffer overflow vulnerability, related to a legacy issue with the SOCKS5 proxy protocol in use since 2002.
With its usage as a command line tool dating all the way back to 1998, curl is widely regarded as a foundational pillar of the internet. With such a storied history and widespread use, it is a dependency that, if found to be vulnerable, could have ongoing implications for general cyber safety.
This incident shares similarities with the devastating Log4Shell attack in Log4j, another vulnerable dependency that is still being exploited almost two years later.
>>> Test your knowledge right now with our curl Mission!
The vulnerability: Buffer Overflow
The exploit is detailed under CVE-2023-38545, and impacts curl versions 7.69.0 up to and including 8.3.0. The primary bug is a Heap-based Buffer Overflow vulnerability, with initial reports noting that successful exploitation could lead to a more devastating Remote Code Execution (RCE) attack. While this is a possible workflow for a threat actor, it is a rare use case rather than a given.
Perhaps the one saving grace to mitigate some of the risks is that the malicious communication must go through a SOCKS5 proxy, which is a relatively uncommon deployment.
Comparable to the curl exploit, let’s take a look at this Buffer Overflow explainer:
When curl is told to use a SOCKS5 proxy, it will pass on the hostname and have the proxy resolve it. However, if the hostname exceeds the 255 bytes limit, curl will resolve the hostname locally (as seen in the code snippet below: source).
In case there is a slow handshake between the client and proxy, it is possible that the long hostname is copied into the memory buffer instead of the (shorter) resolved address. The allocated memory portion only allows for a 255-byte value, so if it receives a value that exceeds this limit, the data will overflow the memory buffer’s boundaries.
>>> Try it out for yourself in this playable mission!
Buffer Overflow is a powerful attack vector, and one that can be prevalent in a lot of legacy programming languages. In this particular case, exploitation made way for a more serious and damaging attack in the form of RCE in some contexts, though this pathway remains uncommon and unlikely.
How can you mitigate Buffer Overflow risk?
At this stage, the highest priority remediation is to apply the patches to all vulnerable instances, with a reminder that the use of curl is so widespread, it may not necessarily be obvious or advertised that components of your system include the dependency in use. In that case, auditing and subsequent patching are required.
In general, buffer overflow flaws can be mitigated by using a memory-safe language like Rust, however, as is the case with a sprawling project like curl, it isn’t practical to port to another language or rewrite on a whim. As Stenberg notes while discussing the potential to use and support more dependencies written in memory-safe languages - or the alternative of gradually replacing parts of curl piecemeal - “... development is… currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.” It is no small undertaking, and the security implications are immense.
Security mistakes can and will happen, and it’s not always possible to rely on scanners and tests to pick up every possible attack vector. Therefore, our greatest weapon in the fight against these bugs is a commitment to ongoing security awareness and skill-building.
Want to learn more about how to write secure code and mitigate risk?
Try out our Heap Overflow challenge for free.
If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding best practices.
.avif)
curl 라이브러리의 영향을 받는 버전은 SOCKS5 프록시 프로토콜의 기존 문제와 관련된 HEAP 기반 버퍼 오버플로 취약점에 취약합니다.플레이 가능한 미션을 통해 이 취약성 유형을 찾아 해결하는 방법을 알아보세요.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
Just a short time ago, the security and development communities were put on notice with an advisory from the curl Project’s lead developer, Daniel Stenberg, who dropped the unfortunate missive that a new version of curl - distributed October 11 - was released to address two high-impact security vulnerabilities, one of which he describes as "probably the worst curl security flaw in a long time."
A postmortem on Stenberg’s blog noted that affected versions of the curl library are susceptible to a Heap-based buffer overflow vulnerability, related to a legacy issue with the SOCKS5 proxy protocol in use since 2002.
With its usage as a command line tool dating all the way back to 1998, curl is widely regarded as a foundational pillar of the internet. With such a storied history and widespread use, it is a dependency that, if found to be vulnerable, could have ongoing implications for general cyber safety.
This incident shares similarities with the devastating Log4Shell attack in Log4j, another vulnerable dependency that is still being exploited almost two years later.
>>> Test your knowledge right now with our curl Mission!
The vulnerability: Buffer Overflow
The exploit is detailed under CVE-2023-38545, and impacts curl versions 7.69.0 up to and including 8.3.0. The primary bug is a Heap-based Buffer Overflow vulnerability, with initial reports noting that successful exploitation could lead to a more devastating Remote Code Execution (RCE) attack. While this is a possible workflow for a threat actor, it is a rare use case rather than a given.
Perhaps the one saving grace to mitigate some of the risks is that the malicious communication must go through a SOCKS5 proxy, which is a relatively uncommon deployment.
Comparable to the curl exploit, let’s take a look at this Buffer Overflow explainer:
When curl is told to use a SOCKS5 proxy, it will pass on the hostname and have the proxy resolve it. However, if the hostname exceeds the 255 bytes limit, curl will resolve the hostname locally (as seen in the code snippet below: source).
In case there is a slow handshake between the client and proxy, it is possible that the long hostname is copied into the memory buffer instead of the (shorter) resolved address. The allocated memory portion only allows for a 255-byte value, so if it receives a value that exceeds this limit, the data will overflow the memory buffer’s boundaries.
>>> Try it out for yourself in this playable mission!
Buffer Overflow is a powerful attack vector, and one that can be prevalent in a lot of legacy programming languages. In this particular case, exploitation made way for a more serious and damaging attack in the form of RCE in some contexts, though this pathway remains uncommon and unlikely.
How can you mitigate Buffer Overflow risk?
At this stage, the highest priority remediation is to apply the patches to all vulnerable instances, with a reminder that the use of curl is so widespread, it may not necessarily be obvious or advertised that components of your system include the dependency in use. In that case, auditing and subsequent patching are required.
In general, buffer overflow flaws can be mitigated by using a memory-safe language like Rust, however, as is the case with a sprawling project like curl, it isn’t practical to port to another language or rewrite on a whim. As Stenberg notes while discussing the potential to use and support more dependencies written in memory-safe languages - or the alternative of gradually replacing parts of curl piecemeal - “... development is… currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.” It is no small undertaking, and the security implications are immense.
Security mistakes can and will happen, and it’s not always possible to rely on scanners and tests to pick up every possible attack vector. Therefore, our greatest weapon in the fight against these bugs is a commitment to ongoing security awareness and skill-building.
Want to learn more about how to write secure code and mitigate risk?
Try out our Heap Overflow challenge for free.
If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding best practices.
Just a short time ago, the security and development communities were put on notice with an advisory from the curl Project’s lead developer, Daniel Stenberg, who dropped the unfortunate missive that a new version of curl - distributed October 11 - was released to address two high-impact security vulnerabilities, one of which he describes as "probably the worst curl security flaw in a long time."
A postmortem on Stenberg’s blog noted that affected versions of the curl library are susceptible to a Heap-based buffer overflow vulnerability, related to a legacy issue with the SOCKS5 proxy protocol in use since 2002.
With its usage as a command line tool dating all the way back to 1998, curl is widely regarded as a foundational pillar of the internet. With such a storied history and widespread use, it is a dependency that, if found to be vulnerable, could have ongoing implications for general cyber safety.
This incident shares similarities with the devastating Log4Shell attack in Log4j, another vulnerable dependency that is still being exploited almost two years later.
>>> Test your knowledge right now with our curl Mission!
The vulnerability: Buffer Overflow
The exploit is detailed under CVE-2023-38545, and impacts curl versions 7.69.0 up to and including 8.3.0. The primary bug is a Heap-based Buffer Overflow vulnerability, with initial reports noting that successful exploitation could lead to a more devastating Remote Code Execution (RCE) attack. While this is a possible workflow for a threat actor, it is a rare use case rather than a given.
Perhaps the one saving grace to mitigate some of the risks is that the malicious communication must go through a SOCKS5 proxy, which is a relatively uncommon deployment.
Comparable to the curl exploit, let’s take a look at this Buffer Overflow explainer:
When curl is told to use a SOCKS5 proxy, it will pass on the hostname and have the proxy resolve it. However, if the hostname exceeds the 255 bytes limit, curl will resolve the hostname locally (as seen in the code snippet below: source).
In case there is a slow handshake between the client and proxy, it is possible that the long hostname is copied into the memory buffer instead of the (shorter) resolved address. The allocated memory portion only allows for a 255-byte value, so if it receives a value that exceeds this limit, the data will overflow the memory buffer’s boundaries.
>>> Try it out for yourself in this playable mission!
Buffer Overflow is a powerful attack vector, and one that can be prevalent in a lot of legacy programming languages. In this particular case, exploitation made way for a more serious and damaging attack in the form of RCE in some contexts, though this pathway remains uncommon and unlikely.
How can you mitigate Buffer Overflow risk?
At this stage, the highest priority remediation is to apply the patches to all vulnerable instances, with a reminder that the use of curl is so widespread, it may not necessarily be obvious or advertised that components of your system include the dependency in use. In that case, auditing and subsequent patching are required.
In general, buffer overflow flaws can be mitigated by using a memory-safe language like Rust, however, as is the case with a sprawling project like curl, it isn’t practical to port to another language or rewrite on a whim. As Stenberg notes while discussing the potential to use and support more dependencies written in memory-safe languages - or the alternative of gradually replacing parts of curl piecemeal - “... development is… currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.” It is no small undertaking, and the security implications are immense.
Security mistakes can and will happen, and it’s not always possible to rely on scanners and tests to pick up every possible attack vector. Therefore, our greatest weapon in the fight against these bugs is a commitment to ongoing security awareness and skill-building.
Want to learn more about how to write secure code and mitigate risk?
Try out our Heap Overflow challenge for free.
If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding best practices.
아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
Just a short time ago, the security and development communities were put on notice with an advisory from the curl Project’s lead developer, Daniel Stenberg, who dropped the unfortunate missive that a new version of curl - distributed October 11 - was released to address two high-impact security vulnerabilities, one of which he describes as "probably the worst curl security flaw in a long time."
A postmortem on Stenberg’s blog noted that affected versions of the curl library are susceptible to a Heap-based buffer overflow vulnerability, related to a legacy issue with the SOCKS5 proxy protocol in use since 2002.
With its usage as a command line tool dating all the way back to 1998, curl is widely regarded as a foundational pillar of the internet. With such a storied history and widespread use, it is a dependency that, if found to be vulnerable, could have ongoing implications for general cyber safety.
This incident shares similarities with the devastating Log4Shell attack in Log4j, another vulnerable dependency that is still being exploited almost two years later.
>>> Test your knowledge right now with our curl Mission!
The vulnerability: Buffer Overflow
The exploit is detailed under CVE-2023-38545, and impacts curl versions 7.69.0 up to and including 8.3.0. The primary bug is a Heap-based Buffer Overflow vulnerability, with initial reports noting that successful exploitation could lead to a more devastating Remote Code Execution (RCE) attack. While this is a possible workflow for a threat actor, it is a rare use case rather than a given.
Perhaps the one saving grace to mitigate some of the risks is that the malicious communication must go through a SOCKS5 proxy, which is a relatively uncommon deployment.
Comparable to the curl exploit, let’s take a look at this Buffer Overflow explainer:
When curl is told to use a SOCKS5 proxy, it will pass on the hostname and have the proxy resolve it. However, if the hostname exceeds the 255 bytes limit, curl will resolve the hostname locally (as seen in the code snippet below: source).
In case there is a slow handshake between the client and proxy, it is possible that the long hostname is copied into the memory buffer instead of the (shorter) resolved address. The allocated memory portion only allows for a 255-byte value, so if it receives a value that exceeds this limit, the data will overflow the memory buffer’s boundaries.
>>> Try it out for yourself in this playable mission!
Buffer Overflow is a powerful attack vector, and one that can be prevalent in a lot of legacy programming languages. In this particular case, exploitation made way for a more serious and damaging attack in the form of RCE in some contexts, though this pathway remains uncommon and unlikely.
How can you mitigate Buffer Overflow risk?
At this stage, the highest priority remediation is to apply the patches to all vulnerable instances, with a reminder that the use of curl is so widespread, it may not necessarily be obvious or advertised that components of your system include the dependency in use. In that case, auditing and subsequent patching are required.
In general, buffer overflow flaws can be mitigated by using a memory-safe language like Rust, however, as is the case with a sprawling project like curl, it isn’t practical to port to another language or rewrite on a whim. As Stenberg notes while discussing the potential to use and support more dependencies written in memory-safe languages - or the alternative of gradually replacing parts of curl piecemeal - “... development is… currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.” It is no small undertaking, and the security implications are immense.
Security mistakes can and will happen, and it’s not always possible to rely on scanners and tests to pick up every possible attack vector. Therefore, our greatest weapon in the fight against these bugs is a commitment to ongoing security awareness and skill-building.
Want to learn more about how to write secure code and mitigate risk?
Try out our Heap Overflow challenge for free.
If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding best practices.
시작하는 데 도움이 되는 리소스
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
