Live data from Hacker News

TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

tailscale.com

151–157 of 157 posts

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#151
post #134

Earlier quoted context omitted.

> Another concern I have is whether a compromise of Tailscale's own infra could let an attacker just add itself to my network. Apparently the "Tailnet Lock" feature mitigates this, but it is off by default. Yeah, we use "tailnet lock" to sort of cover that. AFAIK its the only option available. I say "sort of" because "tailnet lock" is a bit half-assed in its design and implementation. For example, you cannot sign new…

Comically you can sign Tailnet lock from iOS, but it’s an insane workflow. You need to generate a QR code then scan it from the signing mobile device, which opens a secret menu option to sign (fine just brings up a confirmation dialog). Incredibly annoying but perhaps more secure vs the threat of randomly tapping at prompts

> Comically you can sign Tailnet lock from iOS, but it’s an insane workflow.

Interesting, thanks for pointing out the insane workflow.

Although looking around, footguns still remain in terms of relying too much on iOS and Tailnet Lock, e.g. https://github.com/tailscale/tailscale/issues/20475

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#152
post #141

Earlier quoted context omitted.

Yes

Which ones? Alpine supports it.

Most variants don't, Alpine in fact does not, nor does the uclibc shell script, nor the commonly copied in implementation in many busybox environments.

Reference: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/m...

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#153
post #7

> "Tailscale SSH now rejects usernames with leading dashes." Really? That's the fix? A proper fix is to use "--" to separate arguments.

A proper fix is not to shell out to a command at all; use getpwnam(3) or similar.

They actually do use "os/user".Lookup() as a fallback if fetching via getent(1) fails, so they might be using NSS modules to dynamically define users and then not linking their binaries with glibc (musl and the opt-in pure-Go implementation of "os/user".Lookup() do not support NSS).

Still, requesting the information from systemd-userdb would be a better way of doing this if it's really necessary.

EDIT: Yeah, some older comments confirm that was their reasoning. https://github.com/tailscale/tailscale/commit/1fc1077052dfa7...

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#154
post #139

Earlier quoted context omitted.

I haven't had problems with NetBird on Android and Linux. I have also used tailscale and found it comparable.

Neat, I haven't heard of/tried NetBird yet. Always more stuff out there to tinker with!

Word of warning. Netbird does use maginally more data than Tailscale when idle. While you might be tempted by the Jetbird thirdparty app, I found it used ALOT more data and didn't work consistontly even with lazy connections.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#155
post #145

Earlier quoted context omitted.

Others have pointed out that os/user.Lookup is a platform-independent way to resolve this, but additionally you don’t _need_ to link against glibc to use it. If you are writing go, you usually want to set CGO_ENABLED=0 by default, to avoid inadvertently introducing nonportable code. In this way, only the pure Go implementations are used and there is no need to link (statically or dynamically) against a libc implement…

With CGO disabled, it only reads /etc/passwd, while the glibc getpwnam(3) can query LDAP etc.

That’s not the use case of the tailscale daemon though, which was using getent passwd.

To clarify: I’m not against CGO, just introducing a glibc dependency by default. I would only introduce it when I needed it.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#156

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.

The advantage of tailscale ssh is that the machine doesn't need to have the ssh port open publicly.

Re: TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

#157

Earlier quoted context omitted.

Why not tailscale plus head scale for self hosting?

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 never understood the popularity of Tailscale, though that is on me. I'm sure it is a great product, I just never tried it, do not seem the target audience.

Can you talk an $elderly_relative through a wireguard installation on the phone so they can join your VPN?

I've done it with Tailscale and it's a breeze.

Post reply on HN