log4j- Zero-Day Vulnerability – Are You Affected?

By now, many of you are aware of the log4j- Zero-Day Vulnerability, and you may be wondering if your SmartClient based applications will be affected. The good news is that if you are using our default configuration, which is Log4j 1.0, you are not affected, and your SmartClient-based applications are not affected.

Other applications installed on the same server which use Log4j 2.0 may be vulnerable.

However, if, in your SmartClient-based applications, you used our sfl4j bridge to install and use Log4j 2.0, you may be affected by the vulnerability. The recommendation is that anyone using SmartClient + slf4j + log4j v2 should upgrade to the latest log4j v2 to prevent the exploit.

The following mitigations affect the vulnerable case just described:

• You can set the property log4j2.formatMsgNoLookups=true in log4j v2.10 or above.
• You can remove the JndiLookup class from the classpath, for example, by rebuilding the log4j-core JAR file.
• If you have Java build versions 8u191, 7u201, 6u211, and 11.01 or newer, they don’t load remote classes via JNDI by default, but attackers may still be able to use existing app classes to perform remote code execution.

Please note, customers in the above situation should still upgrade to the latest log4j v2.

In summary:

If you use our default configuration of Log4j 1.0, your SmartClient applications are not affected.

If instead, you use the sf4j bridge to use Log4j 2.0, you maybe be affected, and you should upgrade to the latest log4j V2.

Note, some customers have also contacted us about known vulnerabilities in Log4j 1.0 – however, these vulnerabilities do not apply to SmartClient’s use of log4j – you are not vulnerable.

We’d like to take the opportunity to point out an irony here: Isomorphic was repeatedly urged to upgrade the default logging system to Log4j 2.0 for security reasons.  Had we done so, our customers would now be rushing to patch a zero-day exploit.  Isomorphic’s founding team has two security professionals. We understand well that the “latest and greatest” version of a library often has features that have been added quickly without sufficient attention to security.  This is neither the first nor the last time we have saved our customers from a security nightmare by being slow & cautious about upgrading dependencies.

And, as a bonus security note, some customers have also contacted us about a vulnerability reported for Velocity (https://nvd.nist.gov/vuln/detail/CVE-2020-13936).  Here again, this vulnerability is for Velocity templates that can be edited by end-users, whereas with SmartClient, Velocity templates are only editable by developers.  So again, SmartClient-based applications are not vulnerable to this exploit.  However, we have a customer who was kind enough to sponsor an upgrade for Velocity, so 13.0 will use a newer version.  This will not be backported to previous versions, because again, there is no security vulnerability.

The Isomorphic Team