Help Center/ Cloud Container Instance/ User Guide/ Security Vulnerability Responses/ CVE-2020-8558 Vulnerability Notice
Updated on 2024-07-04 GMT+08:00
View PDF
Share

CVE-2020-8558 Vulnerability Notice

The CCI team fully noticed the kube-proxy security vulnerability CVE-2020-8558 on July 10. After detailed analysis, it is found that the vulnerability has no impact on users and CCI services, and does not need to be handled.

Vulnerability Details

Kubernetes officially released security vulnerability (CVE-2020-8558) which allows adjacent hosts to access Kubernetes nodes running on the local host.

For example, if a Kubernetes cluster runs a service on a node that listens on 127.0.0.1, because of this bug, the service will be potentially reachable by other hosts on the same LAN as the node, or by hosts on a Layer-2 network. In this way, the port information is obtained. If the example service on the port requires no additional authentication, the service is vulnerable to attacks.

Reference link:

https://github.com/kubernetes/kubernetes/issues/92315

Root Cause

This issue was originally raised by setting net.ipv4.conf.all.route_localnet=1 for kube-proxy. This setting causes the system not to reject traffic that originates on other hosts to the local host.

How Do I Determine Whether a Vulnerability Is Involved?

  • Affected cluster versions are used:
    • kubelet/kube-proxy v1.18.0-1.18.3
    • kubelet/kube-proxy v1.17.0-1.17.6
    • kubelet/kube-proxy v1.16.10 or earlier
  • Your cluster nodes run in an environment where untrusted hosts share the same Layer-2 domain (for example, same LAN) as the cluster nodes.
  • Your cluster allows untrusted pods to run containers with CAP_NET_RAW (Kubernetes clusters allow this capability by default).
  • Your nodes (or pods that use the host network) run localhost services which do not require any further authentication.

For more information, see Am I vulnerable?

Vulnerability Analysis Results

Based on the preceding analysis, CCI is not affected by the vulnerability because:

  • CCI underlying clusters are based on Kubernetes v1.15. However, the kube-proxy component uses self-developed code and does not involve the setting net.ipv4.conf.all.route_localnet=1.
  • The network model of CCI underlying clusters is different from that of common Kubernetes clusters. CCI uses secure containers and is deeply integrated with Huawei Cloud networking services. Your VPC network and the CCI host network are not in the same Layer-2 domain. There is no information leakage risk at the CCI side.
  • By default, net.ipv4.conf.all.route_localnet is set to 0 in the service container kernel. The process bound to localhost cannot access other nodes in the same VPC. There is no information leakage risk at the user side.