An SSH access policy is a list of which devices may log in to which servers. After a compromise it becomes the list of where an attacker can go next, and I think most teams should read it that way before the next advisory arrives.
What Tailscale found
Tailscale’s findings post on the Tailworm report describes SSH sessions that could do more than the privileges of their configured local user, including through SSH forwarding. Version 1.104.4 fixes them, and we covered the details in our news brief. The part I care about is the condition. Tailscale says exploitation needs an attacker who already holds an authorized device in the tailnet, with SSH access permitted in the policy file.
The company’s investigation also produced a statement about reach. Mike Shaver, who wrote the post, says “Based on our investigation, an attacker could reach only machines the tailnet policy file already permitted SSH connections to.” I take that at face value, and it is the most useful sentence in the post. It says the policy file bounded the damage. Whatever sits in that file is the answer to how bad a stolen laptop would have been.
Why the policy matters more than this patch
Every SSH server needs higher privileges to start sessions as different users, and the next bug in the privilege handling of any SSH server will most likely assume the same thing this one did: a foothold on a device that is allowed in. The patch closes this class of flaw. The list of allowed pairs decides what the next one is worth.
Access lists tend to grow by accumulation. A broad rule added to restore service during an outage gives a laptop that needed one server the ability to reach fifty, and nothing breaks when the rule stays, so nobody removes it. Firewall rule sets age the same way, and an SSH policy has the same incentive to grow and none to shrink. An exposure inventory decides your first hour after an advisory, and the policy is the part of that inventory that says what a single compromised device can touch.
There is also a detection benefit. A device that touches three servers in normal use produces a clear signal when it reaches a fourth. A device allowed to reach every server in the fleet produces no signal at all, because every connection looks permitted. Narrow policy gives both a smaller blast radius and a monitoring baseline.
A foothold on one approved device is the starting condition in most of the incidents we have covered lately, including the token replay across 79 Microsoft 365 organizations. Defenders cannot always prevent the foothold. They can decide, in advance and in writing, how much it is worth to the attacker who gets one.
The strongest objection
The best argument against this view is that policy reviews are busywork once the patch is applied. The report’s findings are fixed, the objection goes, so time is better spent on the next patch. Policies also drift, and a review done today decays within a quarter.
I accept the drift and reject the conclusion. A patch removes a known flaw and a tight policy limits unknown ones, and the two do different jobs. Tailscale itself recommends the review in the same post: it tells customers to check that SSH access is limited to the users and devices that need it, and to consider SSH check mode for sensitive systems. A vendor that has just shipped fixes and still points customers at their own policy is telling you where it sees the remaining risk.
What I would do this week
- List every source and destination pair the SSH policy allows and delete the ones nobody can justify in a sentence.
- Check which local users each device may connect as. Tailscale lets administrators define this, so root access for a general-purpose laptop deserves a written reason.
- Turn on SSH check mode for production databases, backup servers and anything holding keys, so an extra authentication check sits in front of them.
- Alert when a device connects to a server it has never reached before. A policy that allows fifty destinations is easier to defend when a person watches the three that get used.
- Put the policy file in version control with a review requirement, so a Friday-night rule leaves a record.
Patch to 1.104.4 first. Then spend the afternoon on the policy, because it sets the size of the next incident.
Source: Tailscale
