[dead]
TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
51–60 of 157 posts
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#52This 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.)
I'm somewhat alarmed that the context that this bug was running in was capable of root login. Is there a reason that an SSH login process would, by default, have enough capabilities to facilitate direct root login?
We did Tailscale-like SSH reverse tunnels at scale first in 2013 and the main issue has always been that there are no good libraries. Bash scripting around the OpenSSH binaries is pretty much the only way to go.
There's Paramiko, but Python is still a huge liability in memory-constrained systems.
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#53I’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.
The SSH vulnerability here only applies if the attacker is already on the network. It violates your Tailscale ACLs, but it's not arbitrary external root ssh access. Arguably that's a more secure starting point than vanilla ssh to publicly accessible machine.
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#54Earlier quoted context omitted.
as much as handing control to a remote third part is, yes.
Good point. I self host headscale but it also has the ssh feature, probably also insecure.
Not necessarily, it's a clean room implementation. Even if leading dashes was known/documented/tested to implement they might have done it differently. And maybe it was an implementation detail that it was ever allowed, but that's a weird username, headscale implementation happened not to allow it, and nobody ever noticed the discrepancy.
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#55Earlier quoted context omitted.
I argue the opposite: there’s no better fix for this. You can write the most elegant fix, whatever it is, and prevent that from happening only on the codebase that’s fixed. That doesn’t mean that the codebase will always be the only authority on authentication. The username policy fixes this issue for good, regardless of whatever you write in the future, or whatever new mechanism is introduced. It’s a restriction for…
> I argue the opposite: there’s no better fix for this The better fix would be to not have the username pass through a parser looking for cli flags in the first place.
How do you propose to do that when username is a possible argument?
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#56> 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
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#57Earlier quoted context omitted.
I do not understand this rebuttal. I also run self-hosted Wireguard. Initially on a Debian box, nowadays it is integrated into my router (admittedly, this is closed source). For around 6 years at this point. The whole thing could not be easier and simpler. It has never randomly broken on me. It is fast. It is free. There is no middle man, no vendor. I never understood the popularity of Tailscale, though that is on me…
I think Tailscale is popular because of how plug and play it is for most people. Although the main reason I use it over self hosting wireguard is the NAT busting it does, which has so far worked flawlessly for me with no setup aside from installing on both devices. There is nothing wrong with self hosting wireguard, but it doesn't actually do the same job as tailscale.
as someone who uses tailscale: exactly this.
i have my homelab only reachable via tailscale and can access everything i would ever want on the go that way. it was a matter of 15 min to get it all working.
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#58Tailscale SSH has caused me other problems in the past because it takes over port 22. I'm not a fan.
It takes over port 22 on the Tailscale interface only. Only had problems with this when I’ve wanted to hit a host’s non-Tailscale ssh service via Tailscale. Otherwise it’s been great for me
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#59Earlier quoted context omitted.
I do not understand this rebuttal. I also run self-hosted Wireguard. Initially on a Debian box, nowadays it is integrated into my router (admittedly, this is closed source). For around 6 years at this point. The whole thing could not be easier and simpler. It has never randomly broken on me. It is fast. It is free. There is no middle man, no vendor. I never understood the popularity of Tailscale, though that is on me…
I think Tailscale is popular because of how plug and play it is for most people. Although the main reason I use it over self hosting wireguard is the NAT busting it does, which has so far worked flawlessly for me with no setup aside from installing on both devices. There is nothing wrong with self hosting wireguard, but it doesn't actually do the same job as tailscale.
Wireguard by itself also doesn't allow for 2FA or expiring keys. Not as relevant for private use, but some orgs need it for compliance. The idea was always that things like that need to be implemented by an application on top of it, so you end up with something like tailscale eventually.
Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
#60Tailscale SSH has caused me other problems in the past because it takes over port 22. I'm not a fan.
[deleted]