ssh-keysign-pwn - PoC Linux 0-day yang Memungkinkan Pengguna Tanpa Hak Istimewa Membaca File Milik root

• ssh-keysign-pwn adalah PoC kerentanan Linux yang memungkinkan pengguna tanpa hak istimewa membaca file milik root, dan disebut menargetkan kernel sebelum 31e62c2ebbfd
• Bug utamanya adalah __ptrace_may_access() melewati pemeriksaan dumpable saat task->mm == NULL, dan do_exit() menjalankan exit_mm() lebih dulu daripada exit_files(), sehingga tercipta jendela saat file descriptor tetap terbuka
• Dalam jendela ini, jika uid pemanggil cocok dengan proses target, pidfd_getfd(2) akan berhasil, sehingga file descriptor yang terbuka dari proses yang sedang berhenti bisa diambil
• sshkeysign_pwn mengambil /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key, dengan memanfaatkan alur di mana ssh-keysign.c membuka key berizin 0600 lalu keluar dengan EnableSSHKeysign=no sebelum permanently_set_uid(), sehingga meninggalkan fd yang masih terbuka
• chage_pwn mengambil /etc/shadow, dengan membidik race saat keluar dalam alur di mana chage -l <user> menjalankan spw_open(O_RDONLY) lalu sepenuhnya melepas hak istimewa lewat setreuid(ruid, ruid)
• Eksekusinya dilakukan dengan make lalu ./sshkeysign_pwn untuk key host, dan ./chage_pwn root untuk mencetak isi /etc/shadow ke standard output; disebut biasanya berhasil dalam 100~2000 kali spawn
• Lingkungan yang telah dikonfirmasi adalah Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch, dan CentOS 9
• Sebagai PoC target terkontrol, vuln_target.c membuka /etc/shadow lalu menurunkan hak istimewa, dan exploit_vuln_target.c menunjukkan EPERM saat target masih hidup dan pencurian fd setelah SIGKILL
• Kerentanan ini dilaporkan oleh Qualys dan diperbaiki oleh Linus pada 2026-05-14; disebut juga bahwa Jann Horn telah menyoroti bentuk pencurian FD ini pada Oktober 2020
• README mencantumkan entri NVD https://nvd.nist.gov/vuln/detail/CVE-2026-46333

[GN⁺]

Komentar Lobste.rs

• Menonaktifkan ptrace saja tidak cukup. Pesan commit dan nama fungsi memang mudah menyesatkan, tetapi ptrace_may_access dipanggil dari banyak jalur, dan proof-of-concept (PoC) ini juga sebenarnya tidak memakai ptrace
  Belum ada mitigasi yang benar-benar pas; untuk saat ini tampaknya pilihannya hanya 1) secara terbatas menangani PoC spesifik ini dengan menghapus seluruh bit eksekusi pada /usr/lib64/misc/ssh-keysign, atau 2) memblokir pidfd_getfd dengan sesuatu seperti eBPF atau systemtap. Opsi pertama hanya layak dipertimbangkan kalau Anda tidak bisa menambal kernel atau mematikan sistem dan harus segera tidur
  Saya belum meninjau PoC-nya, dan seperti biasa tetap perlu berhati-hati saat menjalankan PoC acak yang diambil dari internet
  Advisory Qualys masih belum dipublikasikan, dan mereka sebelumnya mengatakan dengan sangat menyesal akan menghentikan distribusi ke linux-distros karena kebijakan keamanan kernel Linux. Situasinya memburuk karena LLM kini bisa dengan cepat membuat PoC dari commit perbaikan yang terlihat mencurigakan, sehingga hal yang dulu mungkin bisa menunggu beberapa hari sekarang jadi sulit
  Qualys benar-benar tim yang hebat, jadi disayangkan mereka tidak sempat mendapatkan momen yang tepat untuk mengumumkan ini sendiri. Kalau nanti dirilis, saya yakin advisory-nya akan sangat bagus
  openssh hanya target yang nyaman untuk serangan ini dan bukan pihak yang salah; binary setuid lain juga kemungkinan bisa dipilih sebagai target

  • Menurut pembaruan Qualys, mengatur /proc/sys/kernel/yama/ptrace_scope ke 2 (admin-only attach) atau 3 (no attach) akan memblokir semua eksploit yang sudah diketahui. Namun, secara teoretis masih mungkin ada cara eksploitasi lain
  • Sebagai mitigasi cepat, saya meminta LLM Opus menulis skrip systemtap untuk memblokir pidfd_getfd, dan hasilnya ada di sini. Harus dijalankan dengan stap -g block_pidfd_getfd.stp, dan seperti apa pun yang diambil dari internet, skrip itu wajib ditinjau sebelum dijalankan
  • Apakah ada tautan ke pengumuman linux-distros? Saya tidak bisa menemukannya

• Saya berharap kernel berhenti membocorkan 0-day sendiri dengan memublikasikan commit perbaikan ke branch utama. Di commit bahkan tertulis “Reported-by: Qualys”, jadi jelas ini adalah perbaikan keamanan

  • Minggu lalu ada perdebatan besar soal masalah ini
    Greg K-H menulis bahwa tim keamanan kernel tidak bisa memilih siapa yang mendapat pengungkapan awal untuk perbaikan keamanan, sehingga pada akhirnya tidak ada siapa pun yang mendapatkannya lebih awal
  • Lalu sebagai gantinya seharusnya bagaimana?

• Ini bukan masalah ssh, ini masalah Linux. Judulnya juga seharusnya mencerminkan itu

  • Saya setuju judulnya menyesatkan, tetapi saya juga tidak punya ide lain untuk judulnya. Masih bisa diubah, jadi akan bagus kalau ada usulan
  • Benar, tetapi di saat yang sama, jika ssh-keysign memeriksa EnableSSHKeysign=yes lebih dulu sebelum membuka private host key, maka sistem dengan opsi ini nonaktif seperti default tidak akan rentan terhadap pencurian host key. Cukup mengejutkan bahwa ssh-keysign tidak memeriksa opsi itu paling awal

• Proof-of-concept ini menyenangkan karena sangat singkat, dan perangkat saya juga memang rentan
  Tampaknya ini memungkinkan akses ke file descriptor yang dibuka oleh executable setuid dalam kondisi tertentu. Saya tidak melihat alasan mengapa ini harus terbatas hanya untuk baca, dan rasanya bisa dipelintir menjadi eskalasi hak istimewa lokal (LPE) tanpa perlu memecahkan hash
  PoC yang ini saja bisa dipatahkan dengan chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage. Jalur ssh-keysign mungkin perlu disesuaikan, dan Anda juga bisa melihat halaman manual. Tetapi ini tidak memperbaiki masalah intinya, dan tampaknya juga bisa dilewati. Setahu saya tidak ada mitigasi lain
  Masalah ini diperbaiki di ptrace: slightly saner 'get_dumpable()' logic, dan karena itu jadi terungkap ke publik. Baru 10 jam yang lalu
  Ada juga pengumuman publik Qualys ke oss-security, yang mengatakan advisory-nya belum dirilis agar distro dan pengguna punya waktu untuk menambal. Sepertinya ini akan jadi bacaan yang menarik; sementara itu, lihat penjelasan Brad Spengler dari grsecurity. Tweet itu tampaknya yang memicu pengembangan PoC kali ini

  • Saya sudah mencoba menjalankan PoC-nya, tetapi tidak berhasil memenangkan race-nya. Namun pasangan exploit_vuln_target/vuln_target berfungsi dengan baik. Tidak bagus

• Secara realistis, ini tampaknya memengaruhi sistem yang sudah memiliki pengguna dengan akun tanpa hak istimewa. Artinya, kalau tidak ada login yang valid, ini tidak bisa langsung dipakai untuk mencapai remote code execution pada server dengan SSH yang terekspos ke internet, benar?

  • Benar. Tetapi ada pengecualian jika Anda bisa mendapatkan RCE lewat layanan lain, seperti remote code execution nginx yang muncul beberapa hari lalu