CVE-2020-9488 remediation / general question

[Laurie Sciutti]

Hello Community!   Per list-of-security-vulnerabilities-addressed-in-atlassian-log4j1 , the mitigation notes for CVE-2020-9488 indicate the following:  

Not vulnerable in the default configuration.

If you're using Log4j to email errors to admins, as a workaround, set the mail.smtp.ssl.checkserveridentity system property to true.

Question:  how do we know if we're using the default config or if we're using log4j to email errors to admins?

[Laurie Sciutti · Accepted solution]

For anyone who's curious, per Atlassian Support:

If you would like to know if you are using default configuration or using log4j for sending email errors to admins:

• Jira uses the logging module log4j to output log statements from applications to various output targets.  By default, these log outputs are written to various Jira logs, but the module can also be configured and customized to do other things, such as email log information via SMPT using the SMTPAppender.

That said, by default, Jira does not use the SMTPAppender to send log information via SMTP email. 

Ultimately, if you've never configured the appender for SMTP in Log4j's configuration file (log4j.properties), you shouldn't have to worry about the CVE applying to your instance.

However, if you'd like to verify, you can look at Jira's log4j.properties file in Jira's installation directory to confirm if the appender is enabled inside the log4j.properties file.

The setting begins with a line that should look very similar to this:

log4j.appender.mail=org.apache.log4j.net.SMTPAppender

• Default location:  <jira-application-dir>/atlassian-jira/WEB-INF/classes/log4j.properties
• If you don't see SMTPAppender setup in log4j.properties, then your instance is not sending log4j output via the SMTPAppender. 

Additionally, if you'd like to remain on the side of caution, then you can always setup the JVM argument: 

-Dmail.smtp.ssl.checkserveridentity=true

• When the property is set to "true," the client verifies during the SSL handshake that the domain name on the server matches the domain name in the server's SSL certificate.
• By confirming that the server you're connecting to is, in fact, the one it purports to be, it adds an extra degree of protection. The connection is not made if the check fails.