A new vulnerability in an open-source software component, polkit, emerged this week, to a lot of publicity (in which it has been named “PwnKit”). This vulnerability is present in Linux distributions going back more than a decade, so the scope is broad. With Log4j issues still fresh in our minds there have been questions about how this affects VMware customers, and we hope to answer those here.
First, some context. Context is always important because all organizations and implementations are different. Reactions need to differ based on the details, and not necessarily the CVSS (Common Vulnerability Scoring System) score. CVE-2021-4034 has a CVSS score of 7.8, meaning that it is labeled “Important” by default.
This vulnerability is a local vulnerability so an attacker would need to be logged into the affected system or be able to execute commands on the affected system remotely. The affected binary is pkexec (usually /usr/bin/pkexec) which is “setuid” meaning that when someone runs pkexec, Linux will execute the pkexec binary as the user that owns the file. In this case that’s root, which is the problem, because the root user can do everything.
How does this affect VMware products?
Polkit is part of the Photon OS Linux distribution that VMware appliances use, but it is not a standard component on the appliances. Appliances are shipped with a minimal software footprint. Polkit is not part of ESXi, either. These are the main reasons why there has not been a VMware Security Advisory. We do not issue advisories for vulnerabilities that don’t affect VMware products.
VMware products are delivered & supported as whole appliances. They are not general-purpose servers. The distribution model is more akin to network switch firmware than a Linux server. In fact, when customers enter VMware products in their Configuration Management Databases, we often suggest they list the operating systems as “VMware vCenter Server” or “VMware NSX-T” rather than simply “Linux.” The whole appliance is the product, an atomic unit that is distributed, upgraded, and patched as one.
The shell interface on a VMware appliance, either via the console or SSH, is a support and troubleshooting interface. VMware products differ but in general these interfaces are disabled by default, and only meant to be enabled by customers when support or troubleshooting activity is occurring. The population of people within an organization that can log into the appliance shells on VMware products should be small, limited to virtualization admins. This limits the scope of CVE-2021-4034. Furthermore, those troubleshooting interfaces are already privileged, meaning that an attacker who can log in with that level of access will not need to exploit a vulnerability for further access.
VMware has a software development lifecycle which includes user experience design, documentation, reviews, testing, and coordination with partners. We will interrupt this cycle to issue an out-of-cycle patch if a new issue appears which is classified as critical or found by the VMware Security Response Center to be critical to a product. This includes open-source components. All other issues are resolved on a regular basis as part of the product development and release process, so that proper design, testing, documentation, and partner coordination can occur. The three core tenets of information security are confidentiality, integrity, and availability, and we do not want to endanger one tenet, like availability, in improving confidentiality.
In the case of CVE-2021-4034, given the vulnerability classification and CVSS score at this time, the scope of the problem, the fact that it isn’t present on appliances, and considering the context of our products and how they are used and supported, the resolution to this will be part of a future patch releases. Customers of hosted environments and VMware Cloud on AWS will see any necessary updates as part of regular maintenance notifications, and folks with on-premises deployments should continue to keep current with updates as they appear.
As with Log4j, CVE-2021-4034 has a scope much larger than just VMware products. Working through your organization’s asset inventory to see what might be affected is prudent, and mitigating or patching systems that allow shell access or remote execution is important.
We always recommend that customers subscribe to the VMware Security Advisory mailing list. Security advisories are issued for vulnerabilities that impact VMware products, and the mailing list is used solely for notifications of those. You can find the subscription form on the right side of https://www.vmware.com/security/advisories.html.
Much of the conversation in this post overlaps with our ongoing efforts to help customers become more resilient to attacks and other incidents through increasing defense-in-depth and improving processes. You can find a lot of our thinking about this at https://core.vmware.com/ransomware including practical guides to environment hardening, tips for patching, and more.
VMware appreciates your security-mindedness and looks forward to the future with you. If you have questions or feedback, please reach out to your account teams. They will answer questions and make sure feedback gets to the right place to make our products and processes better. Thank you!