undefined | Better HN

0 pointsfilleokus2y ago0 comments

Hmm. The worst case I can think of is if the vulnerability is exploitable before (or during) verification of TLS certificates for http(s).

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.

0 comments

gnyman2y ago

I thought so at first but then I remembered server side request forgery, SSRF

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.

j / k navigate · click thread line to collapse

0 pointsfilleokus2y ago0 comments

Hmm. The worst case I can think of is if the vulnerability is exploitable before (or during) verification of TLS certificates for http(s).

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.

0 comments

gnyman2y ago

I thought so at first but then I remembered server side request forgery, SSRF

j / k navigate · click thread line to collapse