Four newly discovered vulnerabilities in the Envoy proxy are the reason for another Istio security update. Version 1.4.6 of the service mesh should protect users from possible access control and resource consumption issues.

Since Istio uses Envoy to handle ingress and egress traffic between services, issues in the proxy always affect the mesh project. This time, the mitigated vulnerabilities fall into the categories of access breaches and memory consumption. For one, the TLS inspector in Envoy was discovered to be bypassable by clients only using TLS 1.3, which could lead to them being “matched to a wrong filter chain, possibly bypassing some security restrictions”.

The other access issue is down to update callbacks only being called in the SDS TLS validation context when a secret is either received for the first time or when its value changed. According to the Istio team, “this leads to a race condition where other resources referencing the same secret (e.g,. trusted CA) remain unconfigured until the secret’s value changes, creating a potentially sizable window where a complete bypass of security checks from the static (‘default’) section can occur”.

While these vulnerabilities “only” score a 5.3 on the severity scale, CVE-2020-8659 and 8861 CVSS scores of 7.5 make them comparatively more impactful. The first may see the Envoy proxy consuming “excessive memory when proxying HTTP/1.1 requests or responses with many small (i.e. 1 byte) chunks” leading to a memory overhead larger than the configured buffer limits if a peer is slow to read proxied data. Since the proxy is used to allocate buffer space rounded to the nearest 4Kb for each incoming and outgoing chunk, without freeing up empty ones after data is committed, the result can be quite severe.

Meanwhile CVE-2020-8661 can cause disproportionate memory consumption when responses for pipelined HTTP/1.1 requests are in order. Illegally formed requests lead to the proxy sending an 400 error to the Network::Connection buffer, which can lead to problems when the client reads responses only slowly. And of course Envoy itself has an overload manager, that also generates responses when a memory threshold is exceeded, which doesn’t help in the matter.

More details about the vulnerabilities should pop up in the CVE list in the coming weeks, as per usual.

If any of the problems mentioned is reason enough to finally make the jump onto the 1.4.x series of the project, a quick glance at the upgrade notes is recommended, since it introduced some traffic and config management changes.