1

I am using QGIS in a work environment so it is critical to know if and how QGIS is affected by the Log4J vulnerability.

There are affected software lists, where I cannot find QGIS on, eg. here or here. I don't know whether it is missing or intentionally not listed.

Improve this question
0

2 Answers 2

Reset to default
11

QGIS is not a Java application and does not use any Java component including log4j(ava).

Improve this answer
3
  • Is it generally possible, that a plugin uses Java? ( I know it wont be possible to list all eventually affected plugins, if so)
    – e-shirt
    Dec 14, 2021 at 10:35
  • 2
    Yes, it is generally possible. For every plugin, there is a link to the source repository and an issue tracker. In this case, it will be worth raising the issue with the plugin author. plugins.qgis.org
    – Matthias Kuhn
    Dec 14, 2021 at 10:45
  • 1
    blog.qgis.org/2021/12/14/qgis-not-affected-by-log4j (Same answer but from the QGIS blog)
    – J.R
    Dec 15, 2021 at 12:23
0

UPDATE: 2021-12-18...

Remember to always check for the latest information from the resources listed below

CVE-2021-45105... 2.16.0 and 2.12.2 are no longer valid remediations! The current fixing versions are 2.17.0 (Java 8) and 2.12.3 (Java 7). All other Java versions have to take the stop gap approach (removing/deleting JndiLookup.class file from the log4j-core JAR.
I have updated my message below accordingly.

Answering the question directly:
Go to the reddit thread linked below and cntl+f for .class and .jar recursive hunter. Run the program there and if it finds anything you know you need to remediate.

Then go to the same website and cntl+f for Vendor Advisories. Search the lists there for any software/plugins you are running. If you are running something in the list and there is an update available, update.

Remediation:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
While most people that need to know probably already know enough to do what they need to do, I thought I would still put this just in case...

  • Follow the guidance in those resources... it may change, but

As of 2021-12-18

It's basically

  • Remove log4j-core JAR files if possible
    • From both running machines for immediate fix AND
    • in your source code / source code management files to prevent future builds / releases / deployments from overwriting the change
  • If that is not possible (due to a dependency), upgrade them
    • If you are running Java 8, then you can upgrade to log4j 2.17.0+
    • If you are running Java 7, then you can upgrade to log4j 2.12.3
    • If you are running an older version of Java, then you need to upgrade to the newest version of Java and then use the newest version of Log4J
    • Again, these changes have to happen both on running machine and in code
  • If neither of those are possible for some reason... then there is the NON-remediation stop gap of removing the JndiLookup.class file from the log4j-core JARs.
    • There is a one-liner for the stop gap option on Linux using the zip command that comes packaged with most Linux distros by default.
      • zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
    • At time of writing, most of the guides online for the stop gap option on Windows say to do the following (again... assuming you can't do one of the remove JAR or upgrade options above):
      • Install something like 7-zip
      • Locate all of your log4j-core JAR files and for each one do the following...
      • Rename the JAR to change the extension to .zip
      • Use 7-zip to unzip the JAR (which now has a .zip extension)
      • Locate and remove the JndiLookup.class file from the unzipped folder
        • The path is \\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
      • Delete the old JAR file (which now has an extension of .zip)
      • Use 7-zip to RE-zip the folder
      • Rename the new .zip folder to change the extension to .jar
    • There are also some options to use Power Shell

This is fine if you only have 1 or 2 JAR files to deal with and you don't mind installing 7-zip or you have PowerShell available to do it. However, if you have lots of JAR files, or if you don't want to install 7-zip and don't have access to Power Shell, I created an open-source VBS script that will do it for you without needing to install any additional software. https://github.com/CrazyKidJack/Windowslog4jClassRemover

Read the README and the Release Notes https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

Improve this answer
3
  • 1
    How is this applicable to QGIS?
    – nmtoken
    Dec 17, 2021 at 12:03
  • 1
    @nmtoken OP Asked how to detect if their systems were vulnerable. I answered that question. To re-cap: visit the official vulnerable software lists "Vendor Advisories" and look for QGIS. Also, it's prudent to run the manual checkers to validate ".class and .jar recursive hunter". Then I offered some remediation advice in the case that the OP finds a vulnerability on their system which may include QGIS.
    – Jackson Pfeffer
    Dec 17, 2021 at 15:20
  • 1
    @nmtoken I would specifically point out that OP brought up the possibility of these vulnerabilities to surface in plugins to QGIS. In those cases, the answer from underdark would not suffice... hence, I provided a more thorough answer that addresses how a user could assess their own system as opposed to relying solely on underdark's answer
    – Jackson Pfeffer
    Dec 19, 2021 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.