CVE-2021-44228 Log4j impacts on BigFix

By now, many of us are familiar with reported critical vulnerabilities in Log4j, a common logging component used in many Java applications.

The BigFix team has coordinated community responses to help identify applications where affected Log4j components may be in use, in the Forum thread at Log4j CVE-2021-44228 . This new thread is to address areas where BigFix components themselves can be affected.

The BigFix team has published a knowledge article at https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095486 referencing where BigFix may be impacted and workarounds that should be applied. This will be updated over time with additional workaround instructions.

While our development teams are continuing to evaluate our product line and areas that need to be addressed, we can share that there are some areas where customers can take action to reduce any potential risk in our products.

BigFix does use the affected Log4j components in several areas. We have not yet confirmed any areas where we have an actual vulnerability – where we accept user input, and where the Log4j component is configured for dynamic lookups based on that user-provided input. For maximum safety though we can recommend workarounds to reduce potential impacts.

The BigFix core platform - Root Server, Relay, Client, Web Reports, and WebUI - do not make use of the Log4j components and are not impacted.

BigFix Compliance, BigFix Remote Control, BigFix Inventory’s “Virtual Machine Manager” (VMM) component and “SAP Tool” component, BigFix Server Automation’s Orchestrator Engine, and the BigFix Management Extender for VMWare VCenter do make use of Log4j components. Each are detailed below.


BigFix Compliance -


BigFix Remote Control

BigFix Remote Control Server uses Log4j version 1.2.x. This version does not provide the JNDI dynamic lookup feature and appears to be not affected.

Other Remote Control components do not use the Log4j component.

Watch https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095486 for updates.


BigFix Inventory VMM Manager:
and
BigFix Inventory SAP Tool:

Apply the workaround for VMM Manager and SAP Tools as described at https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095486


BigFix Server Automation Engine:
and
BigFix Management Extender for VMWare VCenter:
Update: these components are not affected

3 Likes

I’ve published alpha-level fixlets for testing the workarounds in BigFix Compliance to BigFix.me

If you only have a single Compliance server, I’d recommend applying the workarounds manually, it may not be worth the complexity of using a Fixlet to configure the workaround on a single server, but I’m posting them here in case they are helpful in updating or auditing multiple Compliance servers.

https://bigfix.me/fixlet/details/26890 - Compliance Log4j replacement
https://bigfix.me/fixlet/details/26891 - Compliance Log4j disable lookups

Please let me know if you find any issues.

3 Likes

@JasonWalker Do we know the version of Log4j being used by the BigFix Management Extender for VMWare VCenter component? I was asked to provide this to the executives but I cannot find any reference to the file on the relay where it is installed. I see python, windows executables, and embeded perl… is this a case where the library is also embeded within?

We have since confirmed the VM Management Extender is not affected. The KB article was updated with this note

Note: It has been verified that Remote Control, Server Automation, and Manager Extender for VMware vCenter are not affected by the vulnerability.

2 Likes

Note the release of new out-of-box content to apply mitigations on BigFix Compliance

4 Likes

Thanks for the quick fix. The %22 after log4j-core-2.15.0.jar should be a %27 for single quote. The double quote causes SCA dashboard to not come up.

There is a WASLiberty folder on the root of the drive which has the log4j vulnerability. I’m not sure what it’s used for. In the readme.txt file mentions IBM WebSphere Application Server v8.5.5.6. Is there patch to remediate this?

Also, this there a patch for the MDM feature? Our Security team folder log4j under the \MDM Provider folder.

What’s the full folder? I’m aware that the old MasS360 integration MDM had a vulnerability, but that is long-unsupported.

Just to name a few of the folder path locations of the log4j.

WebSphere App Server –

D:\WASLiberty\wlp\usr\servers\defaultServer\workarea\org.eclipse.osgi\62\data\cache\com.ibm.ws.app.manager_32.cache\WEB-INF\lib\log4j-1.2.17.jar

D:\WASLiberty\wlp\usr\servers\defaultServer\workarea\org.eclipse.osgi\62\data\cacheAdapt\com.ibm.ws.app.manager_31\WEB-INF\lib\log4j-1.2.17.jar

D:\WASLiberty\wlp\usr\servers\defaultServer\workarea\org.eclipse.osgi\62\data\cacheOverlay\com.ibm.ws.app.manager_32\WEB-INF\lib.cache\log4j-1.2.17.jar

D:\WASLiberty\wlp\service\classes\log4j-1.2.17.jar

MDM –

D:\Program Files (x86)\BigFix Enterprise\Management Extender\MDM Provider\work\tsp\webapp\WEB-INF\gems\gems\log4jer-0.0.7\lib\log4j-1.2.16.jar

D:\Program Files (x86)\BigFix Enterprise\Management Extender\MDM Provider\work\tsp\webapp\WEB-INF\gems\gems\mdm-platform-2.4.3\ext\lib\log4j-1.2.16.jar

The last two look like the MaaS360 extender. It’s been long deprecated, you should look into whether it’s still in use and consider removing it.

I’m not familiar with the first two paths

1 Like

Okay, so I did some digging and navigated to the D:\WASLiberty\wlp\usr\servers\defaultServer\server.xml. It says Server Automation REST API Server in the xml. Is that for the BF Server Automation? If so, is there a patch for it?

Please see the screenshot.

Take a look at this … Content in the BigFix Server Automation site has been modified 2021-12-23

2 Likes