Ouch! Percentage of internet of things devices who don't ship libcurl is a rounding error. Percentage of internet of things devices that patch libcurl is also a rounding error.
So the vulnerable systems are those where an attacker can craft an endpoint where curl downloads data?
Isn’t the lucky circumstance here that most systems with libcurl don’t use it and among those who do, an even tinier subset will allow an attacker to point it anywhere (e.g downloads from an url the attacker decides)?
So a victim behind a hostile AP might be redirected to a malicious site masquerading as a known legit site and when the bad site presents a maliciously crafted bogus certificate curl doesn't notice.
[0] https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-...
That would mean that someone in a MITM position would be able to inject the payload when libcurl make requests.
But even that seems less messy than log4j? It can't possibly be as common that libcurl makes connections to arbitrary user entered urls, compared to log4j logging user entered text.
That's a bug class that is quite common but rarely leads to code exec or other issues (except in some cloud environments). If this is something that gives code exec after pointing curl at a malicious server it's going to be bad.
- a library which can be linked to the application, i.e. one doesn't need to do the expensive fork()/exec[v[p[e]]]() dance and
- documentation: most cloud services offer examples using curl for their API. It takes some additional mental work to translate those into wget syntax.