Security release of Envoy 1.11.1 is now available

[Piotr Sikora]

Hello Envoy Community,

 

The Envoy security team would like to announce the availability of Envoy 1.11.1.

 

This release addresses the following CVE(s):

 

* CVE-2019-9512 (HIGH severity; CVSS score 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): “Ping Flood”, the attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.

 

* CVE-2019-9513 (HIGH severity; CVSS score 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): “Resource Loop”, the attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service.

 

* CVE-2019-9514 (HIGH severity; CVSS score 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): “Reset Flood”, the attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service.

 

* CVE-2019-9515 (HIGH severity; CVSS score 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): “Settings Flood”, the attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.

 

* CVE-2019-9518 (HIGH severity; CVSS score 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): “Empty Frames Flood”, the attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU, potentially leading to a denial of service.

 

More details about the vulnerabilities are available in the Netflix’s security bulletin: https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md

 

Upgrading to the 1.11.1 release is encouraged to fix these issues.

 

GitHub tag: https://github.com/envoyproxy/envoy/releases/tag/v1.11.1

Docker images: https://hub.docker.com/r/envoyproxy/envoy/tags

Release notes: https://www.envoyproxy.io/docs/envoy/v1.11.1/intro/version_history

Docs: https://www.envoyproxy.io/docs/envoy/v1.11.1/

 

**Am I vulnerable?**

 

Run `envoy --version` and if it indicates a base version of 1.11.0 or older then you are running a vulnerable version.

 

Users using Envoy as a HTTP/2 proxy communicating directly with untrusted peers are vulnerable. Deployments communicating only with trusted HTTP/2 peers (e.g. hosted behind Cloud HTTP load balancers) are not vulnerable, but we still recommend updating them.

 

Users using Envoy as a TCP proxy and/or HTTP/1.1 proxy are not affected.

 

**How do I mitigate the vulnerability?**

 

The vulnerable versions can mitigate those vulnerabilities by disabling HTTP/2 and allowing only HTTP/1.1 by setting http_connection_manager.codec_type to “HTTP1” and removing “h2” from tls_context.common_tls_context.alpn_protocols.

 

Please note that while virtually all HTTP clients can use HTTP/1.1 and HTTP/2 interchangeably, proxying gRPC requires HTTP/2 and it won’t work when HTTP/2 is disabled.

 

**How do I upgrade?**

 

Update to 1.11.1 via your Envoy distribution or rebuild from the Envoy GitHub source at the v1.11.1 tag or HEAD @ master.

 

**Have questions?**

 

Please reach out to us on #envoy-cve at https://envoyproxy.slack.com if you have any further questions.

 

**Thank you**

 

The Envoy security team would like to thank Jonathan Looney of Netflix for discovering, reporting and coordinating industry-wide disclosure of those vulnerabilities. Envoy fixes were developed by Envoy security team members Yan Avlasov and myself.

 

The 1.11.1 Envoy security release was coordinated, reviewed and had additional code contributions from Envoy security team members Matt Klein, Alyssa Wilk and Harvey Tuch.

 

Thanks,

Piotr Sikora (on behalf of the Envoy security team)