cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
bkelly
By
Flexera Alumni

Apache-Log4j-Logo.png

Recently, a vulnerability within Apache Log4j caught widespread public attention and has security, operational, and development teams alike scrambling for analyzing the impact within their own ecosystem and to apply mitigations if necessary. The wide use of Log4j and the ease of the exploitation of the vulnerability makes this vulnerability very suitable for quick and effective use within exploitation campaigns. Shortly after the publication of the vulnerability Proof of Concepts (PoCs) and reports of exploitation began to arrive. For more details on this vulnerability and how it works, please see “Vulnerability Details” at the end of this article.

This article is intended to help explain how Flexera security products can help you identify and remediate this vulnerability. For the status of impacted Flexera products, please see this announcement.

 

Software Vulnerability Research (SVR)

Alerts will be generated based on configured watch lists and configured notification settings.

SVR customers can expect to see:

  • Up-to-date Secunia Advisories (SA105630, SA105605, SA105601) and further third-party product-related Secunia Advisories which contain detailed information on the vulnerability and its variants, including the solutions/patches and available CPEs
  • CVEs associated with the vulnerability and its variants as published by a trusted source (for example, the vendor Apache or MITRE)
  • Threat intelligence information associated with the vulnerability and its variants (if entitled to our Threat Intel module)

 

Software Vulnerability Manager (SVM)

Vulnerable products can be detected via file signatures which provide a definitive, actionable status. Where available, security updates may be published to remediate vulnerable instances detected in your environment.

SVM customers can expect to see:

  • Impacted software product versions being detected in their inventory
    • NEW SVM's Single Host Agent (v7.6.0.19) can now detect the log4j-core*.jar files installed on a host machine. See details here.
    • We are and will continue, actively working to obtain more vulnerable product versions in order to create file signatures. If you are aware of a software version that is impacted but not yet detected, please submit it via the normal software suggestion process to help us to get the details necessary to create a file signature.
  • CVE associated with the vulnerability and its variants as published by a trusted source (for example, the vendor Apache or MITRE)
  • Threat intelligence information associated with the vulnerability and its variants (if entitled to our Threat Intel module)
  • Patches you can publish to remediate this vulnerability and its variants for covered products as they are released by their respective vendors.

This vulnerability will be the cause of many software vulnerability disclosures, but each application including and exposing it will typically issue its own disclosure. Our Secunia Research team will continually monitor for such and will create a file signature for SVM to detect and assess specific versions as vulnerable as appropriate.

 

 

For details on the Log4j vulnerability please see Apache Log4j "Log4Shell" and Beyond

 

How Other Flexera Solutions Can Help

To see how other Flexera solutions can help customers get immediate visibility on the impact of this and other vulnerabilities, please go to this main article on the Community Hub where you can find the complete detail across all Flexera solutions.

(4) Comments
Howardmp
By
Level 3

Hello Community,

 

I'm attempting to search "All Advisories" for CVE-2021-44228 but getting nothing returned. Is this because SVM doesn't yet have detection for the CVE or because it believes that we have no exposure?

Many thanks

 

 

Shoggi
By
Level 5

SVM can't scan on *.jar files. This way log4j on Windows won't be found. Only RedHat. We had a support ticket on SVM to clarify situation. This way in SVM you would only find it if e. g. IBM issue a CVE to fix their product which contain log4j to a newer version of their platform. If they publish only to change xy config file that won't appear in SVM at all. This way no chance ot use this.

 

We end up to write a script and search for log4j* via SCCM on all our end points and servers and monitor software vendors articles. The tricky part is also the above is an option but if the dll is embedded in their code you won't be able to find it with our above method either.

Howardmp
By
Level 3

Hello Shoggi, Community,

I can see in my "All Advisories" window that CVEs are listed so was expecting that if a software is known to be vulnerable to CVE-2021-44228 it should be listed?

Thanks

 

 

 

bkelly
By
Flexera Alumni

If you don’t see anything, it is because no products with known vulnerabilities are found. You can expect new disclosures on a daily basis, so keep watching.

Shoggi is correct in his statement above. I just wanted to point out that it is not the intent of SVM to scan jar files—it not a product deficiency but rather, is out of scope. SVM focuses exclusively on assessing known vulnerable software versions. It uses file signatures to determine the presence of known vulnerable software versions and matches that with research and patches to help you identify and remediate such. So, if Log4j is installed on a system, we will detect it, but that is not typically how Log4j is distributed—rather it is included as a component of another third-party application. In such a case, it will be identified as vulnerable if/when the software including it is disclosed as vulnerable, we write an advisory and create a file signature to detect it.


That said, we are prioritizing a potential product enhancement that would allow SVM to provide an awareness report to identify specific components like Log4j embedded within your installed software. This would be a new use case for SVM as it would help provide awareness, but you would not be able to remediate it by patching as SVM is traditionally leveraged. This is due to the fact that the product bundling the component is what needs to be patched, so this would be a new reporting-focused use case versus a patch-focused one. Actually patching a vulnerable component will continue to require targeting the application that is shipping the component, versus the component itself.