Shulou(Shulou.com)06/03 Report--

CVE-2019-1002100 vulnerability

On March 2, 2019, the Kubernetes community released a Kubernetes API server denial of service vulnerability (CVE-2019-1002100), that is, a user with API write access will cause Kubernetes API server to consume resources excessively when writing to resources, and this vulnerability is rated as "moderate severity].

This vulnerability shows that when a user sends a patch pack of json-patch rules to Kubernetes API server to update the resource object (such as kubectl patch xxx-- type json or "Content-Type: application/json-patch+json"), Kubernetes API server consumes a lot of resources, resulting in API server rejecting the connection.

Https://github.com/kubernetes/kubernetes/issues/74534

Scene reproduction

An example of json-patch:

Kubectl patch deployment test-- type='json'-p'[{"op": "add", "path": "/ metadata/labels/test", "value": "test"}, {"op": "add", "path": "/ metadata/labels/app", "value": "test"}, {... }]'

When we frequently send multiple json-patch requests to Kubernetes to update resource objects, we can find that Kubernetes API server consumes a lot of resources to process our requests.

At this time, the patch request of some resources will fail and the response from Kubernetes API server will not be obtained.

Versions of Kubernetes API server affected by this vulnerability include:

V1.0.0-1.10.x

V1.11.0-1.11.7

V1.12.0-1.12.5

V1.13.0-1.13.3

Kubernetes officially recommends that users take mitigation measures for this vulnerability before upgrading to the fixed version:

Remove patch permissions for untrusted users

Vulnerability repair

The Kubernetes community quickly fixed this vulnerability, adding a limit on the number of user json-patch operations.

When a user modifies more than 10000 json-patch operations on a resource object, Kubernetes API server returns an error of 413 (RequestEntityTooLarge).

The error message is as follows:

Request entity too large: The allowed maximum operations in a JSON patch is 10000, got 10004

Kubernetes versions that have been fixed include:

V1.11.8

V1.12.6

V1.13.4

Rancher has released the latest version to deal with this vulnerability.

This time, as always, after the vulnerabilities of Kubernetes itself, the Rancher Labs team responded as soon as possible to ensure the security of users who use the Rancher platform to manage Kubernetes clusters.

If you are using the Rancher platform to manage Kubernetes clusters, don't worry, Rancher has released the latest version today, which supports the Kubernetes version with bug fixes, ensuring that all Rancher users' Kubernetes clusters are not plagued by this vulnerability.

The latest version of Rancher is:

V2.1.7 (Kubernetes v1.11.8, v1.12.6, v1.13.4 support)

V2.0.12 (Kubernetes v1.11.8 support)

For Rancher 1.6.x users, you can use the fix versions v1.11.8 and v1.12.6 released by Kubernetes in the Catalog of Rancher v1.6.26

This vulnerability will affect a wide range of Kubernetes versions, it is recommended that users who have been recruited upgrade as soon as possible!

Escort the user's journey of Docker & K8S

With more than 100 million downloads on the Rancher Kubernetes platform, we are well aware of the importance of security issues to users, not to mention the tens of millions of users who run Docker and Kubernetes in a production environment through the Rancher platform.

CVE-2018-1002105, the first serious security vulnerability exposed by Kubernetes at the end of 2018, was discovered by Darren Shepherd, co-founder and chief architect of Rancher Labs.

When Kubernetes exposed the dashboard and external IP proxy security vulnerability CVE-2018-18264 in January 2019, Rancher Labs was also the first to respond to users, ensuring that all Rancher 2.x and 1.6.x users were completely unaffected by the vulnerability.

The serious runc container escape vulnerability CVE-2019-5736 in February 2019 affected most Docker and Kubernetes users. The Rancher Kubernetes management platform and RancherOS operating system were urgently updated in less than a day. It was the first platform in the industry to urgently release a new version to support Docker patches. It also helped to reverse port the fixes to all versions of Docker and provide them to users. It also provides a fix for the Linux 3.x kernel that is not officially supported by Docker.

Responsible, reliable, rapid response, user-centered, is always the original intention of Rancher; every time there are problems in the industry, rigorous and steadfast to provide users with corresponding solutions, but also Rancher's way of doing things as always. In the future, Rancher will, as always, support and protect users' K8S road to ensure that everyone continues to advance ❤️ safely, safely and safely.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.