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: "<p><strong><em>Description</em></strong>: Privilege escalation bugs in the Tailscale\nKubernetes operator's API proxy allowed authenticated tailnet clients\nto send Kubernetes API requests as the operator's service account.</p>\n<p>Tailscale 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.</p>\n<h5>What happened?</h5>\n<p>The Tailscale Kubernetes operator can optionally act as <a href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\">an API server\nproxy</a>\nfor the cluster's 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<a href=\"https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation\">impersonation\nheaders</a>\nto translate tailnet identities to Kubernetes identities.</p>\n<p>The operator prior to v1.53.37 has two bugs in the forwarding logic,\nwhich affects different modes of operation:</p>\n<ul>\n<li>In the default proxy mode that applies Tailscale identity to\nproxied requests, incorrect header sanitization allowed a request\nwith a crafted <code>Connection</code> header to drop the impersonation\nheaders from the proxied request. This caused the proxied request\nto be authenticated as the operator's service account, and inherit\nthe operator's permissions.</li>\n<li>In the\n<a href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy#configuring-api-server-proxy-in-noauth-mode\">no-auth</a>\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's identity, with similar\nresults.</li>\n</ul>\n<p>The bug was reported by <a href=\"https://github.com/enj\">Mo Khan</a> from Microsoft on\n2023-11-01, and fixed on the same day.</p>\n<h5>Who is affected?</h5>\n<p>Tailnets using <a href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\">the API server\nproxy</a>\nin Tailscale Kubernetes operator images with the following tags are affected:</p>\n<ul>\n<li><code>unstable-v1.53.20</code> or earlier</li>\n<li><code>unstable</code> deployed before the tag was updated to 1.53.37, some time\non 2023-11-01.</li>\n</ul>\n<p>Operator users running in the default operator configuration are\n<strong>not</strong> affected, as the API proxy is not enabled by default.</p>\n<h5>What is the impact?</h5>\n<p>Authenticated tailnet users who have access to the operator's 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.</p>\n<p>External attackers <strong>cannot</strong> exploit this vulnerability without being\na member of the tailnet.</p>\n<h5>What do I need to do?</h5>\n<p>Update the Tailscale Kubernetes operator image to version unstable-v1.53.37 or\nlater.</p>\n<p>If you used the official <a href=\"https://github.com/tailscale/tailscale/blob/main/cmd/k8s-operator/deploy/manifests/operator.yaml\">operator manifest\nfile</a>,\ndownload the new manifest file and run <code>kubectl apply -f manifest.yaml</code>.</p>\n<p>If you used the Helm chart, set the\n<a href=\"https://github.com/tailscale/tailscale/blob/ca4c940a4d0ac3274ee91a58e4823afb3c92ae0b/cmd/k8s-operator/deploy/chart/values.yaml#L16\"><code>operatorConfig.image.tag</code></a>\nto <code>unstable-v1.53.37</code> in the <code>values.yaml</code> file and run <code>helm upgrade &#x3c;path-to-chart-directory> -n tailscale -f &#x3c;path-to-values-file></code></p>\n<p>If you wrote your own manifest or Helm chart, update the <code>k8s-operator</code> image\ntag to <code>unstable-v1.53.37</code> and redeploy it.</p>",
   summary_detail: {
      base: "https://tailscale.com/security-bulletins/index.xml",
      language: null,
      type: "text/html",
      value: "<p><strong><em>Description</em></strong>: Privilege escalation bugs in the Tailscale\nKubernetes operator's API proxy allowed authenticated tailnet clients\nto send Kubernetes API requests as the operator's service account.</p>\n<p>Tailscale 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.</p>\n<h5>What happened?</h5>\n<p>The Tailscale Kubernetes operator can optionally act as <a href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\">an API server\nproxy</a>\nfor the cluster's 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<a href=\"https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation\">impersonation\nheaders</a>\nto translate tailnet identities to Kubernetes identities.</p>\n<p>The operator prior to v1.53.37 has two bugs in the forwarding logic,\nwhich affects different modes of operation:</p>\n<ul>\n<li>In the default proxy mode that applies Tailscale identity to\nproxied requests, incorrect header sanitization allowed a request\nwith a crafted <code>Connection</code> header to drop the impersonation\nheaders from the proxied request. This caused the proxied request\nto be authenticated as the operator's service account, and inherit\nthe operator's permissions.</li>\n<li>In the\n<a href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy#configuring-api-server-proxy-in-noauth-mode\">no-auth</a>\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's identity, with similar\nresults.</li>\n</ul>\n<p>The bug was reported by <a href=\"https://github.com/enj\">Mo Khan</a> from Microsoft on\n2023-11-01, and fixed on the same day.</p>\n<h5>Who is affected?</h5>\n<p>Tailnets using <a href=\"https://tailscale.com/kb/1437/kubernetes-operator-api-server-proxy\">the API server\nproxy</a>\nin Tailscale Kubernetes operator images with the following tags are affected:</p>\n<ul>\n<li><code>unstable-v1.53.20</code> or earlier</li>\n<li><code>unstable</code> deployed before the tag was updated to 1.53.37, some time\non 2023-11-01.</li>\n</ul>\n<p>Operator users running in the default operator configuration are\n<strong>not</strong> affected, as the API proxy is not enabled by default.</p>\n<h5>What is the impact?</h5>\n<p>Authenticated tailnet users who have access to the operator's 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.</p>\n<p>External attackers <strong>cannot</strong> exploit this vulnerability without being\na member of the tailnet.</p>\n<h5>What do I need to do?</h5>\n<p>Update the Tailscale Kubernetes operator image to version unstable-v1.53.37 or\nlater.</p>\n<p>If you used the official <a href=\"https://github.com/tailscale/tailscale/blob/main/cmd/k8s-operator/deploy/manifests/operator.yaml\">operator manifest\nfile</a>,\ndownload the new manifest file and run <code>kubectl apply -f manifest.yaml</code>.</p>\n<p>If you used the Helm chart, set the\n<a href=\"https://github.com/tailscale/tailscale/blob/ca4c940a4d0ac3274ee91a58e4823afb3c92ae0b/cmd/k8s-operator/deploy/chart/values.yaml#L16\"><code>operatorConfig.image.tag</code></a>\nto <code>unstable-v1.53.37</code> in the <code>values.yaml</code> file and run <code>helm upgrade &#x3c;path-to-chart-directory> -n tailscale -f &#x3c;path-to-values-file></code></p>\n<p>If you wrote your own manifest or Helm chart, update the <code>k8s-operator</code> image\ntag to <code>unstable-v1.53.37</code> and redeploy it.</p>",
   },
   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.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.