【独家】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命令允许用户在容器和主机之间复制文件，其基本原理是：

在源地址将文件打包。

打包输出内容作为stream流通过网络传递给目标地址。

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

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