The curl security-team's response to the curl security audit remarks December 2022

audit-response.md

Proxy credentials are cached without encryption (TOB-CURLTM-1)

The subject was brought up for discussion on the mailing list: https://curl.se/mail/lib-2022-09/0149.html - no actual changes for this have been made.

Lack of support for MQTT over TLS (TOB-CURLTM-2)

This remains an outstanding TODO. MQTT is a little used protocol in curl and this (MQTT over TLS) has not appeared much as a wanted feature.

No warnings when TLS connection attempts fail with the --ssl flag (TOB-CURLTM-3)

curl now outputs a warning, and a warning was added to the man page for the option: curl/curl#9519

Contributing guidelines lack recommendations against using insecure C functions (TOB-CURLTM-4)

The curl team has not accepted that this would add much value. Contributors mostly don’t read such documents before contributing. Banned functions should be rejected by tools. Use of non-banned functions should be verified by human code reviews, tests and static code analyzers.

cURL treats localhost as secure by default (TOB-CURLTM-5)

curl considers localhost to be “secure” in some contexts. This is done on purpose to match how other popular cookie using HTTP clients/browsers work. Documentation update: curl/curl#9938

It does not “skip” name resolution checks because it is “secure”, it hardcodes localhost as local addresses in order to make sure it is actually secure, i.e. done on the local host via loopback only.

Insufficient input validation strategy (TOB-CURLTM-6)

The curl team cannot fully accept the recommendations here. We consider it our expertise to work out how to deal with protocols and the parsing of their components. This, combined with history, legacy and our strong commitment to keep existing behaviors has led to the decisions and existing code we use. We should always be as strict as possible and we should test all parsers thoroughly, including with fuzzers.

The issue mentioned with TAB was not a parsing problem, but a file storage problem, as TABs are allowed in cookies. Expanded in this blog post: https://daniel.haxx.se/blog/2022/10/14/there-is-a-tab-in-my-cookie/

Lack of documentation on supported protocol features and RFC compliance (TOB-CURLTM-7)

We document all features we support in depth,with details and with examples. We do not and cannot document “RFC compliance”, and neither does any competitor, similar tools or other network libraries or browsers. Because it simply is not possible. The amount of RFCs is too large, the number of conflicting documents are numerous and interoperability across the Internet trumps all of that.

Expanded more in this blog post: https://daniel.haxx.se/blog/2022/10/18/deviating-from-specs/

Bad recommendation in libcurl cookie documentation (TOB-CURL-1)

Fixed in curl/curl#9654

libcurl URI parser accepts invalid characters (TOB-CURL-2)

Fixed in curl/curl#9608 (and later amended somewhat more)

libcurl Alt-Svc parser accepts invalid port numbers (TOB-CURL-3)

Fixed in curl/curl#9607 (and later amended somewhat more)

Non-constant-time comparison of secrets (TOB-CURL-4)

Fixed in curl/curl#9658

Tab injection in cookie file (TOB-CURL-5)

Fixed in curl/curl#9659

Standard output/input/error may not be opened (TOB-CURL-6)

Fixed in curl/curl#9663 (with a follow-up fix in curl/curl#9708)

Double free when using HTTP proxy with specific protocols (TOB-CURL-7)

Filed as a CVE: https://curl.se/docs/CVE-2022-42915.html

Some flags override previous instances of themselves (TOB-CURL-8)

This is by design. We incorporated a change that makes it mandatory for the documentation to mention how curl deals with multi-use of options: Fixed in curl/curl#9759

Cookies are not stripped after redirect (TOB-CURL-9)

This is by design and we do not see a way to change this behavior without breaking behavior for existing users. This is also not the typical way users use cookies with curl so those who do provide cookies like this usually do it in special crafted ways. This behavior is also documented in the man page for the --cookie option.

Use after free while using parallel option and sequences (TOB-CURL-10)

Fixed in curl/curl#9729

Memory leaks (TOB-CURL-11)

Fixed in curl/curl#9749 (and later amended somewhat more)

Referer header is generated in insecure manner (TOB-CURL-12)

This topic was brought to the mailing list https://curl.se/mail/lib-2022-10/0039.html but no real desire in changing the default behavior was picked up, rather the opposite. This is a function that is rarely used, so presumably users that do not want this way of working will and should not enable it.

Redirect to localhost and local network is possible (Server-side request forgery like) (TOB-CURL-13)

This is working as intended and I do not see how adding a warning here will help anyone or anything. The option asks curl to follow a redirect and there is nothing that says or indicates that it would not follow a redirect to certain hosts or host names. Of course it will also follow redirects to “local” host names, for any definition of local.

The built-in redirect-following is not meant to be the way that covers all possible ways to do redirects for all users in all situations. If users need more control and more say in how redirects are done, curl and libcurl provide the means to let users follow them themselves. curl does not follow any redirects by default.

URL parsing from redirect is incorrect when no path separator is provided (TOB-CURL-14)

Fixed in curl/curl#9763