Join Our Popular Newsletter
Join 4,500+ Linux & Open Source Professionals!
2x a month. No spam.
20 year old vulnerability in libcurl publicly disclosed CVE-2021-22876
At what point does an old vulnerability go from being a bug to becoming a feature? That is the question probably going through the mind of many software developers who use libcurl as part of their applications, as a bug was discovered in code committed in August of 2000 to the libcurl code base.
The disclosed vulnerability allows a specially configured web server to have access to credentials entered in a different web server, through improper behavior in libcurl.
According to available information, this affects curl/libcurl 7.1.1 up to and including 7.75.0. Version 7.76.0+ includes the fix.
This vulnerability affects curl/libcurl as distributed in Centos 6, Ubuntu 16.04 and Oracle EL6 (other older distributions probably have the affected versions as well). Original vendor support has provided patches for Ubuntu, and through our Extended Lifecycle Support service we will be providing patches for CentOS 6 starting later today. Other systems supported through our Extended Lifecycle Support service will also receive patches shortly if original vendors do not do so.
Succinctly, libcurl is a library that contains commonly used functions to access web sites, perform http requests and data transfer. It is used implicitly in “curl”, the venerable tool bundled with most Linux distributions, and also in many, many other tools and third party applications, sometimes even without proper attribution. You’re probably using it in some form through common web browsers, file transfer tools or email programs right now.
The affected behavior can be described as follows:
- A user performs a web request to a site that requires authentication
- User enters credentials normally
- Web server then redirects the request to a secondary server actually serving the requested content
- At this point, the secondary server receives the credentials in a header sent by libcurl that should not contain them, because the second server has no right to see this information.
Note that this can, and does, happens transparently to the end user after the initial credential request by an application. CVE-2021-22876 contains detailed information about this problem.
Also, because this behavior has been in the library for so long, there are probably web hosting environments and applications that depend on it performing as it is for their correct operation. IT teams should run any compliance testing appropriate for their web hosting environment to validate correct behavior of their servers without receiving this header with credentials in their secondary servers.
Disclaimer: Irrespective of the date, this is -not- an April 1st joke. There really is a 20 year old flaw in libcurl.