Internet Bug Bounty · Report #1551588
CVE-2022-27775: Bad local IPv6 connection reuse
Summary
Curl Advisory: Bad local IPv6 connection reuse Project curl Security Advisory, April 27 2022
VULNERABILITY libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse, if one of them matches the setup.
Due to errors in the logic, the config matching function did not take the IPv6 address zone id into account which could lead to libcurl reusing the wrong connection when one transfer uses a zone id and a subsequent transfer uses another (or no) zone id.
We are not aware of any exploit of this flaw.
INFO Zone ids are only used for non-global scoped IPv6 addresses and they are only used when specifying the address numerically.
This flaw has existed in curl since commit 2d0e9b40d3237b1, shipped in libcurl 7.65.0, released on May 22 2019. Previous versions will instead not accept URLs with zone ids.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2022-27775 to this issue.
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Severity: Low
AFFECTED VERSIONS Affected versions: curl 7.65.0 to and including 7.82.0 Not affected versions: curl < 7.65.0 and curl >= 7.83.0 Also note that libcurl is used by many applications, and not always advertised as such.
THE SOLUTION A fix for CVE-2022-27775
RECOMMENDATIONS A - Upgrade curl to version 7.83.0 B - Apply the patch to your local version C - Do not use non-global numerical IPv6 addresses in URLs to curl
TIMELINE This issue was reported to the curl project on April 21, 2022. We contacted distros@openwall on April 21. libcurl 7.83.0 was released on April 27 2022, coordinated with the publication of this advisory.
CREDITS This issue was reported by Harry Sintonen. Patched by Daniel Stenberg. Thanks a lot!
How it was found
Summary:
curl/libcurl doesn't consider IPv6 address zone index when doing connection reuse. if connection exists to specific IPv6 address (and other conditions for connection reuse are fulfilled) it will be reused for connections regardless of the zone index.
Steps To Reproduce:
- Set up a fake server:
echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nHello\n' | nc -6 -v -l -p 9999 - curl "http://[ipv6addr]:9999/x" "http://[ipv6addr%25lo]:9999/y"
Both connections arrive to the test server:
Listening on :: 9999
Connection received on somehost someport
GET /x HTTP/1.1
Host: [ipv6addr]:9999
User-Agent: curl/7.83.0-DEV
Accept: */*
GET /y HTTP/1.1
Host: [ipv6addr]:9999
User-Agent: curl/7.83.0-DEV
Accept: */*
Clearly the 2nd connection should fail as the address is not available at interface lo. (Lone connection to http://[ipv6addr%25lo]:9999/ fails with curl: (7) Couldn't connect to server)
This vulnerability isn't exploitable with public IPv6 addresses on linux systems (it seems kernel strips out zone index for public addresses). It is exploitable with macOS however, and possibly other non-linux OSes.
Impact
Reuse of wrong connection leading to potential disclosure of confidential information.