I think this vulnerability is getting a lot of recognition because of how ubiquitous the disdain is for these kinds of “features”. Every post I see repeats how plainly bad this idea is. I couldn’t imagine letting anything like this through a code review.
My job is in the Minecraft modding space and we were notified of the issue immediately. I maintain our platform that boots Minecraft so I was coincidentally one of the first people to patch it. My “patch” being, like with most vulnerabilities of this caliber, ripping out the bad code completely. I think that was a much better patch than the original one for 2.15.0 (which I saw in 2.15.0-rc2, the latest rc tagged on GitHub, when the vulnerability dropped) and better than the additional mitigations for 2.16.0. No way I’m letting a logger have network access, or even code that could access a network.
JNDI is a Java API abstraction over any kind of lookup services (DNS, LDAP, Consul etc.). The ticket authors wanted to look up certain parts of the logging config from such a service. I don’t think it’s so impossible to imagine how such functionality would be desired to quickly tweak a certain logging parameter across multiple microservices, for example. But yes, enabling it by default was a really bad choice.
The title is clickbait (by Ars), specifically the “has its own vulnerability” part. The correct statement is was that “[the 2.15.0 mitigation] was incomplete in certain non-default configurations”. The CVE description opens early with the following statement “[…] this could allows attackers with control over Thread Context Map[…]” which is rather uncommon. Some projects I am keeping an eye on refused to go into an all-hands-on-deck mode again to upgrade from 2.15.0 to 2.16.0 because they are not vulnerable to this and this CVE is much harder to exploit. And as far as I understand, this problem was not brought in by the CVE fix in 2.15.0, that’s why the title is clickbait. Oh maaaan, see a reply from @crazyloglad.
The original CVE had a score 10/10. The CVE in question has a score 3.7/10 9/10 (but it’s being revised now).
Well it was kindof fresh off the presses :-)
The 2.16 has a supposed DoS that is not patched, let’s see how long it takes for that to become something more.
I think this vulnerability is getting a lot of recognition because of how ubiquitous the disdain is for these kinds of “features”. Every post I see repeats how plainly bad this idea is. I couldn’t imagine letting anything like this through a code review.
My job is in the Minecraft modding space and we were notified of the issue immediately. I maintain our platform that boots Minecraft so I was coincidentally one of the first people to patch it. My “patch” being, like with most vulnerabilities of this caliber, ripping out the bad code completely. I think that was a much better patch than the original one for 2.15.0 (which I saw in 2.15.0-rc2, the latest rc tagged on GitHub, when the vulnerability dropped) and better than the additional mitigations for 2.16.0. No way I’m letting a logger have network access, or even code that could access a network.
What features are you talking about? Asking because I don’t program in Java so don’t know.
https://issues.apache.org/jira/browse/LOG4J2-313 is the original ticket.
JNDI is a Java API abstraction over any kind of lookup services (DNS, LDAP, Consul etc.). The ticket authors wanted to look up certain parts of the logging config from such a service. I don’t think it’s so impossible to imagine how such functionality would be desired to quickly tweak a certain logging parameter across multiple microservices, for example. But yes, enabling it by default was a really bad choice.
Oh no, the anti-patch memes are coming true!
Anti-patchers were right all along??
Ha!
The title is clickbait (by Ars), specifically the “has its own vulnerability” part. The correct statement
iswas that “[the 2.15.0 mitigation] was incomplete in certain non-default configurations”. The CVE description opens early with the following statement “[…] this could allows attackers with control over Thread Context Map[…]” which is rather uncommon. Some projects I am keeping an eye on refused to go into an all-hands-on-deck mode again to upgrade from 2.15.0 to 2.16.0 because they are not vulnerable to this and this CVE is much harder to exploit.And as far as I understand, this problem was not brought in by the CVE fix in 2.15.0, that’s why the title is clickbait.Oh maaaan, see a reply from @crazyloglad.The original CVE had a score 10/10. The CVE in question has a score
3.7/109/10 (but it’s being revised now).https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/#update-the-localhost-bypass-was-discovered
Thank you for calling out my ignorance. I have submitted a new story with a link to the log4j 2.16.0 release summary and a clear description of the CVEs and their scores involved: https://lobste.rs/s/hmkj2q/log4j_2_15_0_has_rce_with_cvss_score_9_0
Well it was kindof fresh off the presses :-) The 2.16 has a supposed DoS that is not patched, let’s see how long it takes for that to become something more.
DoS apparently fixed in 2.17: https://logging.apache.org/log4j/2.x/security.html