0

I am using Jib to pull a base image, add my wrapper java code to it, and build my image on top of that. Due to the widely known log4j CVE in December 2021, we are looking for a way to remove the vulnerable classes. (Now more CVEs are found in 2022, one of them has a score of 10.0, the highest possible. See https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-37215/Apache-Log4j.html)

The base image is near EOL, so the provider answered that they would not release a new version; besides, log4j 1.x also reached EOL long before. But the current situation is that we have no plan of upgrading the base image to next version, so removing the classes seem to be the only way now.

The base image will use /opt/amq/bin/launch.sh as entrypoint. And I have found that I can use customized entrypoint to run a script before that, which removes the classes. Like <entrypoint>/opt/amq/bin/my_script.sh</entrypoint>, and in that I have run_fix.sh && /opt/amq/bin/launch.sh.

Then I realized that even this would work by mitigating the risk when the application is actually running, the vulnerability scan(part of security process) will still raise alarms while examining the image binary, as this is a static process done before the image is uploaded to the docker registry for production, way before actually running it. They can only be removed at the moment when the application runs, aka at runtime.

Can jib pre-process the base image while doing Maven build(mvn clean install -Pdocker-build) instead of only allowing it at runtime? According to what I have read, I understand it's a big NO, and there's no plugin for it yet.

WesternGun
  • 11,303
  • 6
  • 88
  • 157

1 Answers1

1

By the design of container images, it is impossible for anyone or any tool to physically remove files from an already existing container image. Images are immutable. The best you can try is "mark deletion" with some special "whiteout" file (.wh.xyz), which a container runtime will hide the target files at runtime.

However, I am not sure if your vulnerability scanner will take the effect of whiteout files into account during scanning. Hopefully it does. If it doesn't, the only option I can think of is to re-create your own base image.

Take a look at this Stack Overflow answer for more details.

Chanseok Oh
  • 3,920
  • 4
  • 23
  • 63
  • So you mean even I think it's removed, they are just whiteout? Then I have to think again.. Maven plugins, such as shadow plugin, can only modify the dependency jar introduced in my java code, but not those in base image. Maybe I can create a modified version of these jars, put them into src/main/jib, and make jib copy them to the location I want.. that is a way – WesternGun Feb 25 '22 at 10:35
  • 1
    Overwriting jars with the same name is not different from adding a whiteout file. The new jars will hide the jars in the base image but cannot physically remove old jars. But as I said, container runtimes never make them accessible at runtime, so if your vulnerability scanner doesn't complain, I think either overwriting or adding whiteout files is fine. – Chanseok Oh Feb 25 '22 at 13:14
  • At last I think the jib-maven way is too complicated, and as our security scan is naive and cannot(and will never be smart enough to) dive deep into the image binary to judge whether the vulnerability is resolved depending on the presence or not of the classes, I will stick to my current solution, and mark the vulnerabilities as resolved. – WesternGun Mar 01 '22 at 13:51
  • A possible solution would be, as I imagine: 1) introduce the dependencies under `provided` scope in pom.xml 2) use copy-dependencies plugin to copy the jars into a dir 3) use exec-plugin to run a script to remove classes in the dir 4) use jib to copy these modified jars into image with ``, to "whiteout" the original jars on an additional layer. But that is too much work and vulnerable jars still exist on previous layers. Anyone reading this may try. Remember to bind the execution of plugins in different phases of maven build to do them in such order. – WesternGun Mar 01 '22 at 13:55
  • At last I managed to implement the solution in my last comment, it's easier than I thought. See [here](https://stackoverflow.com/questions/70333482/log4j-vulnerability-check-how-to-quickly-detect-if-log4j-is-used-in-mavevn-in#answer-70360877) – WesternGun Mar 19 '22 at 05:18