Detection flags jar files with JndiLookup.class removed (but JndiManager.class present) about local-log4j-vuln-scanner

[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