Link Search Menu Expand Document

EzSign: CVE-2021-44228/45105/44832

Apache Log4j2 Vulnerability (Log4Shell)

Last Updated: 14:30 December 29th 2021

A vulnerability exists in log4j2 that leverages JNDI to potentially allow an attacker to provide a string that is interpreted as a variable

JNDI does not enforce any security controls on LDAP requests, therefore if a string such as the following:


Could be logged, Log4J would interpret it as a variable and this would result in the classes available at the [host]/[path] location being downloaded and executed

Am I Vulnerable

EzSign does makes use of the vulnerable log4j2 libraries. However, input is passed to the server via the EzSign client and the client is itself driven by internal applications. Applications that utilise the EzSign client are not usually web facing

Data sent to EzSign is generally tightly controlled (from trusted sources etc.), but data from an external source could enter the EzSign logs if sent as part of data to sign (or verify). However, this will not make it to the log system in the intended format

If you hash this data before sending to EzSign then no original data is sent to the EzSign logging system anyway and a variable will therefore not be logged

EzSign also converts data it receives to Base64 before logging. So if an attack string does enter the system, it will still not be logged as intended

For example, if an attacker were to attempt to send the following string, as part of a message to sign data:


It would be logged as follows:


and if hashed prior, as:


I.e. the attack string is not sent to Log4J as the intended string - but the Base64 encoded form (of the original or hashed version). This means log4j is not sent the variable

Channel names, may be logged as sent to EzSign however and are not encoded. But these names are defined and configured by the trusted applications that call the EzSign client. They should not be passed in from external sources nor dependant on any end-user data. Only the trusted calling application will decided on what channel to use

Essentially, EzSign can only log what the calling application sends, and even then data is converted to Base 64. If the calling applications are secure then the risk is low. However, to ensure protection it is recommended to also apply the updates described in the next section:

What should we do

If you are running EzSign under Java 8 then the latest patched version of the log4j libraries should work. Follow the instructions in the Patches section below

If you are running EzSign under Java 7 contact support who will provide guidance on upgrading to log4j version 2.12.2

If you are unable or not intending to patch at this time you may follow the Mitigation Steps below

Mitigation Steps

If you are running EzSign against versions of Java greater than the following:

  • Java 7 – 7u202
  • Java 8 – 8u192
  • Java 11 - 11.0.2

Then you may be protected

In any case, the following should be performed as additional protections:

Update the start script

Update the script (ezsign-daemon-start.bat on windows) to include


To perform this, locate your script. By default, this will be located here:


Edit the file by locating the following line:

"%JAVA_HOME%\bin\java" -Dlog4j.configurationFile=%LOGCONFIG% -classpath %CLASSPATH% com.krestfield.ezsign.server.EzSignServer %1 %2

And adding the -Dlog4j2.formatMsgNoLookups=true section


"%JAVA_HOME%\bin\java" -Dlog4j2.formatMsgNoLookups=true -Dlog4j.configurationFile=%LOGCONFIG% -classpath %CLASSPATH% com.krestfield.ezsign.server.EzSignServer %1 %2

On Linux/Unix the updated line may look as Follows:

$JAVA_HOME/bin/java -Dlog4j2.formatMsgNoLookups=true -Dlog4j.configurationFile=$LOGCONFIG -cp $CLASSPATH com.krestfield.ezsign.server.EzSignServer $1 $2 $3

Save the file

Update the log4j2.xml file

This resides, by default here:

[EzSign Install]\EzSignServer\logconf\log4j2.xml

It will begin as follows:

<?xml version="1.0" encoding="UTF-8"?>
		<property name="name">ezsign</property>
		<property name="pattern">%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n</property>


All that is needed is to replace the %msg%n section with %msg{nolookups}%n. When done the file will then look like this:

<?xml version="1.0" encoding="UTF-8"?>
		<property name="name">ezsign</property>
		<property name="pattern">%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg{nolookups}%n</property>


Save the file

On Windows environments, also add in the following System Environment Variable:


Restart the EzSign services

If EzSign is not performing any revocation checking (CRL or OCSP) then it does not need any external access. Restrict access from EzSign to any external sites using firewall rules


Download version 2.17.2 of the log4j libraries that EzSign uses from here

The SHA-1 hash for this zip file is


Extract the two jar files

  • log4j-api-2.17.2.jar

  • log4j-core-2.17.2.jar

Locate the \lib directory of your EzSign installation

[EzSign Install]\EzSignServer\lib

Backup the existing log4j-api... and log4j-core... files. These will either be versions 2.11.1 or 2.7 (if unpatched)

Copy the contents of the zip file downloaded above to this \lib directory

If you are running EzSign versions below version 3.0.0 then you must also either update your script to reference the new jar filenames:

  • log4j-core-2.17.2.jar
  • log4j-api-2.17.2.jar

Or rename the downloaded files to match the previous (i.e. rename log4j-core-2.17.2.jar to log4j-core-2.7.jar etc.). For later versions of EzSign this is not required (but ensure the old log4j jar files are not present in the lib folder)

Restart the EzSign Server

What version of Log4j2 does EzSign use?

Version 3.0.0 and earlier (this includes EzSign Service 1.3) use Log4J version 2.7

Later versions use Log4J version 2.11.1

More Information

Contact Krestfield Support for more information