Some thoughts on why the #curl #CVE202338545 #vulnerability likely is worse than you might initially think:

• The heap memory being overwritten might contain string(s) that end up (in)directly executed by shell if system() or similar functions are used by the application on heap-based strings. This could allow trivial RCE in certain scenarios, especially if you can have nearly unlimited attempts to “get lucky” with the heap arrangement, or can massage the heap in a way to make it more likely to get suitable arrangement. Whether a specific app is susceptible for this can’t easily be determined without analyzing each app in the environment they’re used in.

• Tor users might be at risk, if they’re using curl or libcurl based application with the Tor proxy as the communication with the proxy is commonly using the affected socks5h:// protocol. This risk could manifest itself in several ways: First in the abovementioned RCE threat might allow code execution. Secondly, if the heap memory overwritten will be included in other remote network request (for example part of headers, POST body or similar), it could allow “tagging” Tor users and potentially deanonymize them.

• Thinking that HTTPS will keep you safe is a fallacy. Countless of untrusted sites are accessed over HTTPS (easy example is forums or sites where other users can contribute to).

Curl/libcurl has a very large install base with wide range of use cases. Just because your use cases aren’t affected doesn’t mean the vulnerability can be dismissed as non-issue. #infosec #threatmodeling