Search

Items tagged with: CURL


Screenshot from the #curl website dated December 1998. "massive popularity" ...
#curl


Coming in November. Following up my previous monster video on #curl: the corresponding version for #libcurl: "mastering libcurl"

The exact date is not set yet because man, this takes work and I'm only about half way.


#curl


#curl


Assassin's Creed Mirage ❤️ #curl (thanks to Patrik Svensson)
#curl


Attempt 1. What happens when you invoke #curl. In a single picture.
#curl


New plot added to old graph. Number of lines of code in the #curl tool. From 3,400 lines back in 2000 when libcurl was created, to 22,800 lines now.
#curl


#curl


in the #curl project, we have already done more commits in 2023 than any single previous year since 2014. If we manage 152 more commits this year, 2023 will become the most-commits year since 2004, which remains our top year with 2102 commits in a single year.

Things you figure out when you have graphs.

#curl


#curl


#curl


#curl


TBH that kinda matches the description.

After all, your work on #wolfSSL and #curl is something noone outside of the know even is aware of but millions pf people if not billions of devices rely on daily...

Really like that XKCD dependency stack...





#curl


#curl


this is a key step towards getting HTTP/3 support in #curl by default and not experimental...
#curl


#curl


#curl


#curl bug-bounty award amounts, after the two most recent ones. Accumulated 68,320 USD now. The new curl record payout was 4660 USD for CVE-2023-38545.
#curl


#curl




This week many engineering teams are looking for the immensely popular open source library 'curl' in order to get ahead of the CVE-2023-38545 vulnerability. Most of them are NOT going to see it in their SBOM even though they use it.

In this article I walk through why this is, places it might be hiding and questions to ask that can help uncover your use of it.

zebracatzebra.com/oss/curl-is-… #curl #sca #sbom



#curl runs in all your devices (oct 2023 edition)
#curl


#curl


#curl


#curl


#curl


Why did the #curl #CVE202338545 vulnerability hide from static analysis tools?

The main reason for this is the type of code structure in question. In general state engines are quite difficult for static analysis tools, since as the name implies the state of the various variables depend on runtime state changes.

The code attempts to determine whether it is safe to use the provided host name for remote resolution. Since the code does not function correctly with host names longer than 255 characters, it falls back to using “socks5://” protocol (local name resolution) if the host name is longer. When the name is too long, the code forces “local name resolution” by setting “socks5_resolve_local” variable to TRUE.

Unfortunately this “socks5_resolve_local” variable isn’t stored in the “socks_state” structure as it should have been. For each state “step” the initial value for the variable is determined with:

bool socks5_resolve_local =
(conn->socks_proxy.proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;

The INIT state then set the “socks5_resolve_local” to TRUE if the host name is too long:

/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */
if(!socks5_resolve_local && hostname_len > 255) {
infof(data, "SOCKS5: server resolving disabled for hostnames of "
"length > 255 [actual len=%zu]", hostname_len);
socks5_resolve_local = TRUE;
}

But this check is *only* done in INIT state. When the state is anything else, the initial value is used.

Now, later CONNECT_RESOLVE_REMOTE state checks if remote name resolution should be used or not:

if(!socks5_resolve_local) {
if (… sx->hostname is literal IPv6 address …) {
… use ipv6 address direct …
}
else if (… sx->hostname is literal IPv4 address …) {
… use ipv4 address direct …
}
else {
socksreq[len++] = 3;
socksreq[len++] = (char) hostname_len; /* one byte address length */
memcpy(&socksreq[len], sx->hostname, hostname_len); /* w/o NULL */
len += hostname_len;
}
}
As “socks5_resolve_local” flag is FALSE for the excessively long hostname the “socksreq” heap buffer will be overflown by the memcpy call.

There is no obvious way for the static analysis tools to determine that “socks5_resolve_local” might be set incorrectly for some of the states. Runtime #fuzzing will find this flaw quite easily, but unfortunately no fuzzing was performed for this specific functionality.

#vulnerability #staticanalysis #infosec


I'll get the stream up at twitch.tv/curlhacker in a few minutes and do the #curl release presentation there at the top of the hour.
#curl