Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to interpret K8S vulnerability CVE-2019-1002101

2025-04-11 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

How to interpret K8S vulnerability CVE-2019-1002101, it is believed that many inexperienced people have no idea about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Kubectl cp vulnerability

Recently, kubernetes's kubectl cp command found a security problem (CVE-2019-1002101), which is more serious. It is recommended that you upgrade kubectl to Kubernetes 1.11.9, 1.12.7, 1.13.5 or 1.14.0 to solve this problem.

The kubectl cp command allows the user to copy files between the container and the host, the basic principle of which is:

Package the file at the source address.

The packaged output is delivered to the destination address over the network as a stream stream.

Delivery paths include: apiserver, kubelet, runtime

The stream stream is decompressed at the destination address as input to the tar.

The specific implementation process can refer to the two functions copyToPod and copyFromPod in the kubernetes/pkg/kubectl/cmd/cp.go file.

In the process, if the tar binary in the container is malicious, it can run any code and output unexpected malicious results. When kubectl cp is called, an attacker can use it to write files to any path on the user's computer, subject only to the system privileges of the local user.

At present, the community has fixed this problem in version 1.11-1.14. For more information on how to fix it, please see:

Https://github.com/kubernetes/kubernetes/pull/75037

Users can view the version of kubectl they are using with the kubectl version-- client command and upgrade to version 1.11.9, 1.12.7, 1.13.5 or 1.14.0 to fix this vulnerability.

Kube-proxy IPVS add flag ipvs-strict-arp

First of all, get some background knowledge.

Kube-proxy 's ipvs mode binds clusterIP/externalIP, etc., to a dummy device named kube-ipvs0 on the node to ensure that ipvs rules on the node can forward traffic accessing these addresses.

In version 1.13, an operation was introduced

Echo 1 > / proc/sys/net/ipv4/conf/all/arp_ignore

Echo 2 > / proc/sys/net/ipv4/conf/all/arp_announce

To disable ARP replies to ip bound to kube-ipvs0 dummy devices in IPVS mode, please see pr # 70530. This change is to fix the problem that load banlancer type service cannot be used properly in ipvs mode (issue:#59976).

This buf fix is related to the previous changes, because the previous changes solve the problem of loadbalancer, but introduce other problems: some CNI plug-ins use the ARP protocol for the connection between the host and the container. So we see that some users have reported the following problems after upgrading to 1.13:

Issue#72779:kube-proxy v1.13.0 and 1.13.1 brokes services with externalIPs

Issue#71555:kube-proxy/IPVS: arpignore and arpannounce break some CNI plugins

And this bug fix is also very simple, is to add a startup parameter ipvs-strict-arp for kube-proxy, the default is 0, that is, does not change the ARP configuration on the node, if you need to change, then set the parameter value to 1.

I have to say that this is just an evasion scheme, and some functions in kube-proxy ipvs mode are affected regardless of whether this parameter is used or not.

But the IPVS pattern itself has its unique advantages, which iptables does not have. On the basis of these advantages, it seems unreasonable for ipvs to achieve all the functions of the original iptables.

Analysis of recent bug fix data

Recently, there is no important bug fix release in the 1.13 version (after 1.13.5) we follow, and a few are related to cluster deployment, third-party cloud providers, and e2e testing, which do not require much attention.

The CVE-2019-1002101 vulnerability mentioned earlier has also been fixed before version 1.13.5, and the last bug fix has been covered. If you are interested in further research, you can learn according to the pr link provided in this article.

Finally, let's take a look at the specific data:

The following is a summary of all bug fix:

After reading the above, have you mastered how to interpret the K8S vulnerability CVE-2019-1002101? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report