Log4Shell exploit

[sderrick]

Is the Oxygen SDK vulnerable to the Log4j exploit?

thanks,

Scott

[Radu]

Hi Scott,

What version of the Oxygen SDK are you using?
How are you using the Oxygen SDK? If you are using it only for compilation, then the SDK itself does not run any code.
If you are using it to build an AuthorComponent Swing application you should set the system property in the command line used to start it:

Code: Select all

-Dlog4j2.formatMsgNoLookups=true

If you compile various actions or Java customizations which will later run in Oxygen XML Editor/Author or on our WebAuthor or Content Fusion servers, we'll try to release new maintenance bug fix versions of each of these products with an updated logging library.

Regards,
Radu

[AnalogKid82]

We're also interested in a patch for CVE-2021-44228, if necessary. We only use the Oxygen Editor and publish to Fluid Topics, but I see there are several log4j files under the installation directory. Are we vulnerable?

[sderrick]

Radu,

We are using version 22.0 of the SDK.

Going through the pom I saw this

<properties>
<target.web.dir>${project.build.directory}/dist</target.web.dir>
<jnlp.name>mbep</jnlp.name>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<oxygen.sdk.version>22.0.0.0</oxygen.sdk.version>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>

<dependency>
<groupId>com.oxygenxml</groupId>
<artifactId>oxygen-sdk</artifactId>
<version>${oxygen.sdk.version}</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>

<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.15.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.15.0</version>
</dependency>

The log4j I see being included is Version 2.15, which is not effected?

These are the 3 log4j files in the project

/home/scott/Desktop/ide/log4j-api-2.15.0.jar
/home/scott/Desktop/ide/log4j-core-2.15.0.jar
/home/scott/Desktop/ide/oxygen-patched-log4j-22.0.0.0.jar

We are using the SDK to build a client AuthorComponent Swing application.

If we upgrade the SDK to version 24, would that prevent the exploit?

Scott

[Radu]

Answer for Scott:

Oxygen 22.0 still uses Apache 1.x log4j which should not be affected by this problem. Oxygen delivers it patched "oxygen-patched-log4j-22.0.0.0.jar" to remove an older security risk.
We upgraded to Log4j 2.x in Oxygen 22.1.
Yesterday we released a new version of the 24 SDK which uses the latest Log4j 2.x libraries which remove the security threat.

Regards,
Radu

[Radu]

Answer for AnalogKid82, about your XML Editor installation please read this article:
https://www.oxygenxml.com/oxygen_xml_vu ... s_faq.html

Yesterday we released an Oxygen 24 kit which removes the problem completely both for editing and publishing using Oxygen's bundled DITA OT engine.
We plan to do so also with Oxygen 23.1.

About you publishing through Fluid Topics you should address this question to them.

Regards,
Radu

[mstr]

Hello Radu,

considering the log4j-*-2.13.0 jar files in the Calabash directory delivered as part of Oxygen XML Editor 22.0, are we still vulnerable to the exploit?

Thanks,

mstr

[Radu]

Hi,

Indeed the Calabash engine (used by Oxygen to run XProc scripts) used log4j 2 even in older versions of Oxygen like 22.0.
If you do not use XProc scripts you could remove the entire "lib/xproc" folder completely, now if the problem is really present or not is hard to tell, we would need to know in what places in their code the Calabash engine logs messages, and also probably you would need to run a certain transformation in Oxygen to trigger the security problem, it's not a security problem that someone can cause by remote logging into Oxygen as Oxygen is a desktop application not a server, but if someone who does not have good intentions would tell you to open in Oxygen a certain XProc script and then run it, and you would follow their advice it may be a possibility to trigger this security problem.

Regards,
Radu

[AnalogKid82]

Answer for AnalogKid82, about your XML Editor installation please read this article:
https://www.oxygenxml.com/oxygen_xml_vu ... s_faq.html

Yesterday we released an Oxygen 24 kit which removes the problem completely both for editing and publishing using Oxygen's bundled DITA OT engine.
We plan to do so also with Oxygen 23.1.

About you publishing through Fluid Topics you should address this question to them.

Regards,
Radu

We just updated to the latest Oxygen 24 build and we are in communication with Antidot. Thanks for the quick response!

[sderrick]

Yesterday Apache released another fix for another RCE exploit.

Previously exploit CVE-2021-44228 was addressed in log4j-2.15.

Now exploit CVE-2021-45046 is being addressed in log4j-2.16.

Does SDK version 24.0.0.1 use the 2.15 or the 2.16 version of log4j?

Scott

[Radu]

Hi Scott,

The 24.0.0.1 SDK uses Lg4j 2.15, we'll probably release a new SDK and Oxygen 24.0 these days (today or tomorrow) with Log4j 2.16. Of course there is nothing stopping you to override the logging libraries bundled with the SDK and use Log4j 2.16 on your side.

Also the new vulnerability for which they issued 2.16:
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
has a low security score and could occur only when the end user is using a configuration file with a certain non-standard pattern layout.

Regards,
Radu

[oxyhv]

Hi Radu,

I just downloaded the latest oXygen Developer and ClamXav on my MBP reports a few infections:

dita.jar Java.Exploit.CVE_2021_44228-9914600-2 Fout /Volumes/Oxygen XML Developer 24.0 1/Oxygen XML Developer/frameworks/dita/dita.jar

There are other jars which are reported, f.i.:

oxygen-editor-variables-parser.jar Java.Exploit.CVE_2021_44228-9914601-4 Fout /Volumes/Oxygen XML Developer 24.0 1/Oxygen XML Developer/lib/oxygen-editor-variables-parser.jar

with another exploit-code (...-4 instead of ...-2).

Are these valid reports or is ClamXav at fault here?

Regards,

Huib.

[Radu]

Hi,

Those look like some kind false positives, maybe you can ask the ClamXav tool vendors for more details.
That "CVE_2021_44228-9914601" possibly refers to the same log4j problem: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
but for example the "dita.jar" from the DITA OT engine does not use the Log4j libraries at all, it uses the LogBack libraries.
Also the problem should be detected inside the logging libraries not inside libraries which might use the logging libraries.

Regards,
Radu

[oxyhv]

Thanks Radu, I'll go ask ClamXav about this.

[Radu]

In parallel I asked our sys admin to scan the Oxygen 24.0 all platforms kit from our web site, he scanned with this version:

Code: Select all

clamscan --version
ClamAV 0.103.2/26389/Thu Dec 16 06:02:49 2021

and it did not seem to report anything:

Code: Select all

----------- SCAN SUMMARY -----------
Known viruses: 8583548
Engine version: 0.103.2
Scanned directories: 1513
Scanned files: 12507
Infected files: 0
Data scanned: 1210.11 MB
Data read: 493.10 MB (ratio 2.45:1)
Time: 540.801 sec (9 m 0 s)
Start Date: 2021:12:16 11:27:06
End Date: 2021:12:16 11:36:07

Regards,
Radu

[adrian]

Hi,

ClamAV seems to have dropped today the signature for Java.Exploit.CVE_2021_44228-9914601-4. See here:
https://lists.clamav.net/pipermail/clam ... 07774.html
Not sure about Java.Exploit.CVE_2021_44228-9914600-2, but it might also generate false positives.

Either way, update your AV signatures/database and try to scan again.

Regards,
Adrian

[sderrick]

Radu,

This issue is like herding cats. I saw that CVE-2021-45046 required a non standard pattern, but I know the powers above want an iron clad solution. Thanks for all the work you guys do...

Scott

Hi Scott,

The 24.0.0.1 SDK uses Lg4j 2.15, we'll probably release a new SDK and Oxygen 24.0 these days (today or tomorrow) with Log4j 2.16. Of course there is nothing stopping you to override the logging libraries bundled with the SDK and use Log4j 2.16 on your side.

Also the new vulnerability for which they issued 2.16:
https://nvd.nist.gov/vuln/detail/CVE-2021-45046
has a low security score and could occur only when the end user is using a configuration file with a certain non-standard pattern layout.

Regards,
Radu

[Radu]

Hi Scott,

We should now have the SDK versions "24.0.0.2" and "23.1.0.4" which use Log4j 2.16.

Regards,
Radu