ts-2024-003
Vulnerability from tailscale

Description: Bug in SSH check mode with checkPeriod set to 0s.

What happened?

Check mode in Tailscale SSH forces an SSH client to periodically re-authenticate when connecting to SSH servers. The period is configured via the checkPeriod attribute in Tailscale ACLs, and defaults to 12 hours.

A bug in ACL parsing interpreted "checkPeriod": "0s" as unset, and used the default period of 12 hours instead.

We deployed a fix for the bug in ACL parsing logic on 2024-04-23. SSH clients in tailnets that set "checkPeriod": "0s" are now correctly prompted for re-authentication on every connection.

Note that a special value "checkPeriod": "always" is the documented recommended way to achieve this behavior.

We thank Finch for reporting this issue.

Who was affected?

17 tailnets use Tailscale SSH with "action": "check" and "checkPeriod": "0s". We notified security contacts for the affected tailnets about this bug.

What was the impact?

SSH clients in the affected tailnets were prompted to re-authenticate every 12 hours, instead of during each connection as intended by the tailnet administrators.

What do I need to do?

No action is needed at this time.

Show details on source website


{
   guidislink: false,
   id: "https://tailscale.com/security-bulletins/#ts-2024-003",
   link: "https://tailscale.com/security-bulletins/#ts-2024-003",
   links: [
      {
         href: "https://tailscale.com/security-bulletins/#ts-2024-003",
         rel: "alternate",
         type: "text/html",
      },
   ],
   published: "Tue, 23 Apr 2024 00:00:00 GMT",
   summary: "<p><strong><em>Description</em></strong>: Bug in SSH check mode with <code>checkPeriod</code> set to <code>0s</code>.</p>\n<h5>What happened?</h5>\n<p><a href=\"https://tailscale.com/kb/1193/tailscale-ssh#configure-tailscale-ssh-with-check-mode\">Check mode</a> in Tailscale SSH forces an SSH client to periodically\nre-authenticate when connecting to SSH servers. The period is configured via\nthe <code>checkPeriod</code> attribute in Tailscale ACLs, and defaults to 12 hours.</p>\n<p>A bug in ACL parsing interpreted <code>\"checkPeriod\": \"0s\"</code> as unset, and used the\ndefault period of 12 hours instead.</p>\n<p>We deployed a fix for the bug in ACL parsing logic on 2024-04-23. SSH clients\nin tailnets that set <code>\"checkPeriod\": \"0s\"</code> are now correctly prompted for\nre-authentication on every connection.</p>\n<p>Note that a special value <code>\"checkPeriod\": \"always\"</code> is the documented\nrecommended way to achieve this behavior.</p>\n<p>We thank <a href=\"https://twitter.com/plaidfinch\">Finch</a> for reporting this issue.</p>\n<h5>Who was affected?</h5>\n<p>17 tailnets use Tailscale SSH with <code>\"action\": \"check\"</code> and <code>\"checkPeriod\": \"0s\"</code>. We notified security contacts for the affected tailnets about this bug.</p>\n<h5>What was the impact?</h5>\n<p>SSH clients in the affected tailnets were prompted to re-authenticate every 12\nhours, instead of during each connection as intended by the tailnet\nadministrators.</p>\n<h5>What do I need to do?</h5>\n<p>No action is needed at this time.</p>",
   summary_detail: {
      base: "https://tailscale.com/security-bulletins/index.xml",
      language: null,
      type: "text/html",
      value: "<p><strong><em>Description</em></strong>: Bug in SSH check mode with <code>checkPeriod</code> set to <code>0s</code>.</p>\n<h5>What happened?</h5>\n<p><a href=\"https://tailscale.com/kb/1193/tailscale-ssh#configure-tailscale-ssh-with-check-mode\">Check mode</a> in Tailscale SSH forces an SSH client to periodically\nre-authenticate when connecting to SSH servers. The period is configured via\nthe <code>checkPeriod</code> attribute in Tailscale ACLs, and defaults to 12 hours.</p>\n<p>A bug in ACL parsing interpreted <code>\"checkPeriod\": \"0s\"</code> as unset, and used the\ndefault period of 12 hours instead.</p>\n<p>We deployed a fix for the bug in ACL parsing logic on 2024-04-23. SSH clients\nin tailnets that set <code>\"checkPeriod\": \"0s\"</code> are now correctly prompted for\nre-authentication on every connection.</p>\n<p>Note that a special value <code>\"checkPeriod\": \"always\"</code> is the documented\nrecommended way to achieve this behavior.</p>\n<p>We thank <a href=\"https://twitter.com/plaidfinch\">Finch</a> for reporting this issue.</p>\n<h5>Who was affected?</h5>\n<p>17 tailnets use Tailscale SSH with <code>\"action\": \"check\"</code> and <code>\"checkPeriod\": \"0s\"</code>. We notified security contacts for the affected tailnets about this bug.</p>\n<h5>What was the impact?</h5>\n<p>SSH clients in the affected tailnets were prompted to re-authenticate every 12\nhours, instead of during each connection as intended by the tailnet\nadministrators.</p>\n<h5>What do I need to do?</h5>\n<p>No action is needed at this time.</p>",
   },
   title: "TS-2024-003",
   title_detail: {
      base: "https://tailscale.com/security-bulletins/index.xml",
      language: null,
      type: "text/plain",
      value: "TS-2024-003",
   },
}


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.