zip -d log4j-1.X.jar 不工作（log4j 1.X 漏洞 CVE-2021-4104）

Question

I want to fix the Log4J 1.* vulnerability by using this command:

zip -d /home/server-cliet.jar::BOOT-INF/lib/log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

( log4j-1.2.17.jar is the dependent jar of server-cliet.jar )

This command result is:

zip warning:/home/server-cliet.jar::BOOT-INF/lib/log4j-1.2.17.jar not found or empty.

I use another command:

zip -d /home/server-cliet.jar BOOT-INF/lib/log4j-1.2.17.jar/org/apache/log4j/net/JMSAppender.class

Result is:

zip warning:name not matched:BOOT-INF/lib/log4j-1.2.17.jar/org/apache/log4j/net/JMSAppender.class

please help!

Answer 1

First you need to understand what you are trying to do. The command that you are trying to run appears to be attempting to remove a class from a JAR file that is embedded in another JAR file. The outer JAR file appears to be an executable Spring application... or something like that. ("BOOT-INF/" is used by the Spring application loader.) The inner JAR is a log4j 1.x JAR.

Next, you need to understand how the zip and unzip commands work on Linux. Read the manual entries: man 1 zip and man 1 unzip .

There are a few potential / actual problems with what you have been doing.

1. The pathname ("/home/server-cliet.jar") doesn't look right to me:

   • "/home" is an odd place to put files. On a typical Linux system, "/home" contains a subdirectory for each user. You don't put files there.

   • "server-cliet.jar" looks like a typo. That isn't how you spell client.

2. The Linux version of zip ¹ doesn't understand :: as refering to JAR / ZIP within a ZIP. It thinks it is a normal pathname. Which doesn't work. That's why you got the first "not found or empty" message.

3. The second command failed because Linux zip -d only knows how to delete an entry of a ZIP / JAR.It doesn't deal withe JAR-in-a-JAR scenario. So the command is actually telling zip to delete an entry that doesn't exist.

4. It is also not clear that BOOT-INF/lib/log4j-1.2.17.jar is the correct pathname for the inner JAR. The minor version number might be different.

---

So... dealing with this is going to be messy. What you need to do is ² :

• Unzip the outer JAR into a temporary directory
• Find the log4j-1.2.xx JAR in the temp directory
• Use zip -d to delete the class from the log4j-1.2.xx JAR. Or just replace that entire JAR with a fixed version of log4j-1.2 downloaded from a reliable source.
• Rezip the (updated) temporary directory
• Use unzip -l on the resulting JAR file to confirm that the paths are correct.

---

Finally, note that this is only necessary if your server-cliet application is actually configured to use the JMS appender. According to the CVE, this is not the default behavior, so if your app doesn't configure it, then this rigmarole may not be strictly necessary. Though it may be needed to get your corporate IT security team off your back.

---

^{1 - In fact, I'm not sure of which version of zip does support that syntax. If someone knows, please comment.
2 - I am not going to tell you the exact commands to run. You should be able to work it out from the manual entries and some trial and error. If you can't, maybe hire a Linux professional to help you out with this.}