- This is such a venerable and ancient class of bugs, going at least as far back as AIX 3. Glad to see they're still makin' 'em like they used to.
(If you had SSH access to a host in your Tailscale ACL, you could log in as `-i` and get a root login.)
by traceroute66
7 subcomments
- At $work we use Tailscale mostly because we were running into too many random issues with NAT with our standard DIY Wireguard setup, especially when people were working from hotels and other places with half-ass network setups.
But we don't trust Tailscale. Just look at the thousands of unresolved Github issues, many of which are actually quite important/useful but have been ignored for months and years.
We very much fear at $work that there are vulnerabilities in the Tailscale product awaiting discovery. Especially as, AFAIK, Tailscale have never had a formal security audit on their software.
So we install it on hardened bastion hosts in an old-school "jump host" model. So people can still get access to where they need to be, but we don't need to install Tailscale's unaudited shit on every single server / vm / etc.
And we only use Tailscale as a glorified VPN, we don't use their hundreds of extra random features like this SSH one.
In terms of SSH, we use old-school OpenSSH and SSH certificates. Its really not that difficult and its really not expensive, you can do offline signing with Yubikeys, no need for expensive HSMs.
by doublepg23
5 subcomments
- I’m a heavy Tailscale user, so I do trust them quite a bit, but I never used the Tailscale SSH feature.
I feel like OpenSSH’s security record is pretty unbeatable, not sure why I’d swap over for such a security-sensitive tool.
- > usernames were passed as arguments to getent(1) to retrieve the corresponding passwd entry
Always try to use actual API/system calls (in this case getpwnam) instead of calling sub-processes.
- I'll stick to my 100% self-hosted Wireguard setup, thank you very much.
- > Tailscale SSH now rejects usernames with leading dashes.
Is the proper fix not restricting users not possible in these poorly designed ancient systems?
Similarly re another issue: why not just fix the permission issues instead of restricting users?
> Tailscale now disallows the use of UIDs or numeric-only usernames via SSH to avoid this ambiguity
by s_ting765
2 subcomments
- I don't see the point of publishing a security bulletin if you are not going to timely push the fix to artifacts on all affected platforms. Tailscale needs to do better on their release process, docker hub shows last update was 8 days ago.
by luciana1u
1 subcomments
- tailscale ssh: replacing a 25-year-old battle-tested codebase with a startup's Go rewrite and then acting surprised when it has bugs
- So, giving access via tailscale but using OpenSSH is safe, right?
- >>> We would like to thank Anthropic and Ada Logics for reporting this issue.
it seems anthropic also use tailscale or it's just being discovered by the mythos model?
- It appears that tailscale ssh is off by default? How can I validate that? When I try to log in, I just get:
No ED25519 host key is known for $host and you have requested strict checking.
- Tailscale SSH has caused me other problems in the past because it takes over port 22. I'm not a fan.
- Why own numbering instead of CVE?
- pure logic error, the undergoing tailscale rust rewrite can't help this too:)
- Why does the page only show up to 008? Did TS remove the notice?
Edit: my bad, it's between 008 and 007 ?=
- > "Tailscale SSH now rejects usernames with leading dashes."
Really? That's the fix?
A proper fix is to use "--" to separate arguments.
by TacticalCoder
0 subcomment
- I'll fix this entire HN thread for you all and you'll thank me later:
s/bug/backdoor/g
by farfatched
0 subcomment
- Sadly, yet another path to root via Tailscale.
If their scope grows, and they run so much as root, it won't be their last.
- [dead]