TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access(tailscale.com)
113 pointsby jervant5 hours ago12 comments
  • tptacek5 hours ago
    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.)

    • RossBencina4 hours ago
      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?
      • anilakar6 minutes ago
        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.

      • yjftsjthsd-h3 hours ago
        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.
    • iririririr4 hours ago
      you can also add parameters to env vars in some popular cloud providers for the same effect.
  • doublepg235 hours ago
    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.
    • OJForda minute ago
      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.
    • bakies4 hours ago
      Yeah pretty much just use tailscale as a vpn.. do one thing as they say.
    • jdiff4 hours ago
      I've used it before to access my tailnet machines through a browser on a machine I can't download software on.
      • Shorelan hour ago
        I just don't use stranger's machines to access my personal stuff. Possibly compromised stranger's machines. I don't see the benefit about that, as I have more laptops than I need.
    • dgacmu4 hours ago
      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.
    • isatty4 hours ago
      Convenience for the most part but in general, I agree. I like having it as an option.
  • drnick13 hours ago
    I'll stick to my 100% self-hosted Wireguard setup, thank you very much.
    • nicman23an hour ago
      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"
    • m_mueller2 hours ago
      Why not tailscale plus head scale for self hosting?
      • diarrheaan hour ago
        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'm sure it is a great product, I just never tried it, do not seem the target audience.

        What confuses me is the often accompanying, sometimes aggressive anti-selfhosting stance in these sorts of threads. I do not see this in other topics, e.g. someone mentioning they run Jellyfin isn't met with "why not Plex?". Where does that come from? We are on HackerNews, not ProductShillNews, aren't we? I guess self hosting Wireguard is too boring to warrant any further discussion? The VPN equivalent of a Toyota Corolla.

        • MobiusHorizons29 minutes ago
          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.
          • diarrhea25 minutes ago
            NAT busting is a great point.
        • fragmede22 minutes ago
          How do I install wire guard on my mom's Apple TV?
    • doctorpangloss2 hours ago
      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
  • e405 hours ago
    So, giving access via tailscale but using OpenSSH is safe, right?
    • lugoues5 hours ago
      Yes, this only involves their wrapper that is managed by ACL rules.
    • iririririr4 hours ago
      as much as handing control to a remote third part is, yes.
      • cevn3 hours ago
        Good point. I self host headscale but it also has the ssh feature, probably also insecure.
  • mintflow3 hours ago
    >>> 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?

    • tristanjan hour ago
      I presume Ada Logics has access to Anthropic's Mythos model via Project Glasswing, and Ada Logics discovered this exploit during their vulnerability research.
  • mintflow3 hours ago
    pure logic error, the undergoing tailscale rust rewrite can't help this too:)
    • bestouff44 minutes ago
      If it used one of the standard arguments-handling crates (e.g. "clap") there's no way it can happen.
    • mintflow3 hours ago
      that said, the limit impact perhaps is only affected multiple users in tailnet if the ACL is not configure correctly

      As single tailnet+single user, perhaps it's just okay

  • modeless4 hours ago
    Tailscale SSH has caused me other problems in the past because it takes over port 22. I'm not a fan.
    • LeoPanthera4 hours ago
      That is what it's supposed to do, though. It's not a secret.
    • huflungdung4 hours ago
      [dead]
  • luciana1u3 hours ago
    tailscale ssh: replacing a 25-year-old battle-tested codebase with a startup's Go rewrite and then acting surprised when it has bugs
    • 3 hours ago
      undefined
  • kbumsik5 hours ago
    Why own numbering instead of CVE?
    • vngzs5 hours ago
      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
      • bigfatkitten4 hours ago
        And sometimes it’s just impossible to get a CVE number in a reasonable amount of time, or indeed at all.
    • wereHamster2 hours ago
      Some reasons why an org might want to become their own CNA: https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/
  • cyberax5 hours ago
    > "Tailscale SSH now rejects usernames with leading dashes."

    Really? That's the fix?

    A proper fix is to use "--" to separate arguments.

    • valleyer4 hours ago
      A proper fix is not to shell out to a command at all; use getpwnam(3) or similar.
    • catlifeonmars2 hours ago
      “--“ doesn’t work on all versions of getent.

      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.

      • cyberax33 minutes ago
        Are there any actual systems that can run Tailscale and that have faulty getent?
    • sedatk5 hours ago
      Their fix just future-proofs it in case the same bug gets reintroduced.
      • turbert3 hours ago
        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.
        • raggi2 hours ago
          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.

      • cyberax4 hours ago
        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.

        • sedatk4 hours ago
          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.

          • turbert3 hours ago
            > 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.

  • farfatched2 hours ago
    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.

  • ishweta19 minutes ago
    [dead]