Looks like AI slop and certainly not wormable in the traditional sense. Hard to imagine that your access to a Tailscale SSH server would then allow further replication, and certainly it would not allow for meaningful cross-tenant replication.
This is just slop, even if any of the issues raised here are real or not, no human bothered to want to contribute to its authorship. The linked website is something like 10,000 words that by and large convey nothing useful to the reader. HN is going to need a flag for these articles so nobody wastes and time under the illusion that there’s anything worth reading.
If you were in college this would be a 40 page essay, or about the same length as thesis in some cases, to communicate a list of potential software vulnerabilities in an overly verbose, pompous voice. It's just slop, it could have been a couple of paragraphs of text at most.
Tailscales architecture of increasing its scope while having insufficient isolation is why I don't use it. (I just want the mesh, but their non-root setup instructions are now gone!)
That said, these vulnerabilities aren't that significant.
there are fair and not fair points in all this (too much AI?).
to be fair, config choices like tailnet lock and ephemeral keys can be used to mitigate.
however, the enumeration of the entire tailnet leading to one compromised node providing the whole map (e.g. hugging face) is inherent in their architecture. that one can be mitigated by ACLs for small networks, but that is unwieldy at scale.
i do have to agree that tailscale is a vpn - which is not easily reconfigured to follow more zero trust principles. so their zero trust washing marketing is disingenuous. they could stick with their strength: an easy to use version of a great vpn (wireguard).
(tailscalar here): it's been a long day working on this, and we will have more details to follow. quickly though, on this point about enumeration, some of this may be a difference in headscale. the tailscale control plane performs what we colloquially refer to as "netmap trimming" - if node a has no acls that allow it to do anything with node b, then neither a or b would see each other in their netmap.
trimming is a neat feature - thanks for that - thought the ACLs are often not there to begin with because configuring off the full node level access defaults of the vpn is difficult, at least at scale.
not specific to ts - all vpns and firewalls have the same intrinsic issue.
I am not sure if it is actually true for TS. From what I understand the nodes advertise themselves in a different mechanism than what provides access. ACLs are set globally and the nodes fetch them.
So even with 0 access ACLs for node-to-node communication, nodes can advertise themselves to the control plane and change their config as the ACLs are updated.
I am Erica Windisch, the original researcher that published this report.
The primary finding relevant to most users is the privilege escalation vulnerability in the opensource tailscale ssh server, when port forwarding is enabled (default), users may escalate privileges to root on the destination server.
The secondary finding is the ability to route to arbitrary subnets accessible via a host offering an App Connector. This is the one that really worries me, in regard to impact.
The third most important finding may be the `tailscale serve` authz bypass opportunity, but I suspect this may not impact many users. It may be significant in unlucky configurations.
Much of the report focuses on the security model and architecture of the software, with explanations of live scenarios conducted in our lab. Our concern is that an attacker could establish a foothold via something like a PHP exploit or supply chain exploit on a host, then `tailscale ssh` to another host and escalate, or route through an App Connector. They may even leverage the tailscale serve authz mechanism for an app-level privilege escalation for lateral movement. It is true that well managed policies mitigate some of these risks.
This report was called Tailworm because the research focused on the threat of a worm against an opensource headscale+tailscale network, and the capabilities of our agentic systems to defend autonomously against lateral movement across our systems. Our lab focuses on building secure infrastructure for recursive self improving intelligence, and this was the report from the red side of the experiment.
Finally, I believe we live in an age of continuous disclosure, continuous development, continuous integration, and continuous deployment. That's how we get through this.
What is the "this" that we get through by disclosing unpatched vulnerabilities that aren't evidently being actively exploited in the wild before the vendor can release patches? I'm trying to be charitable and figure out what that could refer to and drawing a blank.
The VP of engineering at tailscale did post a response here:
https://www.reddit.com/r/Tailscale/comments/1xeoj1l/recent_t...
This was very hard to read and this author didn't report their findings to security@tailscale.com either, which is irresponsible.
It was reported but not coordinated.
Looks like AI slop and certainly not wormable in the traditional sense. Hard to imagine that your access to a Tailscale SSH server would then allow further replication, and certainly it would not allow for meaningful cross-tenant replication.
Seems like they responded on Reddit: https://www.reddit.com/r/Tailscale/comments/1xekjpd/tailworm...
This is just slop, even if any of the issues raised here are real or not, no human bothered to want to contribute to its authorship. The linked website is something like 10,000 words that by and large convey nothing useful to the reader. HN is going to need a flag for these articles so nobody wastes and time under the illusion that there’s anything worth reading.
Why?
Some of these vulnerabilities are critical. One compromised node with ssh can get root every other node.
Calling it slop, AI, conveys nothing, 10000 words does not help. They provide practical demonstration, and explain the cause.
In my opinion tailscale needs to focus on secure networking. File sharing, DNS, SSH, Funnel, ... can be handled by dedicated tools.
How many lines of code is tailscale client nowadays?
If you were in college this would be a 40 page essay, or about the same length as thesis in some cases, to communicate a list of potential software vulnerabilities in an overly verbose, pompous voice. It's just slop, it could have been a couple of paragraphs of text at most.
Tailscales architecture of increasing its scope while having insufficient isolation is why I don't use it. (I just want the mesh, but their non-root setup instructions are now gone!)
That said, these vulnerabilities aren't that significant.
Meh.
there are fair and not fair points in all this (too much AI?).
to be fair, config choices like tailnet lock and ephemeral keys can be used to mitigate.
however, the enumeration of the entire tailnet leading to one compromised node providing the whole map (e.g. hugging face) is inherent in their architecture. that one can be mitigated by ACLs for small networks, but that is unwieldy at scale.
i do have to agree that tailscale is a vpn - which is not easily reconfigured to follow more zero trust principles. so their zero trust washing marketing is disingenuous. they could stick with their strength: an easy to use version of a great vpn (wireguard).
(tailscalar here): it's been a long day working on this, and we will have more details to follow. quickly though, on this point about enumeration, some of this may be a difference in headscale. the tailscale control plane performs what we colloquially refer to as "netmap trimming" - if node a has no acls that allow it to do anything with node b, then neither a or b would see each other in their netmap.
appreciate your hard work and ts in general.
trimming is a neat feature - thanks for that - thought the ACLs are often not there to begin with because configuring off the full node level access defaults of the vpn is difficult, at least at scale.
not specific to ts - all vpns and firewalls have the same intrinsic issue.
I am not sure if it is actually true for TS. From what I understand the nodes advertise themselves in a different mechanism than what provides access. ACLs are set globally and the nodes fetch them.
So even with 0 access ACLs for node-to-node communication, nodes can advertise themselves to the control plane and change their config as the ACLs are updated.
I am Erica Windisch, the original researcher that published this report.
The primary finding relevant to most users is the privilege escalation vulnerability in the opensource tailscale ssh server, when port forwarding is enabled (default), users may escalate privileges to root on the destination server.
The secondary finding is the ability to route to arbitrary subnets accessible via a host offering an App Connector. This is the one that really worries me, in regard to impact.
The third most important finding may be the `tailscale serve` authz bypass opportunity, but I suspect this may not impact many users. It may be significant in unlucky configurations.
Much of the report focuses on the security model and architecture of the software, with explanations of live scenarios conducted in our lab. Our concern is that an attacker could establish a foothold via something like a PHP exploit or supply chain exploit on a host, then `tailscale ssh` to another host and escalate, or route through an App Connector. They may even leverage the tailscale serve authz mechanism for an app-level privilege escalation for lateral movement. It is true that well managed policies mitigate some of these risks.
This report was called Tailworm because the research focused on the threat of a worm against an opensource headscale+tailscale network, and the capabilities of our agentic systems to defend autonomously against lateral movement across our systems. Our lab focuses on building secure infrastructure for recursive self improving intelligence, and this was the report from the red side of the experiment.
Finally, I believe we live in an age of continuous disclosure, continuous development, continuous integration, and continuous deployment. That's how we get through this.
What is the "this" that we get through by disclosing unpatched vulnerabilities that aren't evidently being actively exploited in the wild before the vendor can release patches? I'm trying to be charitable and figure out what that could refer to and drawing a blank.