1. 37
  1. 13

    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.

    1. 2

      What features are you talking about? Asking because I don’t program in Java so don’t know.

      1. 3

        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.

      1. 5

        Anti-patchers were right all along??

        1. 1


        2. 1

          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).

            1. 2

              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

              1. 2

                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.

                1. 1