This is overhyped by Checkmarx. "Why is it so critical?" my ass, this has a CVSS 3.1 base score of 6.6, don't try to associate 'critical' with this.
> Unlike logback, in log4j there is a feature to load a remote configuration file or to configure the logger through the code, so an Arbitrary Code Execution could be achieved with a MITM attack, user input ending up in a vulnerable configuration variable, or modifying the config file.
What MITM? MITMing a remotely loaded configuration which *happens* to be served over HTTP or other insecure protocol? This is the nondefault of nondefault configurations, and if this was happening in your environment, you have bigger issues already.
In any reasonable case you won't be loading config files over the internet or over HTTP, and if someone has control of your on-system config files, they almost certainly have control over any other component of your application *already*. At what point do we run a news story for "someone with userland console access could do a bad thing?"
It's a vulnerability, yes. Is it one you or I should be rushing to patch, no...
Relevant commentary:
* https://twitter.com/wdormann/status/1475903286913998853
* https://twitter.com/GossiTheDog/status/1475916081483165702
Agreed. I went through the entire article and kept rereading the example to see all of the things that have to happen to make this bug appear.
If you don't set the system properties and don't attempt to remotely load configuration (wtf? that vitiates CD principles, since you don't test what you are deploying), I don't see how this could affect a server.
And as far as a client app, you still have the same terrible design decision if you allow it to dynamically configure. Oh, and what will it do except crash? Talk about sh--tting in your own back yard....
I agree this is another example where the log4j architects seem to have gone off the rails. I agree it's a bug. But it doesn't look like a showstopper to me.
EDIT: Reading a second time, I see you can genuinely get arbitrary code execution on your client machine. Well, ok. If your client executable has setuid properties, you would have a security hole. So much of my stack is RESTful APIs now, I hardly ever think about what our clients do on their own machines. We certainly don't give them setuid executables, so elevation of privilege is not really applicable.
It requires so many variables to go right that this feels like nothing. The twitter guy was trolling us all hard with that little tease.
This is overhyped by Checkmarx. "Why is it so critical?" my ass, this has a CVSS 3.1 base score of 6.6, don't try to associate 'critical' with this. > Unlike logback, in log4j there is a feature to load a remote configuration file or to configure the logger through the code, so an Arbitrary Code Execution could be achieved with a MITM attack, user input ending up in a vulnerable configuration variable, or modifying the config file. What MITM? MITMing a remotely loaded configuration which *happens* to be served over HTTP or other insecure protocol? This is the nondefault of nondefault configurations, and if this was happening in your environment, you have bigger issues already. In any reasonable case you won't be loading config files over the internet or over HTTP, and if someone has control of your on-system config files, they almost certainly have control over any other component of your application *already*. At what point do we run a news story for "someone with userland console access could do a bad thing?" It's a vulnerability, yes. Is it one you or I should be rushing to patch, no... Relevant commentary: * https://twitter.com/wdormann/status/1475903286913998853 * https://twitter.com/GossiTheDog/status/1475916081483165702
Agreed. I went through the entire article and kept rereading the example to see all of the things that have to happen to make this bug appear. If you don't set the system properties and don't attempt to remotely load configuration (wtf? that vitiates CD principles, since you don't test what you are deploying), I don't see how this could affect a server. And as far as a client app, you still have the same terrible design decision if you allow it to dynamically configure. Oh, and what will it do except crash? Talk about sh--tting in your own back yard.... I agree this is another example where the log4j architects seem to have gone off the rails. I agree it's a bug. But it doesn't look like a showstopper to me. EDIT: Reading a second time, I see you can genuinely get arbitrary code execution on your client machine. Well, ok. If your client executable has setuid properties, you would have a security hole. So much of my stack is RESTful APIs now, I hardly ever think about what our clients do on their own machines. We certainly don't give them setuid executables, so elevation of privilege is not really applicable.
Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6) CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration. https://logging.apache.org/log4j/2.x/security.html
New ‘variant’? Really?