【独家】K8S漏洞报告 | CVE-2019-1002101解读

kubectl cp漏洞CVE-2019-1002101分析

Kube-proxy IPVS添加flag ipvs-strict-arp

近期bug fix数据分析

——本期更新内容 

 

 

kubectl cp漏洞

近期kubernetes的kubectl cp命令发现安全问题(CVE-2019-1002101)，该问题严重程度比较高，建议将kubectl升级到Kubernetes 1.11.9,1.12.7,1.13.5或1.14.0版本以解决此问题。

kubectl cp命令容许用户在容器和主机之间复制文件，其基本原理是：

1. 在源地址将文件打包。

2. 打包输出内容做为stream流经过网络传递给目标地址。

3. 传递路径包括：apiserver、kubelet、runtime

4. stream流在目的地址做为tar的输入，解压。

具体执行过程能够参考kubernetes/pkg/kubectl/cmd/cp.go文件中的copyToPod和copyFromPod两个函数。

在这个过程当中，若是容器中的tar二进制文件是恶意的，它能够运行任何代码并输出意外的恶意结果。当调用kubectl cp时，攻击者可使用它将文件写入用户计算机上的任何路径，仅受本地用户的系统权限限制。

目前社区在1.11-1.14版本均修复了该问题，具体修复方式可参考：

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

用户能够经过kubectl version --client命令查看本身使用的kubectl版本，并升级到1.11.9,1.12.7,1.13.5或1.14.0版本以修复该漏洞。

 

Kube-proxy IPVS添加flag ipvs-strict-arp

首先了解些背景知识。

kube-proxy的ipvs模式会将clusterIP/externalIP等绑定到节点上名为kube-ipvs0的dummy设备，以确保节点上的ipvs规则能够对访问这些地址的流量做转发。

在1.13版本中，引入一个操做

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

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

以禁止IPVS模式下对kube-ipvs0 dummy设备上绑定的ip的ARP回复，具体可参考pr #70530，该改动是为了修复ipvs模式下load banlancer类型service不能正常使用的问题(issue:#59976)。

而本次的buf fix则是跟前面的改动有关，由于前面的改动虽然解决了loadbalancer的问题，可是又引入了其余问题：有些CNI插件在主机和容器间的链接会用到ARP协议。所以咱们看到有些用户升级到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

而本bug fix也很简单，就是为kube-proxy加了一个启动参数ipvs-strict-arp，默认为0，即不改变节点上的ARP配置，若是须要改变，则设置该参数值为1。

不得不说，这只是一个规避方案，不管是否使用该参数，kube-proxy ipvs模式下总有一部分功能受影响。

可是IPVS模式自己就有它独特的优点，是iptables所没有的，在这些优点的基础上，必定要ipvs实现原来iptables实现的全部功能彷佛也不太合理。

 

近期bug fix数据分析

近期在咱们关注的1.13版本(1.13.5以后)没有比较重要的bug fix发布，为数很少的几条也都是集群部署、第三方云提供商、e2e测试相关，不须要太多关注。

前文提到的CVE-2019-1002101漏洞也是在1.13.5版本以前已经修复的，上次的bug fix已经覆盖到，你们若是有兴趣深刻研究的话能够根据本文提供的pr连接学习。

最后咱们看下具体数据：

以下为全部bug fix的汇总信息：

 

相关服务请访问：https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019