ts-2023-002
Vulnerability from tailscale

Description: An issue in the Tailscale coordination server allowed nodes with expired node keys to continue communicating with other nodes in a tailnet.

What happened?

There was a flaw in Tailscale’s logic for expiring node keys. If the set of nodes that can connect in a tailnet (the netmap) didn’t have any changes, then expired node keys were not immediately removed from the netmap. The longest delay in removal was 19 days, from 2022-12-20 to 2023-01-09.

Who is affected?

All tailnets with nodes whose node keys expired prior to 2023-01-12 may have been affected. Admins of a tailnet can view nodes with expired node keys in the admin console.

What is the impact?

Connections between nodes could continue after a node key expired, both when the expired node key was the source or when it was the destination of a connection. Connections to nodes with expired node keys would only be possible if they met all of the following criteria:

  • The peer node was in the same tailnet as, or shared into a tailnet with the node with the expired node key;
  • The peer node and the node with the expired node key were allowed to connect based on the access rules in the tailnet policy file at the time of expiry of the node key;
  • The tailnet’s netmap, including access rules, nodes added or removed from the tailnet, or connectivity of nodes in the tailnet did not change since the node key expiry; and
  • Tailscale had not deployed a change to the coordination server since the node key expiry.

What do I need to do?

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

Upgrade clients to v1.36 or later for an additional mitigation. In conjunction with the coordination server fix, this mitigation prevents nodes from connecting to nodes with expired node keys if the Tailscale coordination server is offline or unreachable.

Credits

We would like to thank Derek Ellis and Alex Eiser for reporting this issue.

Show details on source website


{
   guidislink: false,
   id: "https://tailscale.com/security-bulletins/#ts-2023-002",
   link: "https://tailscale.com/security-bulletins/#ts-2023-002",
   links: [
      {
         href: "https://tailscale.com/security-bulletins/#ts-2023-002",
         rel: "alternate",
         type: "text/html",
      },
   ],
   published: "Tue, 24 Jan 2023 00:00:00 GMT",
   summary: "<p><strong><em>Description</em></strong>: An issue in the Tailscale coordination server allowed nodes with expired node keys to continue communicating with other nodes in a tailnet.</p>\n<h4>What happened?</h4>\n<p>There was a flaw in Tailscale’s logic for expiring node keys. If the set of nodes that can connect in a tailnet (the netmap) didn’t have any changes, then expired node keys were not immediately removed from the netmap. The longest delay in removal was 19 days, from 2022-12-20 to 2023-01-09.</p>\n<h4>Who is affected?</h4>\n<p><strong>All tailnets with nodes whose node keys expired prior to 2023-01-12 may have been affected</strong>. Admins of a tailnet can view <a href=\"https://login.tailscale.com/admin/machines?q=disabled%3Aexpired\">nodes with expired node keys</a> in the admin console.</p>\n<h4>What is the impact?</h4>\n<p>Connections between nodes could continue after a node key expired, both when the expired node key was the source or when it was the destination of a connection. Connections to nodes with expired node keys would only be possible if they met all of the following criteria:</p>\n<ul>\n<li>The peer node was in the same tailnet as, or shared into a tailnet with the node with the expired node key;</li>\n<li>The peer node and the node with the expired node key were allowed to connect based on the access rules in the tailnet policy file at the time of expiry of the node key;</li>\n<li>The tailnet’s netmap, including access rules, nodes added or removed from the tailnet, or connectivity of nodes in the tailnet did not change since the node key expiry; and</li>\n<li>Tailscale had not deployed a change to the coordination server since the node key expiry.</li>\n</ul>\n<h4>What do I need to do?</h4>\n<p><strong>No action is required</strong>. Tailscale has deployed a fix to the coordination server as of 2023-01-11.</p>\n<p><strong>Upgrade clients to v1.36 or later for an additional mitigation</strong>. In conjunction with the coordination server fix, this mitigation prevents nodes from connecting to nodes with expired node keys if the Tailscale coordination server is offline or unreachable.</p>\n<h4>Credits</h4>\n<p>We would like to thank <a href=\"https://me.ellisd.com\">Derek Ellis</a> and <a href=\"https://www.cranksecurity.com/\">Alex Eiser</a> for reporting this issue.</p>",
   summary_detail: {
      base: "https://tailscale.com/security-bulletins/index.xml",
      language: null,
      type: "text/html",
      value: "<p><strong><em>Description</em></strong>: An issue in the Tailscale coordination server allowed nodes with expired node keys to continue communicating with other nodes in a tailnet.</p>\n<h4>What happened?</h4>\n<p>There was a flaw in Tailscale’s logic for expiring node keys. If the set of nodes that can connect in a tailnet (the netmap) didn’t have any changes, then expired node keys were not immediately removed from the netmap. The longest delay in removal was 19 days, from 2022-12-20 to 2023-01-09.</p>\n<h4>Who is affected?</h4>\n<p><strong>All tailnets with nodes whose node keys expired prior to 2023-01-12 may have been affected</strong>. Admins of a tailnet can view <a href=\"https://login.tailscale.com/admin/machines?q=disabled%3Aexpired\">nodes with expired node keys</a> in the admin console.</p>\n<h4>What is the impact?</h4>\n<p>Connections between nodes could continue after a node key expired, both when the expired node key was the source or when it was the destination of a connection. Connections to nodes with expired node keys would only be possible if they met all of the following criteria:</p>\n<ul>\n<li>The peer node was in the same tailnet as, or shared into a tailnet with the node with the expired node key;</li>\n<li>The peer node and the node with the expired node key were allowed to connect based on the access rules in the tailnet policy file at the time of expiry of the node key;</li>\n<li>The tailnet’s netmap, including access rules, nodes added or removed from the tailnet, or connectivity of nodes in the tailnet did not change since the node key expiry; and</li>\n<li>Tailscale had not deployed a change to the coordination server since the node key expiry.</li>\n</ul>\n<h4>What do I need to do?</h4>\n<p><strong>No action is required</strong>. Tailscale has deployed a fix to the coordination server as of 2023-01-11.</p>\n<p><strong>Upgrade clients to v1.36 or later for an additional mitigation</strong>. In conjunction with the coordination server fix, this mitigation prevents nodes from connecting to nodes with expired node keys if the Tailscale coordination server is offline or unreachable.</p>\n<h4>Credits</h4>\n<p>We would like to thank <a href=\"https://me.ellisd.com\">Derek Ellis</a> and <a href=\"https://www.cranksecurity.com/\">Alex Eiser</a> for reporting this issue.</p>",
   },
   title: "TS-2023-002",
   title_detail: {
      base: "https://tailscale.com/security-bulletins/index.xml",
      language: null,
      type: "text/plain",
      value: "TS-2023-002",
   },
}


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.