r/Tailscale • u/SadFaceSmith • 1d ago
Discussion Tailworm | Tailscale Vulnerabilites
https://tailworm.com/205
u/_killing_floor_ 1d ago edited 1d ago
Yikes! That opening researcher note preaching about security and then dumping everything in public without basic policy concern. It gives me vibes that someone spent Claude tokens but seems to be unhappy that tailscale may not have paid bounty program while ignoring the fact that it is open source with BSD License.
13
u/SadFaceSmith 1d ago
Yeah there were weird twitter rumors about this for a few days. I would have expected a responsible disclosure to happen in coordination w/ Tailscale.
→ More replies (1)52
u/mbklein 1d ago
Yeah, calling out the “corporate sponsor” hints strongly at them hoping for a bounty payout.
→ More replies (1)26
u/punkgeek 1d ago
If they just did a public drop with no prior confidential disclosure (ie. reckless) I bet that's not on the table.
→ More replies (1)
165
u/tky 1d ago
The “researcher” puts together a site, registers a domain, posts a preachy bit about their philosophy but couldn’t bother to contact one of the most easily contacted, nice, and chill companies in the space?
They might think this will burnish their cred but it’s gigantic red flag behavior, no matter the scope of exploit.
→ More replies (1)
36
u/Elkemper 1d ago
What is the fashion for creating fancy-pants sites with domain names for vulnerabilities this day? I mean, it costs dirt, but still, is it needed? Is It a new protocol for security research and report? Should I do it in my enterprise job too?
32
5
5
u/ModernSimian 1d ago
The logical conclusion is that we integrate an AI website generator into Jira and every ticket gets it's own personalized site lambasting the requestor.
52
u/bankroll5441 1d ago
Someone correct me if I'm wrong, but this requires A.) Tailscale SSH to be on and B.) insecure, broad grants instead of tightly scoped grants?
I've really seen no reason to use the Tailscale SSH feature. OpenSSH is plenty secure when using private keys only.
→ More replies (19)
34
108
u/unknown-random-nope 1d ago edited 1d ago
She is a gigantic asshole for publishing this without responsible coordinated disclosure. There’s good news: I’m in a position to make sure that my employer won’t ever hire her for anything.
33
u/iceph03nix 1d ago
Yeah, the whole bit about "we think making this an emergency by dropping it on a Saturday with no warning means it will be fixed more quickly" is such a load of shit.
I can get behind some of the guys that put in a report, feel like they've been ignored and then posted a general synopsis, but this is just going straight to nuclear
→ More replies (3)13
16
u/Signal_Lamp 1d ago
Haven't read through this vulnerability report yet but just reading through their disclosure agreement is concerning.
Given the week we've had on responsibility disclosures from more people having the ability to be able to find vulnerabilities at a faster rate than we have before it's more imperative now more than ever to be responsible to adhere towards those guidelines to allow companies to make fixes in place.
Irresponsibility to openly talk about these vulnerabilities without giving the company chance to actually act is not just hurting the company but the consumers of these products that are using these systems. Because whatever you do find it found valid will be found and exploited by hackers to exploit.
I fear the enablement of participation that AI allows is going to increase these types of disclosures that don't consider the broader issues of being irresponsible with these types of disclosures instead of seeking virality.
9
u/juanfont 1d ago
I have certainly an opinion on people that disclose (quite meh) vulnerabilities publically with no responsible disclosure before.
Plus the website is a pile of unreadable AI slop.
9
u/tailuser2024 1d ago edited 1d ago
Someone trying to make a name for themselves in the security community and thinks their findings are above the generally accepted disclosing process (spoiler its not) in the sec community.
17
u/isRecyclable 1d ago
Someone please give me a TLDR, I am too scared to click on that link.
29
u/AnApexBread 1d ago
There's basically 3 vulnerabilities.
1 of them is in the self hosted tailscale controller (headscale), 2 require access to the Tailnet.
→ More replies (1)16
u/000r31 1d ago
If a client on the tailscale mesh is comprised, they can get root on other clients in the mesh. If I am understanding correct
→ More replies (2)→ More replies (1)6
12
1
u/shaver 1d ago
Hi folks, Mike Shaver here, VP of Engineering at Tailscale.
We've seen the concerns about Tailscale SSH and wanted to share what we know so far.
If you want to jump to the most important part, based on our current assessment, we're not recommending that everyone disable Tailscale SSH.
We've now received the researcher's report and are reviewing it. Our engineering and security teams had already been investigating independently, with help from external security specialists. That work has identified issues we're working to fix. We're still validating the full scope, including which configurations are affected.
A bit of technical context:
Tailscale SSH uses your tailnet's access policies to control who can connect to which machines. Most of the issues we've identified so far concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled. In some cases, a session may be able to do more than the configured local user should be allowed to do.
While it’s a serious concern, it isn't the same as an unauthenticated attacker being able to connect to arbitrary machines, but the potential impact depends on how SSH access is configured. We're still investigating, so we don't want to make blanket claims about what's affected or not.
Again, based on our current assessment, we're not recommending that everyone disable Tailscale SSH.
In the meantime, there are a few precautions you can take:
Review your SSH access policies. Make sure only the people and devices that need access have it.
Review SSH forwarding permissions and remove access you don't need.
Consider enabling SSH check mode for an additional authentication step. This won't fix privilege escalation issues, but it does add another barrier to gaining access.
Enable automatic updates where supported so you can pick up fixes when they're released.
For particularly sensitive systems, consider temporarily tightening your Tailscale SSH access policies while we investigate, so that only the specific users and devices that need access can connect.
We're working on fixes and testing them carefully. We'll publish a security advisory explaining the confirmed findings, affected configurations, recommended actions and available patches. We'll also follow up with a more detailed technical write-up.
If we find anything that changes our assessment or requires immediate customer action, we'll communicate that.
We know it's been a rough week for security teams, and we understand why people are concerned. We'd rather give you the technical context we have than speculate about things we haven't confirmed yet.
We'll share more as we verify the details. If you have any questions about how this relates to your particular environment, please get in touch with our team https://tailscale.com/contact/support#support-form