Cloud Foundry Advisory Board Call, Dec 2021: The Log4j Vulnerability

The final Cloud Foundry Community Advisory Board (CAB) meeting for 2021 featured a few updates from the foundation and an overview of the recent Log4j vulnerability. The call was moderated by Ram Iyengar from the CF Foundation.

Log4j’s exposure to data leak

On Friday, December 10, 2021, a critical vulnerability in Apache Log4j identified by CVE-2021-44228 was publicly disclosed. Log4j is a library that is widely adopted as a logging framework for Java. Log4j versions prior to 2.16.0 were subject to a remote code vulnerability via the LDAP JNDI parser, resulting in information leak and remote code execution in some environments and local code execution in all the environments.

Mitigating the Log4j vulnerability (Image credit)

According to Ram, the Vulnerability Management working group (WG) was able to quickly identify six points of vulnerabilities affecting Cloud Foundry products. These include:

• UAA
• CredHub
• cf-for-k8s
• cf-deployment
• PHP buildpack
• Java buildpack

To mitigate the vulnerability, the Foundation recommends upgrading the following releases:

• UAA to 75.12.0 or higher
• CreHub to 2.11.0 or higher
• cf-for-k8s to 5.4.1 or higher
• cf-deployment to 17.1.0 or higher
• PHP buildpack to 4.4.53 or higher
• Java buildpack to 4.45 or higher

Some members of the community shared their experiences dealing with the vulnerability right after it was initially disclosed on December 10. Peter Burkholder of GSA’s Cloud.gov appreciated the rate of patches addressing the security issue.

Peter Burkholder

“I first heard about this on Friday morning, US East Coast Time. Even though I had no evidence that we were being attacked, we immediately declared a potential incident, since we knew that UAA, CredHub, and some other components we run might be vulnerable. It was gratifying that we had tools within our deployment process to use as operators to set the initial property value that you could pass to JVMs…we were able to get ourselves to a pretty good position before the end of the day. We’re just very pleased with the speed of which the patches have come out of the community, and the attention you have all paid to it.” —Peter Burkholder, GSA (Cloud.gov)

Since the Log4j vulnerability linked to the PHP buildpack only affected deployments running AppDynamics, Bret Mogilefsky of GSA’s Technology Transformation Services (TTS), suggested that future security updates from the CF Foundation should be more explicit to avoid confusion. “I do have PHP applications that were not on my radar at all as being affected,” he explained. “When I saw that PHP buildpack was affected, I went into high alert thinking I was affected.”

Bret Mogilefsky

“One thing that could help when releasing updates for things like that, be explicit about what might put you into a category to be susceptible to the vulnerability…The release notes for remediation should say we’ve remediated the vulnerability for Log4j, but also this is how you can tell if your applications were affected, because in this case, it was an optional piece of code that was not invoked, unless you have an AppsDynamics service available, deployed, and bound to the platform.” —Bret Mogilefsky, GSA (TTS)

In addition, Peter also shared a tweet that may provide VMware Tanzu operators with a quick method to mitigate the security vulnerability while running Log4j versions 2.10 and above.

Anyone interested in the ongoing development regarding the Log4j security vulnerability can check out the details via Apache’s website.

Log4j’s GitHub

Foundation updates

With the ongoing initiative to adopt working groups, the Community Management WG has been changed to Service Management. The new working group aims to provide interfaces for service life cycle within application platforms and adapters to common external service providers.

Ram Iyengar

During the call, Ram noted a push from the community for all working groups to adopt an open roadmap to provide even more transparency.

“Going forward, everybody can start consuming and contributing to the roadmap of each of the different working groups and have more of a say in steering the way working groups are putting out solutions in general.”

—Ram Iyengar, Cloud Foundry Foundation

The first CAB call for next year is tentatively scheduled on January 19, 2022, at 11 a.m. ET / 8 a.m. PT. Anyone interested in participating can join the Cloud Foundry’s CAB Slack channel.