ts-2023-004
Vulnerability from tailscale

Description: An issue in the Tailscale coordination server allowed tailnets created by GitHub organizations which were subsequently renamed to be associated with a new GitHub organization with the previous name.

What happened?

Tailscale mapped tailnets created by GitHub organizations to their organization name, rather than to their organization ID. This meant that if a GitHub organization was renamed, and the previous name taken over by a new GitHub organization, the existing tailnet would be tied to the new GitHub organization instead of the original one.

Who is affected?

Up to 1,305 tailnets created by GitHub organizations may have been affected, if those GitHub organizations were renamed between 2021-06-18 and 2023-03-30 and fully relinquished the old GitHub organization name. Additional tailnets created by GitHub organizations could be verified to definitely not have been renamed in that time period based on organization membership.

No tailnets were definitively found to have been affected. If a tailnet created by a GitHub organization is affected, we can detect this the next time an unauthorized user logs in to the tailnet belonging to the renamed organization and block their access. We will contact the security contact for that tailnet if that happens.

What is the impact?

A renamed GitHub organization may have had their previous tailnet visible to a newly created GitHub organization with the same name. The new GitHub organization would be aware of the existence of the previous tailnet. Devices added to the new GitHub organization would be aware of the existence and some metadata of previous added devices, including: their host names, their OS and version, when the devices were last connected, and their public IP addresses. They would have been able to connect to these devices if allowed by ACLs. The new GitHub organization would not have had any admin access or be able to see or modify any setting in the admin console.

There is no evidence of this vulnerability being purposefully triggered or exploited.

What do I need to do?

No action is required. Tailscale has deployed a fix to the coordination server as of 2023-03-30.

GitHub organizations which were previously renamed and lost access to their tailnet should contact support. When renaming a GitHub organization, contact support to migrate the tailnet to the new GitHub organization.

Credits

We would like to thank Thomas Way for reporting this issue.

Show details on source website


{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2023-004",
  "link": "https://tailscale.com/security-bulletins/#ts-2023-004",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2023-004",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Tue, 04 Apr 2023 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: An issue in the Tailscale coordination server allowed tailnets created by GitHub organizations which were subsequently renamed to be associated with a new GitHub organization with the previous name.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eTailscale mapped tailnets created by GitHub organizations to their organization name, rather than to their organization ID. This meant that if a GitHub organization was renamed, and the previous name taken over by a new GitHub organization, the existing tailnet would be tied to the new GitHub organization instead of the original one.\u003c/p\u003e\n\u003ch4\u003eWho is affected?\u003c/h4\u003e\n\u003cp\u003e\u003cstrong\u003eUp to 1,305 tailnets created by GitHub organizations may have been affected, if those GitHub organizations were renamed between 2021-06-18 and 2023-03-30 and fully relinquished the old GitHub organization name\u003c/strong\u003e. Additional tailnets created by GitHub organizations could be verified to definitely not have been renamed in that time period based on organization membership.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eNo tailnets were definitively found to have been affected\u003c/strong\u003e. If a tailnet created by a GitHub organization is affected, we can detect this the next time an unauthorized user logs in to the tailnet belonging to the renamed organization and block their access. We will contact the \u003ca href=\"https://tailscale.com/kb/1224/contact-preferences/#setting-the-security-issues-email\"\u003esecurity contact\u003c/a\u003e for that tailnet if that happens.\u003c/p\u003e\n\u003ch4\u003eWhat is the impact?\u003c/h4\u003e\n\u003cp\u003e\u003cstrong\u003eA renamed GitHub organization may have had their previous tailnet visible to a newly created GitHub organization with the same name.\u003c/strong\u003e\nThe new GitHub organization would be aware of the existence of the previous tailnet. Devices added to the new GitHub organization would be aware of the existence and some metadata of previous added devices, including: their host names, their OS and version, when the devices were last connected, and their public IP addresses. They would have been able to connect to these devices if allowed by ACLs. The new GitHub organization would not have had any admin access or be able to see or modify any setting in the admin console.\u003c/p\u003e\n\u003cp\u003eThere is no evidence of this vulnerability being purposefully triggered or exploited.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003e\u003cstrong\u003eNo action is required\u003c/strong\u003e. Tailscale has deployed a fix to the coordination server as of 2023-03-30.\u003c/p\u003e\n\u003cp\u003eGitHub organizations which were previously renamed and lost access to their tailnet should \u003ca href=\"https://tailscale.com/contact/support/\"\u003econtact support\u003c/a\u003e. When renaming a GitHub organization, \u003ca href=\"https://tailscale.com/contact/support/?type=sso\"\u003econtact support\u003c/a\u003e to migrate the tailnet to the new GitHub organization.\u003c/p\u003e\n\u003ch4\u003eCredits\u003c/h4\u003e\n\u003cp\u003eWe would like to thank \u003ca href=\"https://6f.io/\"\u003eThomas Way\u003c/a\u003e for reporting this issue.\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: An issue in the Tailscale coordination server allowed tailnets created by GitHub organizations which were subsequently renamed to be associated with a new GitHub organization with the previous name.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eTailscale mapped tailnets created by GitHub organizations to their organization name, rather than to their organization ID. This meant that if a GitHub organization was renamed, and the previous name taken over by a new GitHub organization, the existing tailnet would be tied to the new GitHub organization instead of the original one.\u003c/p\u003e\n\u003ch4\u003eWho is affected?\u003c/h4\u003e\n\u003cp\u003e\u003cstrong\u003eUp to 1,305 tailnets created by GitHub organizations may have been affected, if those GitHub organizations were renamed between 2021-06-18 and 2023-03-30 and fully relinquished the old GitHub organization name\u003c/strong\u003e. Additional tailnets created by GitHub organizations could be verified to definitely not have been renamed in that time period based on organization membership.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eNo tailnets were definitively found to have been affected\u003c/strong\u003e. If a tailnet created by a GitHub organization is affected, we can detect this the next time an unauthorized user logs in to the tailnet belonging to the renamed organization and block their access. We will contact the \u003ca href=\"https://tailscale.com/kb/1224/contact-preferences/#setting-the-security-issues-email\"\u003esecurity contact\u003c/a\u003e for that tailnet if that happens.\u003c/p\u003e\n\u003ch4\u003eWhat is the impact?\u003c/h4\u003e\n\u003cp\u003e\u003cstrong\u003eA renamed GitHub organization may have had their previous tailnet visible to a newly created GitHub organization with the same name.\u003c/strong\u003e\nThe new GitHub organization would be aware of the existence of the previous tailnet. Devices added to the new GitHub organization would be aware of the existence and some metadata of previous added devices, including: their host names, their OS and version, when the devices were last connected, and their public IP addresses. They would have been able to connect to these devices if allowed by ACLs. The new GitHub organization would not have had any admin access or be able to see or modify any setting in the admin console.\u003c/p\u003e\n\u003cp\u003eThere is no evidence of this vulnerability being purposefully triggered or exploited.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003e\u003cstrong\u003eNo action is required\u003c/strong\u003e. Tailscale has deployed a fix to the coordination server as of 2023-03-30.\u003c/p\u003e\n\u003cp\u003eGitHub organizations which were previously renamed and lost access to their tailnet should \u003ca href=\"https://tailscale.com/contact/support/\"\u003econtact support\u003c/a\u003e. When renaming a GitHub organization, \u003ca href=\"https://tailscale.com/contact/support/?type=sso\"\u003econtact support\u003c/a\u003e to migrate the tailnet to the new GitHub organization.\u003c/p\u003e\n\u003ch4\u003eCredits\u003c/h4\u003e\n\u003cp\u003eWe would like to thank \u003ca href=\"https://6f.io/\"\u003eThomas Way\u003c/a\u003e for reporting this issue.\u003c/p\u003e"
  },
  "title": "TS-2023-004",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2023-004"
  }
}


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.