Tailscale SSH 보안 취약점 TS-2026-009

Tailscale은 기존 Tailscale ACL 권한을 가진 사용자가 대상 호스트에서 root 권한으로 권한을 상승시킬 수 있었던 TS-2026-009로 식별된 심각한 보안 취약점을 해결했습니다. 이 결함은 Tailscale SSH가 시스템 유틸리티와 상호 작용할 때 사용자 이름을 처리하는 방식에서 비롯되었으며, 특히 대시(-)로 시작하는 사용자 이름이 명령줄 인수로 해석될 수 있도록 허용했습니다.

근본 원인: 안전하지 않은 인수 처리

이 취약점은 Tailscale SSH가 비밀번호 항목을 검색하기 위해 getent(1) 명령에 사용자 이름을 인수로 직접 전달했기 때문에 발생했습니다. 입력값이 적절히 정제되거나 구분되지 않았기 때문에, 사용자는 대시로 시작하는 사용자 이름(예: -i)을 제공할 수 있었고, getent는 이를 리터럴 사용자 이름이 아닌 플래그로 해석했습니다.

이 동작은 Tailscale ACL을 통해 유효한 SSH 액세스 권한을 가진 공격자가 의도된 사용자 제한을 우회하고 root 로그인을 획득할 수 있게 했습니다. 이는 사용자 제공 데이터가 기본 시스템 호출에 의해 제어 명령으로 오해받는 전형적인 인수 주입(argument injection) 취약점의 사례입니다.

해결 방법 및 수정 사항

Tailscale은 이러한 유형의 인수 주입을 방지하기 위해 여러 제한 사항을 구현했습니다:

• Leading Dashes 거부: Tailscale SSH는 이제 대시로 시작하는 모든 사용자 이름을 명시적으로 거부합니다.
• 숫자 사용자 이름 제한: 모호성을 피하고 추가적인 잠재적 공격을 방지하기 위해, Tailscale은 이제 SSH를 통해 UID 또는 숫자 전용 사용자 이름의 사용을 허용하지 않습니다.

기술 커뮤니티 분석

TS-2026-009의 공개는 시스템 호출에 대한 모범 사례와 기존 도구를 대체할 때의 위험성에 대해 보안 전문가들 사이에서 상당한 논의를 불러일으켰습니다.

인수 처리 모범 사례

기술 비평가들은 getent와 같은 하위 프로세스를 호출하는 것이 네이티브 API 또는 시스템 호출을 사용하는 것보다 본질적으로 더 위험하다고 지적했습니다. 사용자 @jcarrano가 언급한 바와 같이:

usernames were passed as arguments to getent(1) to retrieve the corresponding passwd entry Always try to use actual API/system calls (in this case getpwnam) instead of calling sub-processes.

또한, 일부 개발자들은 대시가 포함된 사용자 이름을 거부하는 수정 방식이 구조적 해결책이라기보다는 임시방편(workaround)이라고 주장했습니다. 더 강력한 접근 방식은 명령줄 플래그의 끝을 알리고 모든 후속 인수가 위치 파라미터로 처리되도록 보장하는 -- 구분자를 사용하는 것이었을 것입니다.

Tailscale SSH vs. OpenSSH

이번 사건은 독점적 또는 새로운 SSH 구현체를 사용하는 것과 업계 표준인 OpenSSH를 사용하는 것 사이의 논쟁을 다시 불러일으켰습니다. 여러 커뮤니티 구성원들은 수십 년간 검증된 보안 기록을 가진 OpenSSH를 선호한다고 표현했습니다.

tailscale ssh: replacing a 25-year-old battle-tested codebase with a startup's Go rewrite and then acting surprised when it has bugs

일부 조직은 공격 표면을 최소화하기 위해 NAT traversal 및 VPN 기능만을 위해 Tailscale을 사용하고, 실제 인증 및 액세스 관리는 전통적인 OpenSSH 및 SSH 인증서를 사용하는 방식을 계속 유지하고 있습니다.

영향 요약

Feature	Vulnerability	Impact	Fix
Tailscale SSH	getent를 통한 인수 주입	Root 권한 상승	Leading dashes 및 숫자 사용자 이름 차단