Deep-Dive: Finding and fixing high-severity libcurl/curl vulnerabilities
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)
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. Learn how to find and fix this vulnerability type with a playable mission.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
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.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
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.
Table of contents
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
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 peak of what our content catalog has to offer by topic and role.
Quests: Industry leading learning to keep developers ahead of the game mitigating risk.
Quests is a learning platform that helps developers mitigate software security risks by enhancing their secure coding skills. With curated learning paths, hands-on challenges, and interactive activities, it empowers developers to identify and prevent vulnerabilities.
Resources to get you started
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
The Decade of the Defenders: Secure Code Warrior Turns Ten
Secure Code Warrior's founding team has stayed together, steering the ship through every lesson, triumph, and setback for an entire decade. We’re scaling up and ready to face our next chapter, SCW 2.0, as the leaders in developer risk management.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
