Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tailscale.com

Post reply on HN
Print view View original

71–80 of 157 posts

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

#71

Post by pferde »

eviks wrote: post #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

The proper fix would be to not use getent CLI tool in their logic, but instead use proper system APIs for looking up user account entries, like one of earlier comments here already mentions. This is shocking amateur hour!

My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.

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

#72

Post by pferde »

bestouff wrote: post #46
mintflow wrote: post #32

pure logic error, the undergoing tailscale rust rewrite can't help this too:)

If it used one of the standard arguments-handling crates (e.g. "clap") there's no way it can happen.

If it used one of the standard system APIs for looking up user accounts (e.g. getpwnam(3)), there's no way it can happen.

This is incredibly bad engineering, on level of a SQL injection, in 21st century. Something a highschool student experimenting with scripting could come up with, but not a supposedly professional software company.

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

#73

Post by sva_ »

doctorpangloss wrote: post #37
drnick1 wrote: post #24

I'll stick to my 100% self-hosted Wireguard setup, thank you very much.

haha self hosted wireguard, an opportunity to find out AllowedIPs: 0.0.0.0/0 does the opposite of what you think it will do

If you don't care to invest half an hour into learning some basics of how computer networking and in particular CIDR notation and subnet masks work, maybe it is not for you.

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

#74

Post by sam_lowry_ »

eviks wrote: post #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

There is a whole class of security issues where fixes are worse that the issues themselves. Case in point, the OpenSSH itself that sends 100 packets on each keystroke to avoid timing attacks.

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

#75

Post by gear54rus »

nicman23 wrote: post #44
drnick1 wrote: post #24

I'll stick to my 100% self-hosted Wireguard setup, thank you very much.

i really dislike that there is no way to do dhcp for new clients and that i have to manually define peers in each "exit node"

Because wireguard to tailscale is like git to git GUIs. It's solid base but never should be used separately without a proper wrapper if one wants to keep one's sanity.

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

#76

Post by fragmede »

sam_lowry_ wrote: post #74
eviks wrote: post #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

There is a whole class of security issues where fixes are worse that the issues themselves . Case in point, the OpenSSH itself that sends 100 packets on each keystroke to avoid timing attacks.

Why is that worse than the issue itself? If someone could figure out, say, my root password via an ssh timing attack, that seems bad. Sending 100 packets for each keystroke to protect against this seems cheap in the face of that.

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

#77

Post by cyberax »

raggi wrote: post #35
cyberax wrote: post #14

Earlier quoted context omitted.

This is just a dirty fix. It adds weird restrictions and masks issues. Refactoring external invocations to use safe argument handling is a better way to fix it. Along with tests that exercise weird names.

http://github.com/tailscale/tailscale/commit/e4144230f410204...

All the hallmarks of an LLM fix right there...

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

#78

Post by bestouff »

pferde wrote: post #72
bestouff wrote: post #46

Earlier quoted context omitted.

If it used one of the standard arguments-handling crates (e.g. "clap") there's no way it can happen.

If it used one of the standard system APIs for looking up user accounts (e.g. getpwnam(3)), there's no way it can happen. This is incredibly bad engineering, on level of a SQL injection, in 21st century. Something a highschool student experimenting with scripting could come up with, but not a supposedly professional software company.

Agreed.

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

#79

Post by rfoo »

pferde wrote: post #71
eviks wrote: post #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

The proper fix would be to not use getent CLI tool in their logic, but instead use proper system APIs for looking up user account entries, like one of earlier comments here already mentions. This is shocking amateur hour! My guess is they hastily threw together something hacky in early development, and forgot to replace it with a real, safe solution later.

The issue here is there is NO single system API for looking up user account entries on Linux.

It's implemented in libc. So you need to link to libc. Tailscale is a Go binary, and they probably prefer it to be statically-linked. glibc NSS implementation also REQUIRES you to load `.so` so you just can't emulate it in Go.

Then, "link to libc". Which libc? glibc? musl?

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

#80

Post by xorcist »

hdgvhicv wrote: post #69
diarrhea wrote: post #43

Earlier 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…

My WireGuard uses (either at home or at work) are very much mobile client to single network Where Tailscale comes into its own is automatic managing of mesh networking (like an “sdwan” solution). The other thing it excels at is firewall busting - if you have a firewall (with or without address translation) which only allows outgoing traffic to be established (with UDP timeouts for session) then Tailscale also works i…

> it excels at is firewall busting

Some would consider that an anti-feature. Firewalls are not to be busted. Nothing good lies at the extreme end of working around overly strict policies. Change the policy instead.

Post reply on HN