*Published: 2024-06-21*
Tailscale has become a popular choice for secure networking, using the power of WireGuard and Multi-Factor Authentication (MFA) to let you build private virtual networks between your devices. But in early 2023, a subtle bug was discovered in how Tailscale's SSH feature handled user groups on FreeBSD, exposing users to serious privilege escalation risks. Here, we’ll break down CVE-2023-28436, explain what went wrong, show a bit of the affected code, and give clear advice on how to protect yourself.
Affected Software: Tailscale version 1.34. up to (but not including) 1.38.2 on FreeBSD
- Root Cause: Difference in how FreeBSD’s setgroups works versus POSIX, failing to clear unprivileged group memberships.
What Went Wrong? (Explained Simply)
When you use Tailscale SSH, the Tailscale client makes sure users only get the permissions they’re allowed based on your SSH rules. In most systems, that means switching to the right user ID and group ID before running any commands.
On FreeBSD systems, though, the code that was supposed to clear old group privileges didn't actually work as expected. Specifically, due to a difference between the way the setgroups system call works in FreeBSD compared to how it behaves in standard POSIX systems, Tailscale’s method for restricting group access simply didn’t clear all the existing groups from the session. As a result, if a user connected via Tailscale SSH in a *non-interactive session* (like running ssh user@host command), commands could accidentally run with *higher group privileges* than they were supposed to.
Tailscale’s logic for dropping group privileges looks like this (pseudo-Go code, simplified)
// This code tries to set the group list for a user before exec'ing a command
syscall.Setgroups(userGroups)
On POSIX, if you want to restrict a process to only the groups in userGroups, you call setgroups with the new list, then set the main group ID (setgid) and user ID (setuid). On FreeBSD, however, the behavior isn’t the same: unless you’re careful, the previous group memberships — possibly belonging to the tailscaled daemon, which often runs with extra privileges — can remain.
The real problem is: Tailscale SSH rules might say to restrict someone to a basic user account, but the process kept the more powerful groups from the Tailscale daemon.
A Minimal (Illustrative) Exploit
Suppose your Tailscale SSH rule allowed a non-root user to run commands. With this bug, you could connect and run:
ssh nonrootuser@freebsd-host id
And see that your *group id* (or supplementary groups) is *higher than expected*
uid=1001(nonrootuser) gid=(wheel) groups=(wheel),1001(nonrootuser)
Under proper separation, a normal user shouldn’t see themselves as a member of the privileged wheel group. But because FreeBSD didn’t reset groups, that group “leaked” from the privileged tailscaled process. If any system tools rely on group membership for access controls (for example, allowing wheel members to use sudo), you now have a real privilege escalation vector.
Why Not All SSH Sessions?
The bug only affects *non-interactive* SSH sessions. In interactive sessions (like when you actually get a shell), a different process path is triggered, and user/group privileges are handled properly. This is why automation scripts and command-line invocations, rather than full shell logins, are at risk.
The Fix
Tailscale released version 1.38.2, which fixes the bug by properly handling group memberships for FreeBSD in their SSH implementation. You must upgrade your Tailscale instance to 1.38.2 or newer to be safe.
Get the latest release here
Or update using your package manager
sudo pkg upgrade tailscale
or, if you install from source:
go install tailscale.com/cmd/tailscaled@latest
References
- GitHub Security Advisory - CVE-2023-28436
- Tailscale Release Notes
- FreeBSD setgroups(2) Manual
Bottom Line
While Tailscale is still a solid choice for secure networking and remote access, no software is perfect. CVE-2023-28436 is a classic example of how platform differences (in this case, FreeBSD vs. other flavors of Unix) can spark subtle, dangerous bugs. The fix is simple: Update to Tailscale 1.38.2 or later. Always keep your security tools up to date, and remember: least privilege isn’t just a rule — it’s a moving target.
Have other questions about CVE-2023-28436, FreeBSD, or Tailscale? Let us know in the comments!
*This post is an exclusive, plain-language breakdown for the security community. Please share and spread awareness!*
Timeline
Published on: 03/23/2023 20:15:00 UTC
Last modified on: 03/31/2023 13:28:00 UTC