ssh-keysign-pwn - Linux 0-day로 비권한 사용자가 root 소유 파일을 읽는 PoC

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 발표 링크가 있나? 찾을 수가 없음
커널이 메인 브랜치에 수정사항을 공개 커밋하면서 스스로
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를 얻을 수 있다면 예외임
맞음. 다만 며칠 전 올라온

ssh-keysign-pwn - Linux 0-day로 비권한 사용자가 root 소유 파일을 읽는 PoC

추출된 키워드

원문

ssh-keysign-pwn - Linux 0-day로 비권한 사용자가 root 소유 파일을 읽는 PoC

Lobste.rs 의견들