Question

Do any Laserfiche products use the Apache log4j library?

Laserfiche

Updated April 5, 2022

asked on December 10, 2021

With some recent news over a vulnerability found in the Apache log4j library I just wanted to confirm whether or not it was used in any Laserfiche products? I was not able to find anything, but just wanted to confirm. Thanks!

7 0

Answer

APPROVED ANSWER SELECTED ANSWER

replied on December 10, 2021 • Show version history

Update 15 Dec 2021: There is now a Laserfiche Support site article on this topic, linked below. It is Laserfiche's official statement on the vulnerability and any future updates with be made to that article rather than here. Please reference it for the most up-to-date information.

Apache Log4j 2 Vulnerability (CVE-2021-44228)

Here are the contents of the article as of today:

----------------------------------------------------------------------------------------------------------

Summary

Laserfiche is aware of the publicly disclosed Apache Log4j 2 remote code execution vulnerability described in CVE-2021-44228.

Our downloadable software products, including Laserfiche Rio and Laserfiche Avante, do not ship with or use Log4j 2.

Laserfiche Cloud, which is our multitenant SaaS platform, has some backend systems that use some versions of Log4j 2. Patches have already been applied to Laserfiche Cloud to mitigate the vulnerability.

This article summarizes any potential impacts to Laserfiche products.

Laserfiche Self-hosted and Locally Installed Products and Modules

Laserfiche's downloadable software products, including Laserfiche Rio and Laserfiche Avante, do not ship with or use Log4j 2.

Laserfiche Cloud

Laserfiche Cloud contains some backend systems that use Log4j 2. Security testing has not identified any exploitable vulnerabilities related to this issue in Laserfiche Cloud. As a standard preventative measure, the associated backend systems have been patched to mitigate the vulnerability.

Laserfiche Cloud relies on select AWS services that may also be impacted by the vulnerability. Amazon has stated that they are working on addressing the issue for any AWS services which use Log4j 2. Please see the following statement from Amazon on the vulnerability:

https://aws.amazon.com/security/security-bulletins/AWS-2021-006/

Other Mitigations

We also recommend that customers check whether any integrations or other non-Laserfiche software may be impacted and to check for potential patches.

Related Links

----------------------------------------------------------------------------------------------------------

Original Post:

Laserfiche products do not ship with/use the Apache log4j library and are thus not vulnerable to CVE-2021-44228.

10 0

replied on December 11, 2021

Sam, I received a notification from the Authorize.Net developer network that would indicate that Authorize.Net itself might be vulnerable?

https://support.authorize.net/s/article/Apache-Log4J-Zero-Day-Vulnerability?utm_campaign=22Q1%20ANET%20Java%20log4j%20Vulnerability%20Email%20-%20Developers&utm_medium=email&utm_source=Eloqua

If so could that impact the Forms payment gateway functionality?

0 0

replied on December 12, 2021

It depends on what updates the Authorize.Net side will make.

2 0

replied on December 13, 2021

It is highly unlikely Authorize.Net's updates would affect Forms payment gateway functionality.

The way the Log4j2 vulnerability exploit works is by an attacker causing a specially crafted JNDI:LDAP URL pointing at a malicious server to get logged by a vulnerable application. Log4j would then get the execute an LDAP query against the attacker's server, which would return a malicious payload, and Log4j would then execute the payload. This abuses functionality in the Log4j JNDI extension class, which is intended to do useful things with lookups against your own LDAP servers.

undefined

Apache has a patched version and mitigations available:

Update Log4j2 to 2.15.0, which disables the lookup functionality by default.
In earlier versions, either set a configuration parameter that disables those lookups, or remove the JNDI extension class entirely.

Since the Laserfiche Forms payment gateway integration doesn't depend on logging LDAP endpoint URLs in any way, I can't think of any plausible direct way that Authorize.Net patching or applying mitigations for Log4j on their systems would affect our functionality. If Authorize.Net has systems exploited by the vulnerability that's an entirely different scenario that I can't speculate on.

2 0

Replies

replied on December 15, 2021

A couple of items:

1) Your link to the support article is broken

2) Posts say Laserfiche does not ship with log4j, then what is this file doing?

c:\Program Files (x86)\Laserfiche\Webtools Agent\log4net.dll

File properties says it is Apache log4net for .NET Framework 4.5. The version is 2.0.8.0.

Our vulnerability scanner says it is a vulnerability.

0 0

View 4 previous replies

replied on December 15, 2021

I did some more digging and perhaps the Log4Net version is not vulnerable?
https://blogs.apache.org/security/entry/cve-2021-44228

0 0

replied on December 15, 2021

Hi James,

First, thanks for catching the broken link. I've now fixed it.

Second, that's correct, Log4j ports in other languages like Log4net are not affected by CVE-2021-44228 because the exploit is Java-specific. It relies on a Java feature called Java Naming and Directory Interface (JNDI) that is not present in .NET.

Here are some resources in addition to the Apache security post you found:

0 0

replied on December 15, 2021 • Show version history

@████████ We're looking into this other potential vulnerability that's unrelated to CVE-2021-44228 now. I'm redacting your post in the meantime.

Update: CVE-2018-1285 for log4net specifies "This allows for XXE-based attacks in applications that accept attacker-controlled log4net configuration files." After a preliminary investigation we do not believe Laserfiche applications that currently ship with Log4Net < 2.0.10 to be vulnerable to this exploit because they do not accept attacker-controller log4net configuration files. An attacker would already have to have access to the machine in question in order to insert their own malicious configuration file. We expect to update the library in question in an upcoming normal update.

1 0

replied on December 15, 2021

@████████Please see update above.

1 0

replied on April 4, 2022

Hi Samuel,

I wanted to check back in with regard to CVE-2018-1285. You mentioned this would be addressed in an upcoming normal update. Has this been addressed already?

0 0

replied on April 4, 2022

Hi Michael,

My understanding is that individual product teams plan to update Log4Net as a low priority/as time permits item, in some future releases.

The description of CVE-2018-1285 is:

Apache log4net versions before 2.0.10 do not disable XML external entities when parsing log4net configuration files. This allows for XXE-based attacks in applications that accept attacker-controlled log4net configuration files.

I want to re-emphasize that Laserfiche applications that currently ship with Log4Net < 2.0.10 are not vulnerable to this exploit because they do not accept attacker-controlled log4net configuration files. An attacker would already have to have access to the machine in question in order to insert their own malicious configuration file.

If someone has administrative access to the servers hosting your Laserfiche system, they're not going to swap in a handcrafted malicious Log4net config file, then carry out the subsequent XML external entity (XXE) attacks that could then give them access they already have.

Just because a library has a vulnerability does not means that applications using that library are automatically vulnerable to exploit. Many, like CVE-2018-1285, are conditional. Because Laserfiche does not accept attacker-controlled configuration files, it is not vulnerable to this CVE, and we do not consider it an open security issue.

If Laserfiche is getting flagged for CVE-2018-1285 by a customer vulnerability scanner detecting Log4Net < 2.0.10 and their security team is requesting a response/fix, please reply with:

Laserfiche applications that currently ship with Log4Net < 2.0.10 are not vulnerable to CVE-2018-1285 because they do not accept attacker-controlled log4net configuration files. Because it is not an open security issue, Laserfiche does not have a specific target date or release to update the library.

They should be able to make a note for the vulnerability scan.

0 0

replied on April 5, 2022

Hi Samuel,

Thank you for the detailed response. I will work with our vulnerability scanner vendor to see if we can setup an exclusion until this gets updated.

1 0

replied on March 14, 2022

I have been asked the following specific questions:

Please forward to your IT/Security Dept. for a response.

Your company provides important products and services to Progressive/ASI (PGR Home). Due to recently reported security issues regarding the Apache Log4j (aka Log4Shell, LogJam, or Log4j) vulnerability (CVE-2021-44228 and CVE-2021-45046), we require your immediate attention and response to the questions below.

Does your product run Java in any way?

What version of Java are you running?

Does your product have any .jar files on it?

Did you recursively decompress every .jar file to look for nested instances of Log4J?

Did you look for Log4J in your application layer?

Did you look for Log4J in your base technology stack (i.e. host operating system)?

Please explain in detail your methodology to detect all instances of Log4J on your system?

Please explain in detail your methodology to mitigate all vulnerability instances found of Log4J?

Does this asset exist already on the network?

If yes, the current defined Log4J process will require problem management to reach out to discuss the direction forward for the assets that already exist on the network.

Please advise.

Thank you

0 0

replied on March 14, 2022

Hi Dan,

Please direct your customer to Laserfiche's official statement on Log4j, linked below. We are no longer providing individualized responses to Log4j questions that are reasonably covered by the official statement.

Apache Log4j 2 Vulnerability (CVE-2021-44228)

In short, self-hosted Laserfiche systems do not run Java in any way, so the rest of the questions are N/A. Laserfiche Cloud and some of the AWS services it uses did run Log4j and all known instances of it were fully mitigated months ago.

1 0

replied on March 15, 2022

Thank you - I will pass that on.

0 0

You are not allowed to follow up in this post.

Question

Question

Do any Laserfiche products use the Apache log4j library?

Answer

Replies

Sign in to reply to this post.