CVE-2018-1002105 bug的描述中说到是k8s apiserver在处理代理请求时会留下易受攻击的TCP连接。这将导致前端请求能够跨过ApiServer直接请求到服务后端，从而留下安全隐患。这篇文章中，我们将分析这个漏洞到底是怎么回事。
关于CVE-2018-1002105更多信息可以查看这个链接。
请求代理
首先说请求代理。在k8s中，请求代理是一个非常常见的模式：apiserver将来自前端的请求转发到后端服务处理，并将后端的响应返回给前端。
典型的应用是kube-aggregator。kube-aggregator提供了API用于向k8s集群注册其他的apiserver，kube-aggregator负责处理api发现以及客户端请求代理。metrics-server就是一个典型的基于kube-aggregator的apiserver。metrics-server基于heapster项目演化而来，为k8s集群提供了node/pod性能数据。更多关于metrics-server的分析可以看这篇文章。
http upgrade
请求代理部分是本次bug的主角，具体来说是涉及到http upgrade。
首先我们了解一下http upgrade。upgrade是http/1.1提供协议升级接口，让客户端和服务端可以协商使用其他的协议通信，例如https/websocket等。
- 当客户端向服务端发起upgrade请求，请求头包含upgrade及希望升级的协议，如下所示: OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade
- 服务端接受升级请求，返回101 Switching Protocol响应，如下所示: HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1 Connection: Upgrade
- 服务端发送响应后，切换到新的协议。
- 客户端再通过当前连接通过新的协议发送请求。 更多关于upgrade的信息可以在RFC2817找到。
在apiserver请求代理的过程中，客户端通过自身的请求认证的方式连接apiserver，apiserver通过证书连接其他的apiserver（如metrics-server）。所以，客户端与服务后端并不直接通信，而是交由apiserver负责转发。我们看k8s中的upgrade proxy实现。
tryUpgrade函数(k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go)负责处理upgrade请求的转发，其执行流程描述如下： 1、判断是否是upgrade请求，如果不是直接返回 2、连接服务后端，获取连接对象backendConn 3、Hijack http请求，操作底层的tcp buffer 4、双向代理数据：将request中读取的内容写入backend读取buffer，将backend写出的内容写入到request的写出buffer。 5、关闭相关连接
贴一些核心代码：
go func() {
var writer io.WriteCloser
if h.MaxBytesPerSec > 0 {
writer = flowrate.NewWriter(backendConn, h.MaxBytesPerSec)
} else {
writer = backendConn
}
_, err := io.Copy(writer, requestHijackedConn)
if err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
glog.Errorf("Error proxying data from client to backend: %v", err)
}
close(writerComplete)
}()
go func() {
var reader io.ReadCloser
if h.MaxBytesPerSec > 0 {
reader = flowrate.NewReader(backendConn, h.MaxBytesPerSec)
} else {
reader = backendConn
}
_, err := io.Copy(requestHijackedConn, reader)
if err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
glog.Errorf("Error proxying data from backend to client: %v", err)
}
close(readerComplete)
}()
这里存在的安全问题是代码中并没有判断客户端向后端服务发送upgrade请求后后端服务的响应，而是直接默认返回是SwitchingProtocols响应，之后直接将客户端的请求发送给后端服务，并将后端服务的响应返回给客户端。这样就存在一种可能性，客户端可以构造一个upgrade请求，让后端服务不进行协议的切换，然后再发送正常的其他http请求，这样后端服务将认为是来自于apiserver的正常请求，将可以绕过k8s的各种安全机制直接获取后端服务的响应。
因而，在后期的修复中，主要的逻辑也是提前判断upgrade请求的响应是否是SwitchingProtocols，如果不是，则关闭连接，不代理接下来的数据传输。代码如下所示：
if rawResponseCode != http.StatusSwitchingProtocols {
// If the backend did not upgrade the request, finish echoing the response from the backend to the client and return, closing the connection.
glog.V(6).Infof("Proxy upgrade error, status code %d", rawResponseCode)
_, err := io.Copy(requestHijackedConn, backendConn)
if err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
glog.Errorf("Error proxying data from backend to client: %v", err)
}
// Indicate we handled the request
return true
}
Bug的影响
在k8s框架中，只要使用到这段代理逻辑的模块都将受到影响，kube-aggregator是肯定的。其他还包括:
- kubectl proxy命令将创建一个本地到apiserver的proxy server。
- kubelet 在处理来自客户端的attach/exec/portforward请求时，创建了一个upgrade proxy来转发相应的数据流。
