Log4J Security Measures

We take the security of iDialogue very seriously and actively monitor broader Internet security trends and bulletins.

For those with questions related to the log4j vulnerability,this post provides some details on proactive and preventative measures taken to ensure the security of iDialogue hosted data and documents.

Our hosting provider, AWS, has assured us our Java 11 hosted containers were not exposed to this vulnerability, and that they've taken the following additional preventative measures:

AWS Lambda does not include the Log4j2 utility in the Lambda Java managed runtimes (Java 8, Java 8 on AL2, and Java 11) or corresponding base container images.  Functions that do not include impacted versions of Log4j2 within their code are therefore not affected by the issue described in CVE-2021-44228 and CVE-2021-45046.
​
We have applied a change to the Lambda Java managed runtimes and base container images (Java 8, Java 8 on AL2, and Java 11) that disables remote class loading by the RMI Registry or COS Naming service provider. This change helps to mitigate the issues in CVE-2021-44228 and CVE-2021-45046 for Lambda functions that package the impacted versions of Log4j2. Customers using managed runtimes benefit from this change automatically. 

iDialogue has one transitive dependency on Log4J via our use of the Twilio Java SDK for sending SMS messages for two-factor authentication to rooms. In addition to upgrading this dependency to Log4J v2.17.0, we’ve also verified the utilization of the SDK does not log customer provided events.