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?
If it runs as your user and can only log in as you, then I wouldn't expect it to be able to become root. But if it can log you in as different users, I would expect that 1. it needs to run from root, and 2. it can log in as root.
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.
I used it for a bunch of remote monitor boxes to have a way of centrally managing ssh access to things that were often on- and off-line. It was simple and convenient and access was easily revocable.
It lets organizations (Tailscale) control the timing and narrative around the disclosure more directly. Organizations sometimes avoid the bureaucracy of going through CVE Numbering Authorities by self-publishing. Often a CVE assignment follows self-disclosure, especially when there's pressure to interoperate with vuln-scanning/compliance tooling
A better fix is to call “getent passwd” with no user controlled arguments and then parse the resulting list. This gets rid of the input sanitization problem entirely.
A correct implementation would be to just call glibc directly, this seems like a hasty fix to get the patch out the door. The history of vulns from bad shell escaping is as old as bash, whenever possible you probably shouldn't be mixing code and data, especially in a security critical application like this.
The fact that there is no portable way to link the relevant functions that works reliably across all distributions of Linux is a failure of POSIX and GNU, and unfortunately is largely the Linux distribution story in a nutshell.
Your answer is mostly correct, except that when you tug on that thread the shelf comes off the wall, the plaster comes with it, and then it cracks the water pipes on the way to the floor.
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 sure, but it’s not a nonsense restriction? Who would have a username starting with a hyphen? I didn’t even know it was possible until today.
(If you had SSH access to a host in your Tailscale ACL, you could log in as `-i` and get a root login.)
it seems anthropic also use tailscale or it's just being discovered by the mythos model?
As single tailnet+single user, perhaps it's just okay
If their scope grows, and they run so much as root, it won't be their last.
Really? That's the fix?
A proper fix is to use "--" to separate arguments.
A better fix is to call “getent passwd” with no user controlled arguments and then parse the resulting list. This gets rid of the input sanitization problem entirely.
Your answer is mostly correct, except that when you tug on that thread the shelf comes off the wall, the plaster comes with it, and then it cracks the water pipes on the way to the floor.
Refactoring external invocations to use safe argument handling is a better way to fix it. Along with tests that exercise weird names.
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 sure, but it’s not a nonsense restriction? Who would have a username starting with a hyphen? I didn’t even know it was possible until today.
The better fix would be to not have the username pass through a parser looking for cli flags in the first place.