Statement on the recent Log4j security vulnerability

Jonathan Yu

 on December 13th, 2021

Updated on January 11th, 2022

2 min read

Late last week, Chen Zhaojun of the Alibaba Cloud Security Team discovered a severe remote code execution vulnerability (CVE-2021-44228). This vulnerability affects many Java applications using the Log4j library. Security researchers at LunaSec (which dubbed the vulnerability Log4Shell), Fastly, and Cloudflare quickly published detailed analyses of the attack and how to mitigate the vulnerability.

While the Coder product does not use Java or Log4j for any of its services, many of the integrated development environments (IDEs) used with Coder, such as JetBrains’ IntelliJ IDEA, GoLand, and PyCharm, do use Java and the Log4j library. Coder’s security model enforces authentication and only permits users to access instances running in their own workspaces. As a result, workspaces running in Coder are unlikely to be affected by this vulnerability. We are working with our upstream vendors to investigate and patch any vulnerable applications to further safeguard against any security risks.

Update: JetBrains has released a statement noting all IntelliJ platform based IDEs and Gateway are not affected.

As a general risk mitigation strategy, we recommend using appropriate ingress and egress firewall rules, as well as Kubernetes network policies, to prevent data exfiltration. Coder uses Kubernetes network policies to prevent workspaces from receiving ingress traffic directly, instead requiring connections to pass through an authenticating proxy, which includes access to IDEs, DevURL services, and tunnelled connections. Coder’s built-in security controls on DevURLs also permit administrators to enforce an installation-wide policy, such as requiring users to be authenticated using the organization’s identity provider.