Data Loss Prevention

 View Only

 Log4j Vulnerability

Jim Mie Lu's profile image
Jim Mie Lu posted Dec 17, 2021 12:52 PM
I understand that Symantec DLP is not affected with the vulnerability as mentioned on the advisory: Broadcom Support Portal
However, upon search the Oracle DB installation of 12c (and maybe 19c), we've noticed that there are certain log4j files available under the \oracle\product directory.

I know Symantec basically resells the Oracle DB to be used for the DLP software but I'm not able to access the Oracle KBs directly without an account that has Oracle support to actually view the articles that they have posted with products that are vulnerable. I've searched some sites that mentions that the version being used on 12c is that of 1.x which is not affected by this vulnerability, but it seems that 19c has some of these versions listed:

Please, if someone from Symantec/Broadcom is able to provide further insight into this and clarifications on the files above?

Muhammad Atif's profile image
Muhammad Atif

I have checked this through different resources and I came across a document by Oracle which clearly states “Oracle Database (all supported versions including 11.2, 12.1, 12.2, 19c, and 21c) are not affected by vulnerability CVE-2021-44228 or CVE-2021-45046

It further states “Oracle Databases with the October 2020 or later critical patch update are evaluated as not vulnerable to CVE-2021-44228 or CVE-2021-45046

Please find link below for this article.


Sunil Khanna's profile image
Sunil Khanna
Hi Jim,

I asked our Broadcom  CSM to inquire of Engineering re the same issue and this is what they replied:

The only vulnerabilities for databases that Oracle has documented are for "Autonomous Health Framework" and "Oracle Spatial and Graph" which are separate products that must be installed to be used. Spatial and Graph does also require the Spatial client must be installed as part of the Oracle database creation. While this installation is a default option using Oracle default template, our template (required to be used for our product) specifically excludes this database option from being installed.


As far as the log4j files being on the Oracle system, the presence of the files does not equate to a vulnerability, but requires that the vulnerable class be in use by the product.

So unless you're using either of those 2 modules, ​it sounds like your system is safe.

BUT I would probably try reaching out to your Broadcom reps for 'official' confirmation.

Aman Yadav's profile image
Aman Yadav

I will explain this in more details.

Apache log4j has two major releases: log4j 1.x (EOL) and log4j 2.x.

The vulnerable class is packaged as a part of log4j-core jar, and not log4j-api jar.

Since DLP includes log4j-api jar file and not log4j-core, it is not vulnerable to CVE-2021-44228.
log4j 1.x does not have Jndi class, and hence is automatically NOT vulnerable to log4shell (CVE-2021-44228).
In the patchset, Apache team also addressed a similar security issue in JMSAppender class (which is present in both log4j 1.x and log4j 2.x). 

DLP Security team reviewed entire source code and concluded the JMS Appender functionality is not being used in DLP.
DLP ships log4j 1.x and only one jar file (log4j-api-2.x.jar) from log4j 2.x.
Given the above information, it is safe to conclude none of the log4j packages shipped with DLP are vulnerable to either CVE-2021-44228 or JMSAppender vulnerability.

Security scanners that flagged log4j-api vulnerable should be updated with this new information. We recommend customers update their scanner database on a regular basis. We have reports that Qualys scanner  did flag log4j-api as being vulnerable, which is a false-positive