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" } }
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.