Detection flags jar files with JndiLookup.class removed (but JndiManager.class present)

[leepfrog-ger]

Thanks for the great tool!
I understand that the detection is done by checking for presence of the JndiManager.class in versions 2.1 and up.

However my understanding is that removing JndiLookup.class should be sufficient to mitigate the issue. I know that there is some conflicting information regarding this out there (whether to remove both the lookup and the manager class or only the lookup), but based on the official communication by apache removing the JndiLookup.class should be sufficient:

Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046

Is there any concrete information out there that JndiManager.class really needs to be removed too? If not it could make sense to change the detection to be based on the Lookup's class presence for accurate results

[sirmb123]

You probably meant Is there any concrete information out there that manager really needs to be removed too?

[leepfrog-ger]

You probably meant Is there any concrete information out there that manager really needs to be removed too?

Thanks, edited

[sirmb123]

That's a very good question by the way, I'm really looking forward for the answer.

[hillu]

I suppose we could add back JndiLookup.class hashes…

[dracoqcca]

I suppose we could add back JndiLookup.class hashes…

What we want to know if if you have any sources that JdniManager.class is vulnerable or not? I have try to find it myself and didn't find any sign of it. Thanks for what you have done though really appreciate it.

[hillu]

I think that my original assumption around JndiManager was based on the fact that JndiManager.java had been patched for 2.15 while JndiLookup.java had not.

In my attempts at reproducing the vulnerability (including the 127.0.0.1#. workaround)), JAR files with JndiManager.class removed could not be used to reproduce the RCE.

[leepfrog-ger]

Thanks for your feedback. Some vendors rely on the guidance from Apache regarding removing the Lookup class as workaround. So it seems both to be sufficient and also the minimum required deletion. Therefore for our scanning we've added the Lookup classes too so that they are detected and then filtering on the log side to treat everything as not vulnerable that has at least the lookup class missing.

[tkboyle]

Hi Hilko, I'd really like to see a filter against JndiLookup rather than JndiManager as we remediating by removing the JndiLookup.class but on re-run it's still finding a vulnerable version of JndiManager.class.

I've tried to change the hash info in filter.go before building to no avail.
Any help would be greatly appreciated