Vulnerability-Lookup

TS-2024-003

Vulnerability from tailscale - Published: Tue, 23 Apr 2024 00:00:00 GMT

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

JSON

To clipboard

{
  "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": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Bug in SSH check mode with \u003ccode\u003echeckPeriod\u003c/code\u003e set to \u003ccode\u003e0s\u003c/code\u003e.\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003e\u003ca href=\"https://tailscale.com/kb/1193/tailscale-ssh#configure-tailscale-ssh-with-check-mode\"\u003eCheck mode\u003c/a\u003e in Tailscale SSH forces an SSH client to periodically\nre-authenticate when connecting to SSH servers. The period is configured via\nthe \u003ccode\u003echeckPeriod\u003c/code\u003e attribute in Tailscale ACLs, and defaults to 12 hours.\u003c/p\u003e\n\u003cp\u003eA bug in ACL parsing interpreted \u003ccode\u003e\"checkPeriod\": \"0s\"\u003c/code\u003e as unset, and used the\ndefault period of 12 hours instead.\u003c/p\u003e\n\u003cp\u003eWe deployed a fix for the bug in ACL parsing logic on 2024-04-23. SSH clients\nin tailnets that set \u003ccode\u003e\"checkPeriod\": \"0s\"\u003c/code\u003e are now correctly prompted for\nre-authentication on every connection.\u003c/p\u003e\n\u003cp\u003eNote that a special value \u003ccode\u003e\"checkPeriod\": \"always\"\u003c/code\u003e is the documented\nrecommended way to achieve this behavior.\u003c/p\u003e\n\u003cp\u003eWe thank \u003ca href=\"https://twitter.com/plaidfinch\"\u003eFinch\u003c/a\u003e for reporting this issue.\u003c/p\u003e\n\u003ch5\u003eWho was affected?\u003c/h5\u003e\n\u003cp\u003e17 tailnets use Tailscale SSH with \u003ccode\u003e\"action\": \"check\"\u003c/code\u003e and \u003ccode\u003e\"checkPeriod\": \"0s\"\u003c/code\u003e. We notified security contacts for the affected tailnets about this bug.\u003c/p\u003e\n\u003ch5\u003eWhat was the impact?\u003c/h5\u003e\n\u003cp\u003eSSH clients in the affected tailnets were prompted to re-authenticate every 12\nhours, instead of during each connection as intended by the tailnet\nadministrators.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eNo action is needed at this time.\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: Bug in SSH check mode with \u003ccode\u003echeckPeriod\u003c/code\u003e set to \u003ccode\u003e0s\u003c/code\u003e.\u003c/p\u003e\n\u003ch5\u003eWhat happened?\u003c/h5\u003e\n\u003cp\u003e\u003ca href=\"https://tailscale.com/kb/1193/tailscale-ssh#configure-tailscale-ssh-with-check-mode\"\u003eCheck mode\u003c/a\u003e in Tailscale SSH forces an SSH client to periodically\nre-authenticate when connecting to SSH servers. The period is configured via\nthe \u003ccode\u003echeckPeriod\u003c/code\u003e attribute in Tailscale ACLs, and defaults to 12 hours.\u003c/p\u003e\n\u003cp\u003eA bug in ACL parsing interpreted \u003ccode\u003e\"checkPeriod\": \"0s\"\u003c/code\u003e as unset, and used the\ndefault period of 12 hours instead.\u003c/p\u003e\n\u003cp\u003eWe deployed a fix for the bug in ACL parsing logic on 2024-04-23. SSH clients\nin tailnets that set \u003ccode\u003e\"checkPeriod\": \"0s\"\u003c/code\u003e are now correctly prompted for\nre-authentication on every connection.\u003c/p\u003e\n\u003cp\u003eNote that a special value \u003ccode\u003e\"checkPeriod\": \"always\"\u003c/code\u003e is the documented\nrecommended way to achieve this behavior.\u003c/p\u003e\n\u003cp\u003eWe thank \u003ca href=\"https://twitter.com/plaidfinch\"\u003eFinch\u003c/a\u003e for reporting this issue.\u003c/p\u003e\n\u003ch5\u003eWho was affected?\u003c/h5\u003e\n\u003cp\u003e17 tailnets use Tailscale SSH with \u003ccode\u003e\"action\": \"check\"\u003c/code\u003e and \u003ccode\u003e\"checkPeriod\": \"0s\"\u003c/code\u003e. We notified security contacts for the affected tailnets about this bug.\u003c/p\u003e\n\u003ch5\u003eWhat was the impact?\u003c/h5\u003e\n\u003cp\u003eSSH clients in the affected tailnets were prompted to re-authenticate every 12\nhours, instead of during each connection as intended by the tailnet\nadministrators.\u003c/p\u003e\n\u003ch5\u003eWhat do I need to do?\u003c/h5\u003e\n\u003cp\u003eNo action is needed at this time.\u003c/p\u003e"
  },
  "title": "TS-2024-003",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2024-003"
  }
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.