{"id":104491,"date":"2019-12-19T20:15:01","date_gmt":"2019-12-20T04:15:01","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=104491"},"modified":"2019-12-20T06:22:49","modified_gmt":"2019-12-20T14:22:49","slug":"cloud-envoy-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www2.paloaltonetworks.com\/blog\/2019\/12\/cloud-envoy-vulnerabilities\/","title":{"rendered":"Recent Vulnerabilities in Envoy Explained, Including Impact to Istio"},"content":{"rendered":"

On Dec. 10, three vulnerabilities in the <\/span>Envoy proxy<\/span><\/a> were made public, one of which was classified as \u201chigh severity\u201d and two as \u201cmedium severity,\u201d affecting all versions up to and including Envoy 1.12.1.\u00a0\u00a0<\/span><\/p>\n

Istio, which relies on Envoy, is also directly affected by these issues. The vulnerabilities may affect many Kubernetes deployments using Envoy, including many that are managed by cloud providers. On Dec. 13, Google issued an email alert to all its Google Kubernetes Engine (GKE) users, urging them to upgrade all Envoy instances in their clusters. In this article, I will shed more light on these three issues, their impact and how they were fixed. I\u2019ll also present a proof-of-concept video of a full bypass of Envoy rules.\u00a0<\/span><\/p>\n

Before diving into the details, let\u2019s go over the fundamentals of the affected components:<\/span><\/p>\n

Service Mesh\u00a0<\/b><\/p>\n

A service mesh is a transparent software infrastructure layer designed to improve networking between microservices. The service mesh ensures communication is fast, reliable and secure. It provides useful capabilities such as load balancing, traceability, encryption and more.<\/span><\/p>\n

Envoy<\/b><\/p>\n

Envoy is a high-performance proxy designed for cloud-native applications. It was originally developed by the engineers at Lyft, and it grew to become open sourced and graduated to be a Cloud Native Computing Foundation (<\/span>CNCF<\/span><\/a>) project. Additionally, it is a key component in the most popular service mesh \u2013 Istio.<\/span><\/p>\n

Istio<\/b><\/p>\n

Istio is a service mesh, originally developed by Google, IBM and Lyft. It uses Envoy as a sidecar proxy, which means every microservice or pod has an Envoy running beside it and all the communication in the cluster goes through these sidecar components.<\/span><\/p>\n

CVE-2019-18838 \u2013 Denial of Service and Potentially Other Issues<\/b><\/p>\n

Envoy can be customizable with different encoding filters. <\/span>If it is configured with an encoder, containing a specific router manager API call, and it receives an HTTP request without the \"<\/span>Host<\/span>\" header, it will send back an \"Invalid request\" response. This response is dispatched through the configured encoder filter chain before being sent to the client. If an encoder filter access requests \"<\/span>Host<\/span>\" header, it will cause a NULL pointer to be dereferenced and result in abnormal behavior of Envoy.<\/span><\/p>\n

It may cause Envoy to fail and crash, but under certain circumstances, an attacker may be able to craft an exploit even more dangerous and execute code on Envoy instances.<\/span><\/p>\n

CVE-2019-18801 \u2013 Heap Overflow<\/b><\/p>\n

Envoy can be configured to accept HTTP 1, and while doing so, it assumes that all the HTTP header value sizes are less than 4KB. However, in HTTP 2 there are no restrictions on the size of the values, and as a result, untrusted input can overflow the buffer allocated for the encoding of the headers and crash Envoy.<\/span><\/p>\n

So far, an RCE exploit was not published, but a proof-of-concept exists in which two malicious requests are able to result in bypassing Envoy\u2019s access control.<\/span><\/p>\n

CVE-2019-18802 \u2013 Policy Bypass and Potentially Other Issues<\/b><\/p>\n

The security problem here is that Envoy\u2019s parser incorrectly fails to trim whitespace after the HTTP header value. This can result in many security issues like policy bypass, privilege escalation or information disclosure. For example, <\/span>one of Envoy\u2019s features is the ability to reject HTTP requests by filtering the hostname header. The problem is that <\/span>Envoy will treat \u201cforbiddenSite[.]com \u201d\u00a0 as a different string from \u201cforbiddenSite[.]com\u201d (notice the space character after the dot com) and forward the request instead of denying it. After that, the HTTP server will trim the whitespace to send a response.<\/span><\/p>\n

Proof of Concept<\/b><\/p>\n

\n
\n