#curl 8.9.0 is out: https://daniel.haxx.se/blog/2024/07/24/curl-8-9-0/
2 CVEs fixed
11 changes
260 bugfixes
by 80 contributors, out of which 47 authored commits
in 63 days since the previous release
This website is tracked using the Matomo analytics tool. If you do not want that your visits are logged in this way you can set a cookie to prevent Matomo / Piwik from tracking further visits of the site (opt-out).
daniel:// stenberg://
in reply to daniel:// stenberg:// • • •CVE-2024-6197: freeing stack buffer in utf8asn1str. (severity medium) libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. It can detect an invalid field and return error. Unfortunately, when doing so it also invokes free() on a 4 byte local stack buffer.
https://curl.se/docs/CVE-2024-6197.html
curl - freeing stack buffer in utf8asn1str - CVE-2024-6197
curl.sedaniel:// stenberg://
in reply to daniel:// stenberg:// • • •CVE-2024-6874: macidn punycode buffer overread. (severity low) libcurl’s URL API function curl_url_get() offers punycode conversions, to and from IDN. Asking to convert a name that is exactly 256 bytes, libcurl ends up reading outside of a stack based buffer when built to use the macidn IDN backend. The conversion function then fills up the provided buffer exactly – but does not null terminate the string.
https://curl.se/docs/CVE-2024-6874.html
curl - macidn punycode buffer overread - CVE-2024-6874
curl.sedaniel:// stenberg://
in reply to daniel:// stenberg:// • • •curlhacker - Twitch
Twitchdaniel:// stenberg://
in reply to daniel:// stenberg:// • • •curl disclosed on HackerOne: CVE-2024-6874: macidn punycode buffer...
HackerOnedaniel:// stenberg://
in reply to daniel:// stenberg:// • • •curl disclosed on HackerOne: CVE-2024-6197: freeing stack buffer in...
HackerOneDov Murik
in reply to daniel:// stenberg:// • • •I'm curious about this bug. From the description it seems that any time that free(buf) was called, the process will crash. So if it hasn't occurred in curl CI tests, we should see this line was not covered (assuming we have some coverage reports). I don't think that 100% coverage is a must, but maybe we can look at uncovered lines for sensitive operations?
(Thank you for all your work on curl. It's awesome.)
daniel:// stenberg://
in reply to Dov Murik • • •@dubek many libc versions actually just refuse it, most cases will crash but there can be cases where it does more harm.
The line was (quite obviously) not reached in our tests and yes it would be awesome if it did. We'd welcome help to increase test coverage.
Test coverage in highly portable code with billions of build combinations is a challenge.
Jim Fuller
in reply to daniel:// stenberg:// • • •daniel:// stenberg:// reshared this.