{"id":102658,"date":"2019-10-16T05:40:08","date_gmt":"2019-10-16T12:40:08","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=102658"},"modified":"2021-01-15T14:51:04","modified_gmt":"2021-01-15T22:51:04","slug":"cloud-kubernetes-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www2.paloaltonetworks.com\/blog\/2019\/10\/cloud-kubernetes-vulnerabilities\/","title":{"rendered":"Analysis of Two Newly Patched Kubernetes Vulnerabilities"},"content":{"rendered":"

By Ariel Zelivansky and Aviv Sasson<\/span><\/p>\n

 <\/p>\n

The Kubernetes Patch Release Team on Tuesday released new builds that patch Kubernetes vulnerabilities CVE-2019-16276 and CVE-2019-11253, which have been publicly disclosed over the past month. These vulnerabilities have the potential to be highly dangerous under some Kubernetes configurations.\u00a0<\/span><\/p>\n

We highly recommend <\/span>upgrading to Kubernetes builds<\/span><\/a> 1.14.8, 1.15.5 or 1.16.2, regardless of your Kubernetes configuration.<\/span><\/p>\n

Here is an overview of the now-resolved issues:<\/span><\/p>\n

 <\/p>\n

CVE-2019-16276, or HTTP Protocol Violation in Go\u2019s net\/http Library<\/b><\/p>\n

This vulnerability has its roots in the Go language\u2019s standard HTTP library, net\/http. The library is used for HTTP request parsing in Kubernetes. Its implementation normalized invalid HTTP requests in a way that caused a potential danger for Kubernetes.<\/span><\/p>\n

HTTP requests are comprised of a field-name, followed by a colon, then its value. Per the HTTP\/1.1 <\/span>specification<\/span><\/a>, no whitespace is allowed between the header\u2019s field-name and colon. As mentioned in the <\/span>GitHub issue<\/span><\/a> of this problem, the net\/http library interpreted headers with this whitespace the same as valid headers, in violation of the HTTP RFC.<\/span><\/p>\n

This seemingly innocent problem becomes dangerous when a Go server relying on the library is used in combination with a reverse proxy that filters request headers. The proxy may ignore invalid headers, but forward them to the Go server, which would interpret these headers as valid.<\/span><\/p>\n

For example, if a reverse proxy server is used for authentication, attackers could exploit this bug to authenticate as any user by crafting an invalid header that would go through to the server.<\/span><\/p>\n

This scenario is not at all hypothetical. The Kubernetes API server can be configured to work with an <\/span>Authenticating Proxy<\/span><\/a> and identify users through request headers. Such a proxy may be used to allow users to authenticate to the API server using an existing SSO scheme, or other access control configurations.<\/span><\/p>\n

To exploit the attack, assuming <\/span>X-Remote-User<\/span> is used as the identifying user field for the API server, an attacker may send the following request to the proxy:<\/span><\/p>\n

X-Remote-User : admin<\/span><\/p>\n

If the proxy is designed to filter <\/span>X-Remote-User<\/span> headers but doesn\u2019t recognize the header because it\u2019s invalid and forwards it to the Kubernetes API server, the attacker would successfully pass the API request with the roles of the \u201cadmin\u201d user.<\/span><\/p>\n

The diagram below demonstrates how such an attack may take place.<\/span><\/p>\n

\"This<\/span><\/div><\/p>\n

In this case, the proxy is highly naive. It both accepts anonymous connections and forwards invalid headers. The attacker sends a malicious request with an invalid header with including a whitespace. The API server accepts this header and performs the attacker\u2019s requests with Bob\u2019s roles. Of course, the details of an actual exploit would rely on the implementation of the proxy server.<\/span><\/p>\n

On the bright side, we were unable to find any open-source authenticating proxy that is commonly used. Using an authenticating proxy is a niche configuration, and special flags need to be passed to the API server to enable it. If your Kubernetes setup does use an Authenticating Proxy, make sure to upgrade immediately, especially because exploitation of this problem is very simple.<\/span><\/p>\n

CJ Cullen from the Kubernetes Security Committee published a <\/span>security advisory<\/span><\/a> on this issue. The new releases were built with the fixed Go version (Go 1.12.10), rendering them immune to this attack.<\/span><\/p>\n

 <\/p>\n

CVE-2019-11253, or Kubernetes YAML Parsing Vulnerable to DoS<\/b><\/p>\n

In an unusual manner, the discovery of this vulnerability was made by a curious Kubernetes user over a <\/span>Stack Overflow question<\/span><\/a>. The user found that the Kubernetes API server was vulnerable to a specific kind of attack on YAML parsers called YAML bomb attack. The attack, sometimes dubbed \u201c<\/span>Billion laughs attack<\/span><\/a>\u201d for historical reasons, intends to crash the YAML parser by exponentially loading it with references. The user worried how such an attack could be prevented to protect his API server.<\/span><\/p>\n

The original exploit attached to the question is shown below.<\/span><\/p>\n

\"This<\/span><\/div><\/p>\n

Rory McCune, a Stack Overflow user, realized that the fact this attack works is a potentially dangerous vulnerability in Kubernetes, and directed it to the Kubernetes security team. The security team suggested publishing the details of this vulnerability on its own <\/span>GitHub issue<\/span><\/a>, since the details of this attack were already public.<\/span><\/p>\n

Although the CVE was assigned to Kubernetes, and a <\/span>patch<\/span><\/a> was released to its source, the real culprit of this vulnerability is the YAML parser library that enabled this attack. Fortunately, another <\/span>patch<\/span><\/a> was written to resolve this problem at the go-yaml library level, preventing this attack in other projects that rely on its code.<\/span><\/p>\n

After we experimented with exploitation of this vulnerability, we determined it should be considered high severity. Any user or container with roles that allow delivering YAML to the API server may crash it. Although it may be brought up depending on its restart policy and restart limit, the attacker may abuse the attack and deliver it continuously.<\/span><\/p>\n

We recommend reviewing each role given to users, pods or anonymous users to determine if it is required, especially if it allows sending POST requests with a YAML file.<\/span><\/p>\n

 <\/p>\n

Fixed Releases<\/b><\/p>\n

Kubernetes releases <\/span>1.14.8<\/span><\/a>, <\/span>1.15.5<\/span><\/a> and <\/span>1.16.2<\/span><\/a> include the fixes to these issues. We recommend that you update clusters to the safe versions regardless of your configuration.<\/span><\/p>\n

We would like to thank Jordan Liggitt from the Kubernetes release team for directing us to the correct releases.<\/span><\/p>\n

Learn more about our previous research on Kubernetes vulnerabilities<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

We highly recommend upgrading to Kubernetes builds 1.14.8, 1.15.5 or 1.16.2 to address two recently patched Kubernetes vulnerabilities. <\/p>\n","protected":false},"author":663,"featured_media":102691,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[6768],"tags":[6731,515],"coauthors":[6875,6869],"class_list":["post-102658","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-secure-the-cloud","tag-kubernetes","tag-vulnerabilities"],"jetpack_featured_media_url":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-content\/uploads\/2019\/10\/Possible-Kubernetes-image.1.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/102658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/users\/663"}],"replies":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/comments?post=102658"}],"version-history":[{"count":5,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/102658\/revisions"}],"predecessor-version":[{"id":102690,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/102658\/revisions\/102690"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/media\/102691"}],"wp:attachment":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/media?parent=102658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/categories?post=102658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/tags?post=102658"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/coauthors?post=102658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}