log4j, after running the remove script from KB 87081, there is still a vulnerable jar file found

[jimfa]

after running the remove script from KB 87081, there is still a vulnerable jar file found, 

It's a vcenter server aplliance: VMware VirtualCenter 6.7.0 build-18831049 

python remove_log4j_class.py -r
2021-12-20T16:48:42 INFO main: Running in dryrun mode
2021-12-20T16:48:49 INFO process_archive: Found a VULNERABLE FILE: /usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/316/0/.cp/log4j-core-2.11.2.jar
2021-12-20T16:49:05 INFO main:
===== Summary =====
List of vulnerable files:
/usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/316/0/.cp/log4j-core-2.11.2.jar

===========================
2021-12-20T16:49:05 INFO main: Done.

With our vsca 7.02, this is not the case only with the 6.7 appliances

can anyone help me?

[jimfa · Accepted solution]

Hi all, I think i just resolved it myself, 

i only had this problem with VCSA that i have upgraded from older version, 6.x, my solution:

i made a backup of the jar file and then removed the JndilLookup.class

cp -rfp /usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/322/0/.cp/log4j-core-2.11.2.jar /usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/322/0/.cp/log4j-core-2.11.2.jar.bak

zip -q -d /usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/322/0/.cp/log4j-core-2.11.2.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

i haven't restarted any services yet will do that tomorrow morning.

[SP720]

I ran into the same issue and was told to run the python remove_log4j_class.py script again and that worked and now I have no files listed.

[jimfa]

Hi SP720, 

Thank for your reply,

I did run it many times no change, so i changed the syntax to work for me.

[rgb99]

I have the same issue. I did the cp/zip steps and a service-control --stop --all followed by service-control --start --all and the file still shows up when I run the script in dryrun mode.

root@vcsa [ /tmp ]# python vc_log4j_mitigator.py -r
2021-12-21T18:21:51 INFO main: Script version: 1.6.0
2021-12-21T18:21:51 INFO main: vCenter type: Version: 6.7.0.51000; Build: 18831133; Deployment type: embedded; Gateway: False; VCHA: False; Windows: False;
2021-12-21T18:21:51 INFO main: Running in dryrun mode.
2021-12-21T18:22:51 INFO process_jar: Found a VULNERABLE FILE: /usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/322/0/.cp/log4j-core-2.11.2.jar
2021-12-21T18:23:23 INFO print_summary:
=====     Summary     =====
List of vulnerable java archive files:

/usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/322/0/.cp/log4j-core-2.11.2.jar

List of vulnerable configuration files:

Total found: 1
Log file: /var/log/vmsa-2021-0028_2021_12_21_18_21_51.log
===========================
2021-12-21T18:23:23 INFO main: Done.

[jimfa]

Hi rgb99, 

did you resolve that problem now?

[rgb99]

I rebooted the vCenter Server and re-ran the dryrun. Nothing was found.

[rgb99]

The vCenter workaround KB https://kb.vmware.com/s/article/87081?lang=en_US got updated and said that the Pure Storage vSphere Plugin 4.3.1 and older cause the jar to keep showing up as vulnerable. As soon as I removed the plugin and installed version 4.5.1, it cleared.

This has been found with older versions of the Pure Storage HTML client plugin 4.3.1 and below . The file continually marked as vulnerable will be: /usr/lib/vmware-vsphere-ui/server/work/Catalina/localhost/ROOT/eclipse/configuration/org.eclipse.osgi/321/0/.cp/log4j-core-2.11.2.jar.

---

In my case, the jar file was a little different (folder 322 vs 321), but the issue got resolved.

[jimfa]

Hi rgb99,

That is helpful information, I haven't thought of that, we too use pure, thanks, I will update the plugin as well, 

I think this is the real solution, 

Thanks @rgb99