Edit online

Log4Shell - Oxygen XML Vulnerability Analysis FAQ

Cristi Talau
15 Dec 2021
Read time: 11 minute(s)
Security

NIST has announced a vulnerability (CVE-2021-44228 code-named Log4Shell) in the Apache Log4j library. Syncro Soft has released a new critical security advisory CVE-2021-44228 and prepared this page containing frequently asked questions and answers related to this vulnerability and its impact on our software products.

In the following days, more vulnerabilities (with far lower impact on Oxygen products) were discovered on the Log4j library: CVE-2021-45046, CVE-2021-45105, CVE-2021-44832.

Please subscribe to our Security Advisories mailing list (found on the top of the Security Advisories page ), and revisit this page periodically to get the latest information.

  1. How to protect against this vulnerability?
    • Upgrade to the latest version of our products. We have already released new minor bug fix versions for our products. For example, for Oxygen XML Editor/Author/Developer versions 24.0, 23.1, and 22.1.
    • If you cannot upgrade to the latest version, patch or update the Log4j library.
  2. How can I patch or update the Log4j library?
    • If you are using one of these products:
      • Oxygen XML Editor/Author/Developer standalone installation
      • Oxygen XML Editor/Author/Developer plugin for Eclipse installation
      • Oxygen XML Web Author
      you can use our free tool (https://github.com/oxygenxml/oxygen-log4j-patcher) to upgrade the Log4j 2.x libraries or to remove the problematic JndiLookup class from inside them.

      The recommended Oxygen versions to apply this tool on range from 16.1 to 22.1 inclusively.

    • If you are using Oxygen Content Fusion, you can use the Content Fusion Log4j Patcher: https://github.com/oxygenxml/content-fusion-log4j-patcher.
    • For other scenarios:
      • Scan your system for occurrences of the log4j-core JAR file.
      • Stop your running Java application (e.g. Oxygen XML Editor).
      • Delete the JndiLookup class from those JAR files. For example, use the following command on a Linux system: 
        zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  3. Am I still vulnerable if I set the -Dlog4j2.formatMsgNoLookups=true system property?
    • Although our products do not meet the preconditions for CVE-2021-45046, setting this system property is no longer considered to offer bullet-proof protection.
  4. Am I still vulnerable if I set the environment variable: LOG4J_FORMAT_MSG_NO_LOOKUPS="true"?
    • Although our products do not meet the preconditions for CVE-2021-45046, setting this environment variable is no longer considered to offer bullet-proof protection.

  5. Are there components that may have this problem used by the application outside of the Oxygen installation folder?

    • Oxygen add-ons may come bundled with Log4j 2.x libraries. Update all your add-ons to their latest version by using the Help > Check for add-ons updates menu action.
    • The Oxygen application may have external tools configured in the Preferences > External Tools page. Check that your external tools do not use Java processes that may have this problem.
    • You may have configured extra JAR libraries used for validation or transformation scenarios. Check that all of these separate libraries do not contain the Log4j 2.x libraries.
    • There may be data sources (for example, for connections to eXist-db servers) created in the Preferences > Data Sources page that have references to Log4j 2.x libraries. If this is the case, update your connection libraries to the latest ones provided for the latest server installation.
    • You may run DITA publishing using an external DITA Open Toolkit publishing engine that has older versions for the bundled Log4j 2.x libraries provided by the Oxygen-specific publishing plugins. Update the Oxygen plugins used by the custom DITA Open Toolkit to the latest versions available on our website.
  6. I am using the Oxygen SDK and cannot upgrade. How can I upgrade just the Log4j library?
    • Make sure that you do not have the version of Log4j hard-coded in your pom.xml file.
    • You can control the version of Log4j to be included by adding the following configuration in the dependencyManagement section of the pom.xml file of your project:
      <dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-bom</artifactId>
  <version>2.17.1</version>
  <type>pom</type>
  <scope>import</scope>
</dependency>
    • To test which version of Log4j your Maven project uses, run: mvn dependency:list -DincludeGroupIds=org.apache.logging.log4j -U.
    • If you are using the web-author-component artifact, you can use a Maven WAR Overlay to replace the packaged Log4j library distributed with a newer version.
  7. Am I still vulnerable if I block all outbound traffic?
    • If you block ALL the outbound traffic, you may be safe, but:
      • Be sure to block also DNS traffic, as it can exfiltrate data such as environment variables.
      • Be sure to re-assess which servers are trusted - maybe some trusted servers had the same vulnerability and were exploited.
    • Regardless, it is a very good idea to restrict outbound traffic from Oxygen tools. This will protect you against various types of vulnerabilities.
  8. Am I still vulnerable if I use a new version of Java?
    • The vulnerability is known to exist with the latest versions of Java (e.g. > 1.8u191) if you are also using Apache Tomcat or Websphere. If you are not using those servers, you may still be vulnerable, but we are not aware of any exploits.
  9. Should I remove the JndiLookup class?
    • Yes. Removing it will remove the vulnerable code. We have high confidence that other problems will not be generated.
  10. Should I set firewall rules based on HTTP headers or URLs to block attacks?
    • These kind of rules do not offer full protection. The URLs that exploit the vulnerability can be written in various ways and are not recognized by common WAF rules that you might find.
  11. How to test if I am vulnerable?
    • If you did not apply any mitigation, you can assume you are.
  12. Should I do anything if the affected server is deployed inside the intranet?
    • Yes. The attack can be triggered from another server that was exploited or by one of the employees when they follow a link in a phishing email.
  13. Should I upgrade to the latest version of your products?
    • Yes. New maintenance builds that avoid this vulnerability are available for versions that are in the maintenance period.
  14. Is this vulnerability related to Java being insecure?
    • No. It is caused by an open-source component called Log4j that had a vulnerability. This component is widely used in the Java ecosystem.
  15. How is Syncro Soft addressing the problem?
    • We patched all our public servers against this vulnerability.
    • We provided a security advisory with current solutions (https://www.oxygenxml.com/security/advisory/CVE-2021-44228.html) and we produced maintenance builds that remove the vulnerable version of Log4j for all product versions that are under maintenance. We are working on solutions for older versions.
    • We analyzed and updated our internal servers to make sure they are not vulnerable.
    • We scanned the logs of the services we use or provide to look for the pattern that triggers the vulnerability.