JFrog Discloses Config Vulnerability in Envoy Proxy Software

A security research team at JFrog, a provider of a continuous integration/continuous delivery (CI/CD) platform, has discovered a vulnerability in certain compression configurations of open source Envoy proxy software that can be used by a distributed denial-of-service (DDoS) attack to disable it.

Shachar Menashe, senior director of security research for JFrog, said that while the configuration vulnerability, known as CVE-2022-29225, is not commonly used, it is dangerous once it’s exploited. The code that is used to decompress user-supplied data does not implement a size limit for the output buffer, allowing the buffering of virtually unlimited amounts of data by accumulating all the extracted data into one large buffer before sending it upstream. An attacker can send a simple small zip file to create a Brotli Zip Bomb that can cause performance issues or crash the Envoy process due to memory exhaustion.

Envoy is designed to enable IT teams to deploy a proxy server without requiring any proprietary hardware. It is used widely within microservices-based cloud-native application environments in addition to being embedded within service meshes such as Istio. The technical oversight committee for the open source Istio mesh is also advising IT teams to upgrade to the version that uses the latest version of Envoy.

The vulnerability has since been fixed in Envoy versions 1.19.5, 1.20.4, 1.21.3 and 1.22.1 and there are also workarounds for organizations that are unable to upgrade.

The CVE-2022-29225 vulnerability JFrog researchers discovered is only the latest in a series of disclosures that are occurring because researchers are taking advantage of, for example, static analysis tools to discover them, said Menashe. Organizations that have implemented DevSecOps best practices can typically find all the instances where these vulnerabilities might impact their organization in a few hours, he added. In contrast, organizations with less mature software development practices might have to spend weeks looking for every instance of a potential vulnerability, noted Menashe.

It’s not clear how quickly organizations have adopted DevSecOps best practices, but an increase in the number of vulnerabilities discovered may finally force the issue. Each time a new vulnerability is disclosed, it doesn’t take too long for cybercriminals to learn how to exploit it. Naturally, not every vulnerability impacts every organization in the same way, but it’s clear that cybercriminals are becoming more efficient at exploiting known vulnerabilities.

Regardless of the severity of the vulnerability, the days when cybersecurity teams aggregated vulnerabilities in a spreadsheet and shared it with an application development team are coming to an end. Development teams are demanding more context before devoting resources to patch vulnerabilities that either might have no impact on applications or, as in the case of CVE-2022-29225, might only impact use cases involving a very specific configuration. The expectation is that, at the very least, cybersecurity teams should be able to prioritize vulnerabilities according to actual severity.

It may be a while before all the cultural issues that need to be addressed to achieve that goal are worked out within most organizations, but the sooner they are resolved the better.

Avatar photo

Michael Vizard

Mike Vizard is a seasoned IT journalist with over 25 years of experience. He also contributed to IT Business Edge, Channel Insider, Baseline and a variety of other IT titles. Previously, Vizard was the editorial director for Ziff-Davis Enterprise as well as Editor-in-Chief for CRN and InfoWorld.

mike-vizard has 759 posts and counting.See all posts by mike-vizard

Secure Guardrails