''' We've discovered a privilege escalation issue in the OpenShift platform.
Conditions for the privilege escalation: - a user must be granted the ability to "update, patch" the "pods/ephemeralcontainers" subresource - by default, NEITHER common users NOR Service Accounts are granted this permission by the platform - with the above permission, a user is able to patch a running pod they've got access to and bypass SCC admission - this means, a user can create a "privileged" container, which allows them obtaining access to the pod's node resources
The step-by-step reproducer is described in https://issues.redhat.com/browse/OCPBUGS-7181.
Affected OpenShift Container Platform versions: 4.10 and newer. Affected component: kube-apiserver (and the platforms that use it)
The bug is located within the apiserver-library-go repository in the following module: https://github.com/openshift/apiserver-library-go/tree/master/pkg/securitycontextconstraints. We are yet to determine how to fix it.
The workaround is to remove the permissions to "update, patch" the "pods/ephemeralcontainers" subresource from any low-privileged users, if there are any that currently hold it. '''
From Stanislav Láznička
Summary: Possible DOS in SPDY streaming code, used for attach, exec and port forwarding.
Requirements To Exploit: Access to the kubelet's endpoint (granted through nodes/proxy) or access to any of portforward, exec, or attach to pods. These all can be represented by the cluster roles
pods/portforward (create)
pods/exec (create)
pods/attach (create)
nodes/proxy (get/create)
Component Affected: Kubelet, CRI-O, kube-apiserver
Version Affected: Openshift 4.21.4 and below
Patch Available: yes
Version Fixed: none yet
Cvss: (Based on [https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]). Please note that only the Base Score Metrics are required by the incident response team.
Impact: Based on the https://access.redhat.com/security/updates/classification , what do you think would be the impact and why? This helps a lot the analyst to understand why such a report must be or not considered Moderate/Important or even Critical.
Steps To Reproduce: apply:
— apiVersion: v1 kind: ServiceAccount metadata: name: poc-sa-portforward namespace: default — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: Role metadata: name: poc-role-portforward namespace: default rules:
apiGroups: [""] resources: ["pods/portforward"] verbs: ["create"] — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: RoleBinding metadata: name: poc-rb-portforward namespace: default subjects:
kind: ServiceAccount name: poc-sa-portforward namespace: default roleRef: kind: Role name: poc-role-portforward apiGroup: rbac.authorization.k8s.io — apiVersion: v1 kind: Pod metadata: name: poc-target namespace: default spec: containers:
name: nginx image: nginx:alpine
set env:
export APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' | sed 's|https://||')
export TOKEN=$(kubectl create token poc-sa-portforward)
export POD=poc-target
run attached pocportforward.py
Mitigation: disable the above cluster roles from untrusted users.
Embargo Reason: Coordination with three upstream communities: containerd, CRI-O, kubernetes
Original Report: https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2