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": "\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"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...
  • 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.