Allocation of Resources Without Limits or Throttling Affecting github.com/rancher/rancher/pkg/tls package, versions >=2.11.0-alpha1 <2.11.16-alpha6>=2.12.0-alpha1 <2.12.12-alpha9>=2.13.0-alpha1 <2.13.8-alpha8>=2.14.0-alpha1 <2.14.4-alpha7

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the filterExistingCN logic in pkg/tls/podips.go for the tls-rancher-internal TLS listener. An attacker can bloat the serving certificate’s SAN list and eventually break TLS handshakes by repeatedly sending TLS connections with distinct SNI hostnames or HTTP Host values to the internal listener. The vulnerable code lets non-IP CNs pass through unchanged instead of limiting the certificate to live pod IPs, so attacker-supplied hostnames accumulate on the cert across requests and pod restarts. Once the SAN list grows too large, clients can no longer complete TLS connections to the Rancher internal endpoint, causing a denial of service.

Notes

• The vulnerable listener is the upstream Rancher internal port 444 path; on v2.12/v2.13 it is backed by the rancher Service, while the rancher-internal.cattle-system.svc DNS name only appears in later releases.
• The affected serving certificate already includes other static SANs through dynamiclistener’s default-SAN handling; the issue is specifically the extra hostname CNs being appended on top of that list and persisting across pod churn.

Workarounds

• Restrict cluster-internal access with Kubernetes NetworkPolicy so only trusted workloads can reach the cattle-cluster-agent pod IP on port 443 and the rancher-internal ClusterIP Service on port 444; this reduces the ability of an attacker inside the cluster to send repeated TLS requests with distinct hostnames.

• BugZilla
• GitHub Commit v2.11.16
• GitHub Commit v2.12.12
• GitHub Commit v2.13.8
• GitHub Commit v2.14.4
• Maintainer's Advisory