Curl’s 20-year-old bug is resilient – back for another fix – CVE-2021-22925

Some weeks ago, CVE-2021-22898 was published. It affects curl/libcurl from version 7.7, dating from the 22nd of March 2001. It consisted of a flaw in the way a rarely used option, CURLOPT_TELNETOPTIONS, was parsed which could lead to data exfiltration. At the time, a fix was produced and submitted to the curl/libcurl codebase, and the problem dealt with. That is, until CVE-2021-22925 showed up on the 21st of July. Apparently the initial fix for the previous vulnerability did not correctly address the issue, and so a new fix has been produced.

This issue affects curl version 7.7 up to 7.77.0, which is roughly all curl versions included by default in most Linux distributions for the previous 20 years except for the most recent distribution versions that ship curl 7.78.0 (or higher).

TuxCare’s Extended Lifecycle Support team has prepared and has started to make available the new patch for all affected distributions, namely CloudLinux 6, CentOS 6, OracleLinux 6 and Ubuntu 16.04.

The patch for the previous vulnerability addressed a situation where CURLOPT_TELNETOPTIONS could be abused and made to pass unintended data to the outside of the server. However, it missed a second situation where this could also happen and was, therefore, incomplete.

The new fix addresses both situations by correctly calling sscanf() when processing the strings provided by the calling applications before sending the data to the other end of the connection.

At this time, no exploits are known to exist for this flaw, and the option is very rarely used. But on the other hand, curl and libcurl are used by many applications that do not always announce their use explicitly. So, you shouldn’t simply assume it’s safe to ignore this vulnerability if you don’t directly use this option, as some other application on the system could be doing just that in some background tasks.

As a curious aside, the original vulnerability, CVE-2021-22898, which addressed the same problem in exactly the same code, was correcting code that was, at the time it was disclosed, 20 years and 2 months old. The current one described in this post, because it fixes, again, exactly the same code, is, for all intents and purposes, fixing code that is 20 years and 4 months old. If there were such a contest, they would probably both be contending for “the longest time a vulnerability has been around” prize.

The TuxCare Team remains committed to test and correct all known vulnerabilities on Linux distributions covered by our Extended Lifecycle Support service. You can learn more about this and our other TuxCare services here.