ts-2023-008
Vulnerability from tailscale

Description: Privilege escalation bugs in the Tailscale Kubernetes operator's API proxy allowed authenticated tailnet clients to send Kubernetes API requests as the operator's service account.

Tailscale Kubernetes operator version v1.53.37 fixes the issue and users of the operator who enable the API proxy functionality should update as described below.

What happened?

The Tailscale Kubernetes operator can optionally act as an API server proxy for the cluster's Kubernetes API. This proxy allows authenticated tailnet users to use their tailnet identity in Kubernetes authentication and RBAC rules. The API server proxy uses impersonation headers to translate tailnet identities to Kubernetes identities.

The operator prior to v1.53.37 has two bugs in the forwarding logic, which affects different modes of operation:

  • In the default proxy mode that applies Tailscale identity to proxied requests, incorrect header sanitization allowed a request with a crafted Connection header to drop the impersonation headers from the proxied request. This caused the proxied request to be authenticated as the operator's service account, and inherit the operator's permissions.
  • In the no-auth proxy mode, which does not apply Tailscale identity to forwarded requests, a specially crafted request could similarly cause the proxied request to use the operator's identity, with similar results.

The bug was reported by Mo Khan from Microsoft on 2023-11-01, and fixed on the same day.

Who is affected?

Tailnets using the API server proxy in Tailscale Kubernetes operator images with the following tags are affected:

  • unstable-v1.53.20 or earlier
  • unstable deployed before the tag was updated to 1.53.37, some time on 2023-11-01.

Operator users running in the default operator configuration are not affected, as the API proxy is not enabled by default.

What is the impact?

Authenticated tailnet users who have access to the operator's API proxy can make requests to the Kubernetes API with operator privileges. In the proxy mode that allows the operator to use impersonation, this can be used for further privilege escalation to other cluster identities.

External attackers cannot exploit this vulnerability without being a member of the tailnet.

What do I need to do?

Update the Tailscale Kubernetes operator image to version unstable-v1.53.37 or later.

If you used the official operator manifest file, download the new manifest file and run kubectl apply -f manifest.yaml.

If you used the Helm chart, set the operatorConfig.image.tag to unstable-v1.53.37 in the values.yaml file and run helm upgrade <path-to-chart-directory> -n tailscale -f <path-to-values-file>

If you wrote your own manifest or Helm chart, update the k8s-operator image tag to unstable-v1.53.37 and redeploy it.

Show details on source website


{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2023-008",
  "link": "https://tailscale.com/security-bulletins/#ts-2023-008",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2023-008",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Wed, 01 Nov 2023 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Privilege escalation bugs in the Tailscale\nKubernetes operator\u0027s API proxy allowed authenticated tailnet clients\nto send Kubernetes API requests as the operator\u0027s service account.\u003c/p\u003e\n\u003cp\u003eTailscale Kubernetes operator version v1.53.37 fixes the issue and\nusers of the operator who enable the API proxy functionality should\nupdate as described below.\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003eThe Tailscale Kubernetes operator can optionally act as \u003ca href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\"\u003ean API server\nproxy\u003c/a\u003e\nfor the cluster\u0027s Kubernetes API. This proxy allows authenticated\ntailnet users to use their tailnet identity in Kubernetes\nauthentication and RBAC rules. The API server proxy uses\n\u003ca href=\"https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation\"\u003eimpersonation\nheaders\u003c/a\u003e\nto translate tailnet identities to Kubernetes identities.\u003c/p\u003e\n\u003cp\u003eThe operator prior to v1.53.37 has two bugs in the forwarding logic,\nwhich affects different modes of operation:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIn the default proxy mode that applies Tailscale identity to\nproxied requests, incorrect header sanitization allowed a request\nwith a crafted \u003ccode\u003eConnection\u003c/code\u003e header to drop the impersonation\nheaders from the proxied request. This caused the proxied request\nto be authenticated as the operator\u0027s service account, and inherit\nthe operator\u0027s permissions.\u003c/li\u003e\n\u003cli\u003eIn the\n\u003ca href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy#configuring-api-server-proxy-in-noauth-mode\"\u003eno-auth\u003c/a\u003e\nproxy mode, which does not apply Tailscale identity to forwarded\nrequests, a specially crafted request could similarly cause the\nproxied request to use the operator\u0027s identity, with similar\nresults.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe bug was reported by \u003ca href=\"https://github.com/enj\"\u003eMo Khan\u003c/a\u003e from Microsoft on\n2023-11-01, and fixed on the same day.\u003c/p\u003e\n\u003ch5\u003eWho is affected?\u003c/h5\u003e\n\u003cp\u003eTailnets using \u003ca href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\"\u003ethe API server\nproxy\u003c/a\u003e\nin Tailscale Kubernetes operator images with the following tags are affected:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eunstable-v1.53.20\u003c/code\u003e or earlier\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eunstable\u003c/code\u003e deployed before the tag was updated to 1.53.37, some time\non 2023-11-01.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eOperator users running in the default operator configuration are\n\u003cstrong\u003enot\u003c/strong\u003e affected, as the API proxy is not enabled by default.\u003c/p\u003e\n\u003ch5\u003eWhat is the impact?\u003c/h5\u003e\n\u003cp\u003eAuthenticated tailnet users who have access to the operator\u0027s API\nproxy can make requests to the Kubernetes API with operator\nprivileges. In the proxy mode that allows the operator to use\nimpersonation, this can be used for further privilege escalation to\nother cluster identities.\u003c/p\u003e\n\u003cp\u003eExternal attackers \u003cstrong\u003ecannot\u003c/strong\u003e exploit this vulnerability without being\na member of the tailnet.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eUpdate the Tailscale Kubernetes operator image to version unstable-v1.53.37 or\nlater.\u003c/p\u003e\n\u003cp\u003eIf you used the official \u003ca href=\"https://github.com/tailscale/tailscale/blob/main/cmd/k8s-operator/deploy/manifests/operator.yaml\"\u003eoperator manifest\nfile\u003c/a\u003e,\ndownload the new manifest file and run \u003ccode\u003ekubectl apply -f manifest.yaml\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eIf you used the Helm chart, set the\n\u003ca href=\"https://github.com/tailscale/tailscale/blob/ca4c940a4d0ac3274ee91a58e4823afb3c92ae0b/cmd/k8s-operator/deploy/chart/values.yaml#L16\"\u003e\u003ccode\u003eoperatorConfig.image.tag\u003c/code\u003e\u003c/a\u003e\nto \u003ccode\u003eunstable-v1.53.37\u003c/code\u003e in the \u003ccode\u003evalues.yaml\u003c/code\u003e file and run \u003ccode\u003ehelm upgrade \u0026#x3c;path-to-chart-directory\u003e -n tailscale -f \u0026#x3c;path-to-values-file\u003e\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eIf you wrote your own manifest or Helm chart, update the \u003ccode\u003ek8s-operator\u003c/code\u003e image\ntag to \u003ccode\u003eunstable-v1.53.37\u003c/code\u003e and redeploy it.\u003c/p\u003e",
  "summary_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/html",
    "value": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Privilege escalation bugs in the Tailscale\nKubernetes operator\u0027s API proxy allowed authenticated tailnet clients\nto send Kubernetes API requests as the operator\u0027s service account.\u003c/p\u003e\n\u003cp\u003eTailscale Kubernetes operator version v1.53.37 fixes the issue and\nusers of the operator who enable the API proxy functionality should\nupdate as described below.\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003eThe Tailscale Kubernetes operator can optionally act as \u003ca href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\"\u003ean API server\nproxy\u003c/a\u003e\nfor the cluster\u0027s Kubernetes API. This proxy allows authenticated\ntailnet users to use their tailnet identity in Kubernetes\nauthentication and RBAC rules. The API server proxy uses\n\u003ca href=\"https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation\"\u003eimpersonation\nheaders\u003c/a\u003e\nto translate tailnet identities to Kubernetes identities.\u003c/p\u003e\n\u003cp\u003eThe operator prior to v1.53.37 has two bugs in the forwarding logic,\nwhich affects different modes of operation:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIn the default proxy mode that applies Tailscale identity to\nproxied requests, incorrect header sanitization allowed a request\nwith a crafted \u003ccode\u003eConnection\u003c/code\u003e header to drop the impersonation\nheaders from the proxied request. This caused the proxied request\nto be authenticated as the operator\u0027s service account, and inherit\nthe operator\u0027s permissions.\u003c/li\u003e\n\u003cli\u003eIn the\n\u003ca href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy#configuring-api-server-proxy-in-noauth-mode\"\u003eno-auth\u003c/a\u003e\nproxy mode, which does not apply Tailscale identity to forwarded\nrequests, a specially crafted request could similarly cause the\nproxied request to use the operator\u0027s identity, with similar\nresults.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe bug was reported by \u003ca href=\"https://github.com/enj\"\u003eMo Khan\u003c/a\u003e from Microsoft on\n2023-11-01, and fixed on the same day.\u003c/p\u003e\n\u003ch5\u003eWho is affected?\u003c/h5\u003e\n\u003cp\u003eTailnets using \u003ca href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\"\u003ethe API server\nproxy\u003c/a\u003e\nin Tailscale Kubernetes operator images with the following tags are affected:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eunstable-v1.53.20\u003c/code\u003e or earlier\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eunstable\u003c/code\u003e deployed before the tag was updated to 1.53.37, some time\non 2023-11-01.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eOperator users running in the default operator configuration are\n\u003cstrong\u003enot\u003c/strong\u003e affected, as the API proxy is not enabled by default.\u003c/p\u003e\n\u003ch5\u003eWhat is the impact?\u003c/h5\u003e\n\u003cp\u003eAuthenticated tailnet users who have access to the operator\u0027s API\nproxy can make requests to the Kubernetes API with operator\nprivileges. In the proxy mode that allows the operator to use\nimpersonation, this can be used for further privilege escalation to\nother cluster identities.\u003c/p\u003e\n\u003cp\u003eExternal attackers \u003cstrong\u003ecannot\u003c/strong\u003e exploit this vulnerability without being\na member of the tailnet.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eUpdate the Tailscale Kubernetes operator image to version unstable-v1.53.37 or\nlater.\u003c/p\u003e\n\u003cp\u003eIf you used the official \u003ca href=\"https://github.com/tailscale/tailscale/blob/main/cmd/k8s-operator/deploy/manifests/operator.yaml\"\u003eoperator manifest\nfile\u003c/a\u003e,\ndownload the new manifest file and run \u003ccode\u003ekubectl apply -f manifest.yaml\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eIf you used the Helm chart, set the\n\u003ca href=\"https://github.com/tailscale/tailscale/blob/ca4c940a4d0ac3274ee91a58e4823afb3c92ae0b/cmd/k8s-operator/deploy/chart/values.yaml#L16\"\u003e\u003ccode\u003eoperatorConfig.image.tag\u003c/code\u003e\u003c/a\u003e\nto \u003ccode\u003eunstable-v1.53.37\u003c/code\u003e in the \u003ccode\u003evalues.yaml\u003c/code\u003e file and run \u003ccode\u003ehelm upgrade \u0026#x3c;path-to-chart-directory\u003e -n tailscale -f \u0026#x3c;path-to-values-file\u003e\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eIf you wrote your own manifest or Helm chart, update the \u003ccode\u003ek8s-operator\u003c/code\u003e image\ntag to \u003ccode\u003eunstable-v1.53.37\u003c/code\u003e and redeploy it.\u003c/p\u003e"
  },
  "title": "TS-2023-008",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2023-008"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.