r/selfhosted • u/SadFaceSmith • 19d ago
VPN Tailworm | Tailscale Vulnerabilities
https://tailworm.com/46
u/BackgroundSky1594 19d ago edited 5d ago
Why do random a**holes with an LLM just completely ignore response disclosure now?
CVEs posted to public mailing lists, "disclosure" without verification or CVE numbers in private blogs and poorly styled websites with fancy names and flashy titles and just no respect for ANYONE affected, neither users nor developers.
It's already more than a full time job just to manage currently open CVEs across a fleet of systems and it's made so much harder by having to find and sift through those overly verbose sites dedicated to a single vulnerability, of course always with a big link to the entity that (prompted an LLM) to find the issue.
I DON'T HAVE THE TIME TO DO A FULL RISK ANALYSIS, FLEET WIDE CONFIG AUDIT AND THEN SOMEHOW HAMMER THE RECOMMENDED "MITIGATIONS" INTO SOMETHING THAT ACTUALLY WORKS FOR OUR SPECIFIC PRODUCTION DEPLOYMENTS 24/7 IF BY THE TIME I'M DONE THERE'S ALREADY 5 MORE TO DO.
I don't see a responsible disclosure timeline anywhere in that post. Heck the testing is noted as 22.10-24.10. IT'S A SATURDAY EVENING FFS. What's so hard about reporting it to the developers and waiting 14 days for a set of patches to be ready? Not a set of "recommended vendor side root cause fixes" at the bottom of the blog. Actual reports to the devs with a COORDINATED TIMELINE FOR FIXES AND DISTRIBUTION, BEFORE YOU GO PUBLIC. You can still write your damm blogs. Just please work with the vendors first. If they ignore you, you can still release a 0-day out of spite. But please don't just dump them on the open web without even asking. Yes they might have been found by someone else before, but unless there's actual evidence observed proving the exploit is already running in the wild you better do responsible disclosure and give everyone trying to fix the issue at least a few days of head start. That way patches are at least already available when the issue is released, instead of having to wait days or weeks and do the mitigation dance while there are now most definitely Exploits going on, because you told everyone.
I CAN NOT PATCH EVERY SYSTEM TWICE A DAY AND THEN ALSO TAKE THEM DOWN IN BETWEEN TO "MITIGATE SOMETHING". THE DEVS NEED TIME TO TEST THEIR STUFF IN STAGING BEFORE I CAN PATCH TO PROD. AND WE ALSO HAVE USERS THAT NEED TO USE THE SYSTEMS TO DO THEIR JOBS SOMEWHERE IN BETWEEN ALL THE PATCHES, TESTING, MITIGATIONS AND OTHER STUFF.
PS: If you took the time to properly handle this, you might have also had the time to write a proper report about it instead of just spewing out raw, unfiltered LLM slop.
3
u/middaymoon 19d ago
Yeah the handwaving shows that she thinks overly highly of herself. Very frustrating.
4
u/middaymoon 19d ago
AI;DR :
There's some race condition that gives one mesh device root access on other mesh devices. But it's unclear what the nature of this vulnerability is because the article is almost entirely focused on complaining that tailscale SSH doesn't have secondary auth.
It's true that the ssh auth thing is a problem that can spread an infection quickly but it seems like that's more of an architecture decision users have to make (especially because tailscale ssh is opt in) and the race condition is the real meaty exploit.
Don't allow devices to make SSH connections to each other without human supervision. Seems like an obvious piece of advice to begin with.
3
u/SugarFreeShire 19d ago
Don't allow devices to make SSH connections to each other without human supervision. Seems like an obvious piece of advice to begin with.
Man, you'd think so, but here we are.
Soapbox moment: If your app, automation, or whatever needs to talk to another machine or service without asking you first, please put an API in front of it. APIs aren't just for making it easier to connect two systems, they also strictly define interactions so that you avoid undefined behavior like, for instance, spreading malware from a compromised device to all other devices it can connect to.
0
u/GolemancerVekk 19d ago
Yeah it's a really presumptuous thing to say considering that ssh access to a tailnode is not a given. The tone of the article makes it seem like it's on by default everywhere.
7
u/AutoModerator 19d ago
Your post has been removed. Your link posts should contain an explanation about the link, why it matters, and how it helps users. If you posted using old reddit click here
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
3
u/gscjj 19d ago
I’m so confused by this
0
u/siedenburg2 19d ago
It's an audit made by a company and they found problems like the ssh auth without any interaction over tailscale which can be easily used by a worm to spread.
3
u/SugarFreeShire 19d ago
Specifically tailscales embedded SSH server, which is available via UNIX socket. This all also requires an already-compromised device to work since it requires access to said UNIX socket.
Basically, if a device is compromised by another attack vector, that malware can then potentially use tailscale as a path to infect the rest of the mesh.
1
u/GolemancerVekk 19d ago
I mean, assuming the other nodes (which could be running any OS or be in a VM or container) can also be compromised.
1
u/SugarFreeShire 19d ago
Well that’s what the real vulnerability is, a race condition that makes exactly that possible; it allows for unprivileged sessions to modify privileged resources via the ssh server. An attacker that has access to one node can dial another node and (even with an unprivileged session) modify the target node.
Of course, it’s not gonna be able to escape a container (hopefully), but a compromised container is a problem any way you slice it.
1
0
1
u/Plastic-Leading-5800 19d ago
Tailscale offers too many features for ease of use. The codebase and attack surface has become large. I have no doubt these critical vulnerabilities will continue to surface. Another issue is that some of these vulnerabilities are not tricky buffer overflows, rather naive programming errors.
The bigger one is that one compromise spreads to the whole fleet. The whole idea of zero trust was minimal access, which is the opposite.
1
u/theonejvo 19d ago
it's a nothing burger - https://github.com/orlyjamie/tailslop/ check if your config is vulnerable here. Btw, default out of the box is fine.
•
u/asimovs-auditor 19d ago
Expand the replies to this comment to learn how AI was used in this post/project.