5 ms·

I have the feeling that this is gonna be way bigger than the log4j mess.

by fer 3y ago

technion 3y ago
For the most part it's not common to be able to make a server call curl with an arbitrary server which is usually required to exploit this sort of thing. There will be some vulnerable apps, but the vast majority of servers with this vulnerability present won't be exploitable in any practical sense.
- tyingq 3y ago
  I agree at a high level, but there are spaces where it would be common. CI/CD servers as one example. Or any wordpress server.
- worksonmine 3y ago
  You have to consider the author of curl has recently been vocal against CVE scoring for vulnerabilities that require very specific conditions or user stupidity to trigger. For him to come out with "the one rated HIGH is probably the worst curl security flaw in a long time" most likely means it's bad.
- fer 3y ago
  Sure. Or you can get an RCE on a car[0] after some bitsquatting[1]. [0] https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-my-car/ https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-... [1] https://en.wikipedia.org/wiki/Bitsquatting https://en.wikipedia.org/wiki/Bitsquatting
  - dzhiurgis 3y ago
    Cars entertainment system, not car itself
filleokus 3y ago
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.
- gnyman 3y 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.

I have the feeling that this is gonna be way bigger than the log4j mess.

by fer 3y ago

I have the feeling that this is gonna be way bigger than the log4j mess.

For the most part it's not common to be able to make a server call curl with an arbitrary server which is usually required to exploit this sort of thing. There will be some vulnerable apps, but the vast majority of servers with this vulnerability present won't be exploitable in any practical sense.

tyingq 3y ago
I agree at a high level, but there are spaces where it would be common. CI/CD servers as one example. Or any wordpress server.
worksonmine 3y ago
You have to consider the author of curl has recently been vocal against CVE scoring for vulnerabilities that require very specific conditions or user stupidity to trigger. For him to come out with "the one rated HIGH is probably the worst curl security flaw in a long time" most likely means it's bad.
fer 3y ago
Sure. Or you can get an RCE on a car[0] after some bitsquatting[1]. [0] https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-my-car/ https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-... [1] https://en.wikipedia.org/wiki/Bitsquatting https://en.wikipedia.org/wiki/Bitsquatting
- dzhiurgis 3y ago
  Cars entertainment system, not car itself

filleokus 3y ago

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.

gnyman 3y 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.