ssh-keysign-pwn - Linux 0-day로 비권한 사용자가 root 소유 파일을 읽는 PoC
(github.com/0xdeadbeefnetwork)- ssh-keysign-pwn은 비권한 사용자가 root 소유 파일을 읽을 수 있게 하는 Linux 취약점 PoC로,
31e62c2ebbfd이전 커널이 대상이라고 밝힘 - 핵심 버그는
__ptrace_may_access()가task->mm == NULL일 때 dumpable 검사를 건너뛰고,do_exit()가exit_mm()을exit_files()보다 먼저 실행해 파일 디스크립터가 열린 채 남는 창이 생기는 구조임 - 이 창에서 호출자의 uid가 대상 프로세스와 일치하면
pidfd_getfd(2)가 성공해, 종료 중인 프로세스의 열린 파일 디스크립터를 가져올 수 있음 sshkeysign_pwn은/etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key를 가져오며,ssh-keysign.c가 0600 권한의 키를 연 뒤permanently_set_uid()전에EnableSSHKeysign=no로 종료하면서 열린 fd를 남기는 흐름을 이용함chage_pwn은/etc/shadow를 가져오며,chage -l <user>가spw_open(O_RDONLY)후setreuid(ruid, ruid)로 권한을 완전히 내려놓는 흐름에서 종료 레이스를 노림- 실행은
make후./sshkeysign_pwn으로 호스트 키를,./chage_pwn root로/etc/shadow내용을 표준 출력에 출력하는 방식이며, 100~2000회 스폰 안에 적중한다고 밝힘 - 확인된 환경은 Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch, CentOS 9임
- 제어된 대상 PoC로
vuln_target.c는/etc/shadow를 연 뒤 권한을 내리고,exploit_vuln_target.c는 살아 있는 동안의EPERM과SIGKILL이후 fd 탈취를 보여줌 - 취약점은 Qualys가 보고했고 Linus가 2026-05-14에 수정했으며, Jann Horn은 2020년 10월에 FD 탈취 형태를 짚었다고 밝힘
- README는 NVD 항목으로
https://nvd.nist.gov/vuln/detail/CVE-2026-46333을 제시함
Lobste.rs 의견들
-
ptrace 비활성화만으로는 충분하지 않음. 커밋 메시지와 함수 이름 때문에 오해하기 쉽지만,
ptrace_may_access는 여러 경로에서 호출되고 이 개념증명(PoC)도 실제로는 ptrace를 쓰지 않음
완화책은 마땅치 않고, 지금으로서는 1) 이 특정 PoC에만 약하게 대응하려고/usr/lib64/misc/ssh-keysign의 전체 실행 비트를 제거하거나, 2) eBPF나 systemtap 같은 것으로pidfd_getfd차단을 하는 정도로 보임. 전자는 커널 패치나 종료를 못 하고 당장 자야 할 때나 고려할 수준임
PoC는 검토하지 않았고, 인터넷에서 받은 임의 PoC 실행에는 늘 그렇듯 주의가 필요함
Qualys 권고문은 아직 공개되지 않았고, Linux 커널 보안 정책 때문에 linux-distros 배포를 매우 유감스럽게 중단하겠다고 한 바 있음. LLM이 수상해 보이는 수정 커밋에서 PoC까지 빠르게 만들어낼 수 있게 되면서 상황이 거칠어졌고, 예전 같으면 며칠 기다리는 것도 가능했을 것임
Qualys는 정말 훌륭한 팀인데, 이번 일을 직접 발표할 제대로 된 순간을 갖지 못하게 된 건 아쉬움. 공개되면 분명 훌륭한 권고문일 거라고 봄
openssh는 이 공격에 편리한 표적일 뿐 잘못은 없고, 다른 setuid 바이너리도 표적으로 고를 수 있을 것임- Qualys 업데이트에 따르면
/proc/sys/kernel/yama/ptrace_scope를 2(admin-only attach)나 3(no attach)으로 설정하면 알려진 모든 익스플로잇을 막는다고 함. 다만 이론적으로는 다른 악용 방식이 있을 수 있음 - 빠른 완화책으로 LLM인 Opus에게
pidfd_getfd를 막는 systemtap 스크립트를 작성하게 했고, 결과는 여기에 있음.stap -g block_pidfd_getfd.stp로 실행해야 하며, 인터넷에서 받은 모든 것처럼 실행 전에 반드시 스크립트를 검토해야 함 - linux-distros 발표 링크가 있나? 찾을 수가 없음
- Qualys 업데이트에 따르면
-
커널이 메인 브랜치에 수정사항을 공개 커밋하면서 스스로 0-day 공개를 하는 일을 멈췄으면 함. 커밋에 “Reported-by: Qualys”라고까지 적혀 있으니 명백한 보안 수정임
-
이건 ssh 문제가 아니라 Linux 문제임. 제목도 그렇게 보여야 함
- 제목이 오해를 부른다는 데 동의하지만, 어떻게 제목을 붙여야 할지 다른 생각이 없었음. 아직 수정할 수 있으니 제안이 있으면 좋겠음
- 맞지만, 동시에
ssh-keysign이 개인 호스트 키를 열기 전에EnableSSHKeysign=yes를 먼저 확인했다면, 기본값처럼 이 옵션이 꺼진 시스템은 호스트 키 탈취에 취약하지 않았을 것임.ssh-keysign이 가장 먼저 이 옵션을 확인하지 않는다는 점이 놀라움
-
개념증명이 기분 좋을 정도로 짧고, 내 장비들도 실제로 취약했음
특정 조건에서 setuid 실행 파일이 연 파일 디스크립터에 접근할 수 있게 해주는 것으로 보임. 이게 읽기에만 한정될 이유가 안 보이고, 해시를 크래킹하지 않아도 되는 로컬 권한 상승(LPE) 으로 비틀 수 있을 것 같음
이 PoC만은chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage로 깨뜨릴 수 있음.ssh-keysign경로는 바꿔야 할 수 있고 매뉴얼 페이지도 참고할 수 있음. 하지만 핵심 문제는 고치지 못하며 우회도 가능할 것 같음. 아는 한 다른 완화책은 없음
이 문제는 ptrace: slightly saner 'get_dumpable()' logic에서 수정되었고, 그래서 공개되어 버렸음. 고작 10시간 전임
oss-security에 보낸 Qualys의 공개 발표도 있음. 배포판과 사용자에게 패치할 시간을 주려고 아직 권고문은 공개하지 않는다고 함. 꽤 흥미로운 내용이 될 것 같고, 그동안은 grsecurity의 Brad Spengler 해설을 보면 됨. 이 트윗이 이번 PoC 개발을 촉발한 것으로 보임- PoC를 실행해 봤지만 경합에서 이기지는 못했음. 대신
exploit_vuln_target/vuln_target쌍은 잘 동작했음. 별로 좋지 않음
- PoC를 실행해 봤지만 경합에서 이기지는 못했음. 대신
-
현실적으로는 이미 비권한 계정을 가진 사용자가 있는 시스템에 영향을 주는 것 같음. 즉, 유효한 로그인이 없다면 SSH가 인터넷에 노출된 서버에서 이걸로 바로 원격 코드 실행을 달성할 수는 없는 게 맞나?
- 맞음. 다만 며칠 전 올라온 nginx 원격 코드 실행처럼 다른 서비스로 RCE를 얻을 수 있다면 예외임