RegreSSHion: Eksekusi Kode Jarak Jauh (RCE) pada Server OpenSSH Linux Berbasis glibc

 (qualys.com)
1 poin oleh GN⁺ 2024-07-02 | 1 komentar | Bagikan ke WhatsApp
  • Karena race condition pada handler sinyal di server OpenSSH sshd, klien yang belum terautentikasi dapat memicu eksekusi kode jarak jauh pada server dengan konfigurasi default jika tidak melakukan autentikasi dalam batas waktu praautentikasi LoginGraceTime
  • Kerentanan ini adalah regresi (regression) dari CVE-2006-5051 tahun 2006, dan muncul kembali pada versi 8.5p1 hingga sebelum 9.8p1 setelah commit OpenSSH 8.5p1 pada Oktober 2020 menghapus pengaman dari sigdie()
  • Pada Linux berbasis glibc, syslog() memanggil fungsi yang tidak async-signal-safe seperti malloc() dan free(), sehingga dapat berujung pada RCE root tanpa autentikasi di kode privileged sshd yang tidak di-sandbox
  • Eksperimen dilakukan pada mesin virtual i386 dan jaringan stabil dengan jitter paket sekitar 10ms; pada Debian 12.5.0 OpenSSH 9.2p1, rata-rata dibutuhkan sekitar 10.000 percobaan, dan sekitar 6–8 jam hingga mendapatkan root shell dengan kondisi MaxStartups=100 dan LoginGraceTime=120
  • OpenSSH memperbaikinya lewat commit 81c1099 pada 6 Juni 2024; jika pembaruan atau kompilasi ulang sulit dilakukan, mengatur LoginGraceTime 0 dapat mencegah RCE, tetapi risiko DoS karena habisnya koneksi MaxStartups tetap ada

Titik Terjadinya Kerentanan

  • Masalah pada OpenSSH sshd bermula dari handler SIGALRM yang berjalan sebelum autentikasi
    • Jika klien tidak melakukan autentikasi dalam LoginGraceTime, handler SIGALRM dipanggil secara asinkron
    • Handler ini memanggil fungsi yang tidak async-signal-safe, seperti syslog()
    • Nilai defaultnya adalah LoginGraceTime=120 detik, dan pada versi OpenSSH lama nilainya 600 detik
  • Kerentanan ini adalah regresi dari CVE-2006-5051
    • CVE-2006-5051 adalah race condition pada handler sinyal di OpenSSH sebelum 4.4, yang dilaporkan oleh Mark Dowd pada 2006
    • Pada Oktober 2020, commit 752250c di OpenSSH 8.5p1 secara tidak sengaja menghapus #ifdef DO_LOG_SAFE_IN_SIGHAND dari sigdie()
  • Cakupan dampak berbeda jelas menurut versi
    • OpenSSH sebelum 4.4p1: rentan jika patch terkait CVE-2006-5051 atau CVE-2008-4109 belum di-backport
    • OpenSSH 4.4p1 hingga sebelum 8.5p1: sigdie() diubah menjadi pemanggilan _exit(1) yang aman, sehingga tidak rentan terhadap race condition ini
    • OpenSSH 8.5p1 hingga sebelum 9.8p1: kembali rentan karena pengaman dihapus

Lingkungan yang Terdampak dan Pengecualian

  • Target eksploitasi jarak jauh adalah Linux berbasis glibc
    • syslog() milik glibc secara internal memanggil fungsi yang tidak async-signal-safe seperti malloc() dan free()
    • Kode rentan berada di kode privileged sshd, berjalan tanpa sandbox dan dengan full privilege
    • Akibatnya, eksekusi kode root jarak jauh tanpa autentikasi dimungkinkan
  • libc atau sistem operasi lain tidak termasuk dalam cakupan investigasi
  • OpenBSD tidak rentan
    • Handler SIGALRM di OpenBSD memanggil syslog_r() alih-alih syslog()
    • syslog_r() adalah versi yang lebih async-signal-safe yang dibuat OpenBSD pada 2001

Prasyarat Riset Eksploitasi Jarak Jauh

  • Untuk mengeksploitasi race condition ini dari jarak jauh, tiga masalah perlu dipecahkan
    • Diperlukan jalur kode yang membuat sshd berada dalam keadaan tidak konsisten ketika SIGALRM menyela pada saat yang tepat
    • Perlu mencapai jalur kode tersebut dan meningkatkan peluang interupsi pada waktu yang benar
    • Timing tersebut harus bisa dicapai bahkan di lingkungan jaringan jarak jauh
  • Riset dimulai dari lingkungan i386 OpenSSH lama, bukan langsung berhadapan dengan teknik proteksi modern, lalu diperluas ke versi terbaru
  • Kondisi eksperimen memiliki batasan yang jelas
    • Hanya menargetkan mesin virtual, bukan server bare-metal
    • Jaringannya adalah link yang relatif stabil dengan jitter paket sekitar 10ms
    • Banyak bagian eksploit masih dapat ditingkatkan
    • Pekerjaan eksploit amd64 sudah dimulai, tetapi jauh lebih sulit karena ASLR yang lebih kuat

Eksperimen pada Target OpenSSH Lama

  • Debian 3.0r6, OpenSSH 3.4p1

    • Targetnya adalah SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, lingkungan Debian 3.0r6 tahun 2005
    • Versi Debian ini adalah versi Debian pertama dengan privilege separation aktif secara default, dan patch kerentanan utama saat itu sudah diterapkan
    • Eksploitasi memanfaatkan interupsi free() dan keadaan heap yang tidak konsisten
      • Pemanggilan free() di dalam kode parsing kunci publik disela oleh SIGALRM
      • Setelah itu, keadaan heap yang tidak konsisten dimanfaatkan pada free() lain di dalam packet_close()
    • glibc 2.2.5 belum memiliki hardening terhadap teknik unlink() dari Solar Designer
    • Serangan menimpa __free_hook untuk mengalihkan alur eksekusi ke alamat shellcode di heap
    • Versi Debian ini tidak memiliki ASLR maupun NX
    • Setelah perbaikan timing, rata-rata dibutuhkan sekitar 10.000 percobaan
    • Dengan MaxStartups=10 dan LoginGraceTime=600, rata-rata dibutuhkan sekitar 1 minggu hingga mendapatkan root shell jarak jauh

  • Ubuntu 6.06.1, OpenSSH 4.2p1

    • Targetnya adalah SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3, lingkungan Ubuntu 6.06.1 tahun 2006
    • Ini adalah versi Ubuntu terakhir yang masih rentan terhadap CVE-2006-5051
    • Karena glibc 2.3.6 mengambil mandatory lock saat masuk ke fungsi keluarga malloc, metode mengeksploitasi pemanggilan malloc lain setelah interupsi malloc berujung pada deadlock
    • Jalur eksploitasi final memanfaatkan PAM
      • pam_start() mengatur pointer global sshpam_handle milik sshd
      • Jika _pam_add_handler() disela, field next yang belum diinisialisasi dapat tersisa
      • Ketika pam_end() dipanggil di handler SIGALRM, pointer arbitrer dapat diteruskan ke free()
    • Karena teknik unlink() lama glibc sudah diblokir, digunakan versi fastbin dari Malloc Maleficarum House of Mind
    • Fake arena diarahkan ke .got.plt milik sshd, lalu entri _exit() ditimpa dengan alamat shellcode heap
    • Heap Ubuntu ini secara default dapat dieksekusi
    • Rata-rata dibutuhkan sekitar 10.000 percobaan
    • Dengan MaxStartups=10 dan LoginGraceTime=120, rata-rata dibutuhkan sekitar 1–2 hari hingga mendapatkan root shell jarak jauh
    • Penyerang yang kurang beruntung dapat membuat semua 10 koneksi MaxStartups mengalami deadlock sebelum mendapatkan root shell

Eksperimen Debian 12.5.0, OpenSSH 9.2p1

  • Jalur syslog() dan malloc glibc

    • Targetnya adalah SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2, lingkungan current stable Debian 12.5.0 tahun 2024
    • Lingkungan ini rentan terhadap regresi CVE-2006-5051
    • Handler SIGALRM pada versi ini tidak memanggil packet_close() atau pam_end(), tetapi masuk ke jalur syslog()
      • grace_alarm_handler() memanggil sigdie()
      • sigdie() memanggil syslog() lewat sshlogv() dan do_log()
    • syslog() pada Debian glibc 2.36 memanggil malloc saat pemanggilan pertama
      • __tzfile_read() dipanggil melalui jalur __localtime64_r()
      • fopen() memanggil malloc(304) untuk struktur FILE
      • malloc(4096) juga dipanggil untuk read buffer internal
    • Sejak Oktober 2017, malloc glibc tidak mengambil mandatory lock dalam situasi single-thread
    • Pada proses single-thread seperti sshd, muncul kemungkinan mengeksploitasi race pada malloc

  • Kondisi ASLR dan Batasan i386

    • Lingkungan Debian 12.5.0 i386 memiliki kelemahan ASLR
    • PIE sshd, heap, sebagian besar library, dan stack umumnya diacak
    • glibc sendiri selalu dipetakan di 0xb7200000 atau 0xb7400000
    • Alamat glibc dapat ditebak dengan probabilitas setengah
    • Eksploit mengasumsikan glibc dipetakan di 0xb7400000
    • Alasannya, alamat ini sedikit lebih sering muncul dibanding 0xb7200000

  • Ketidakkonsistenan heap dan eksploitasi struktur FILE

    • Jalur malloc yang dipilih adalah jalur split yang membagi free chunk besar menjadi dua
    • Chunk yang akan dikembalikan dan remainder chunk terbentuk
    • Jika SIGALRM menyela setelah remainder chunk ditautkan ke unsorted list tetapi sebelum field size diinisialisasi, terjadi ketidakkonsistenan heap
    • Penyerang mengendalikan field size dari remainder chunk lewat sisa data dari alokasi heap sebelumnya
    • Remainder chunk dibuat lebih besar dari ukuran sebenarnya sehingga tumpang tindih dengan chunk heap lain
    • Saat malloc di dalam handler SIGALRM menggunakan chunk ini, memori heap tercemar
    • Targetnya adalah struktur FILE yang dialokasikan fopen() di heap dalam __tzfile_read()
      • Dengan heap corruption terbatas, 1 byte _vtable_offset pada struktur FILE ditimpa
      • Fungsi libio glibc kemudian mencari pointer vtable di offset lain, bukan posisi default
      • Penyerang mengendalikan fake vtable pointer dan pointer _codecvt di lokasi tersebut menggunakan sisa data dari alokasi heap sebelumnya
    • Pada glibc i386, teknik ini dapat memanggil pointer fungsi arbitrer __fct selama __fread_unlocked()
    • glibc amd64 tampaknya tidak menggunakan _vtable_offset

  • Heap layout dan 27 race window

    • Karena sulit memenangkan race condition hanya dengan satu small race window, dibuat 27 pasang large hole dan small hole
    • 28 pasang akan melampaui PACKET_MAX_SIZE 256KB
    • Paket final memaksa urutan malloc(~4KB), malloc(304), malloc(~4KB), malloc(304)
    • Jika setiap split large hole disela pada momen yang tepat, fopen() milik handler SIGALRM mengalokasikan small hole yang sesuai sebagai struktur FILE
    • Untuk membuat heap layout, digunakan kode parsing kunci publik sshd
      • Jalur cert_parse() dan cert_free() menjalankan urutan malloc() dan free() yang hampir arbitrer
      • Karena tidak menemukan memory leak, chunk tcache digunakan sementara sebagai barrier chunk
    • Lima jenis paket kunci publik dikirim
      • a/ Membuat alokasi heap yang tidak dapat dikendalikan masuk ke chunk tcache
      • b/ Membuat 27 pasang large/small hole dan barrier chunk
      • c/ Menulis fake header, fake footer, fake vtable, dan pointer _codecvt
      • d/ Mengalokasikan dan membebaskan string besar hampir 256KB untuk memindahkan hole dari unsorted list ke bin malloc masing-masing
      • e/ Memaksa urutan malloc terakhir dan membuka 27 small race window

  • Strategi Timing untuk Versi Modern

    • Strategi timing berbasis feedback yang digunakan pada versi lama tidak berhasil pada target OpenSSH 9.2p1
    • Parsing kunci publik kelima memakan waktu sekitar 10ms, membuat large race window terlalu besar
    • user_specific_delay() yang diperkenalkan di OpenSSH 7.8p1 menunda respons hingga sekitar 9ms dan merusak feedback lama
    • Strategi baru membandingkan waktu respons dari dua jenis error yang disengaja
      • Mengirim paket yang memicu error tepat sebelum parsing kunci publik
      • Mengirim paket yang memicu error tepat setelah parsing kunci publik
      • Waktu parsing kunci publik terakhir diukur dari selisih waktu respons keduanya
    • Dengan strategi ini, race condition dimenangkan rata-rata dalam sekitar 10.000 percobaan
    • Dengan MaxStartups=100 dan LoginGraceTime=120, rata-rata dibutuhkan sekitar 3–4 jam hingga race condition dimenangkan
    • Karena ASLR, rata-rata dibutuhkan sekitar 6–8 jam hingga mendapatkan root shell jarak jauh

Status Eksploit amd64

  • Target amd64 ditetapkan sebagai Rocky Linux 9
    • Image target adalah Rocky-9.4-x86_64-minimal.iso
    • OpenSSH 8.7p1 rentan terhadap race condition handler sinyal ini
    • Karena kelemahan ASLR, glibc dipetakan pada kelipatan 2MB sehingga partial pointer overwrite menjadi lebih kuat
  • syslog() pada glibc 2.34 di Rocky Linux 9 secara internal memanggil __open_memstream()
    • Struktur FILE di-malloc() di heap
    • calloc(), realloc(), dan free() juga dipanggil, memberi ruang tambahan
  • Berdasarkan primitive heap corruption, dua struktur FILE yang dialokasikan di heap, dan 21 bit tetap pada alamat glibc, eksploitasi dinilai mungkin juga pada amd64
    • Perkiraan waktunya lebih lama daripada 6–8 jam pada i386, tetapi dinyatakan diharapkan kurang dari satu minggu
  • Ada juga observasi terpisah tentang Ubuntu 24.04
    • Ubuntu 24.04 tidak mengacak ulang ASLR child sshd, melainkan hanya mengacaknya sekali saat boot
    • Penyebabnya dilacak ke systemd-socket-activation.patch yang mematikan rexec_flag
    • Secara umum ini bukan pilihan yang baik, tetapi pada kerentanan ini hal tersebut mencegah eksploitasi karena syslog() di dalam handler SIGALRM bukan pemanggilan syslog() pertama sehingga tidak memanggil fungsi malloc
    • Patch terkait: https://git.launchpad.net/ubuntu/+source/…

Patch dan Mitigasi

  • OpenSSH memperbaiki race condition ini lewat commit 81c1099 pada 6 Juni 2024
    • 81c1099: menambahkan fitur agar sshd(8) memberi penalti pada client behavior yang bermasalah
    • Kode yang tidak async-signal-safe dipindahkan dari handler SIGALRM sshd ke listener process agar diproses secara sinkron
  • Perbaikan ini berada di atas commit besar 81c1099 dan commit defense-in-depth yang lebih besar 03e3de4, sehingga backport bisa sulit dilakukan
  • Jika backport sulit, kode yang tidak async-signal-safe di sshsigdie() dapat dihapus atau dikomentari agar hanya memanggil _exit(1)
  • Jika pembaruan atau kompilasi ulang tidak memungkinkan, LoginGraceTime dapat diatur menjadi 0 di file konfigurasi
    • Pengaturan ini mencegah eksekusi kode jarak jauh dalam advisory ini
    • Namun, sistem menjadi rentan terhadap DoS akibat habisnya semua koneksi MaxStartups

Jadwal Publikasi

  • 2024-05-19: Menghubungi developer OpenSSH, kemudian patch dan review berlangsung berulang
  • 2024-06-20: Menghubungi distros@openwall
  • 2024-07-01: Dipublikasikan sebagai coordinated release date

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-02
Opini Hacker News

  • Menariknya, perbaikan RCE tampaknya sudah “terselip” secara publik hampir sebulan lalu
    Saat PerSourcePenalties diaktifkan, sshd(8) memantau status terminasi proses sesi anak praautentikasi, lalu mencatat kondisi seperti kegagalan autentikasi berulang atau crash sshd sebagai penalti untuk alamat klien selama jangka waktu tertentu
    https://github.com/openssh/openssh-portable/commit/81c1099d2...
    Alih-alih patch yang bisa direkayasa balik dan memberi tahu penyerang sesuatu, ini tampaknya cukup cerdik karena mengubah struktur biner sehingga menghilangkan kerentanan tertentu dan, sebagai efek samping, juga memitigasi seluruh keluarga exploit tersebut

    • Itu bukan perbaikan RCE; perbaikan RCE yang sebenarnya ada di sini: https://news.ycombinator.com/item?id=40843865
      Perubahan di atas adalah fitur yang sebelumnya diumumkan untuk menangani koneksi sampah, dan hanya ikut memitigasi kerentanan ini dengan membuat kondisi balapan lebih sulit dimenangkan
      Diskusi sebelumnya: https://news.ycombinator.com/item?id=40610621
    • Saya penasaran apakah perbaikan ini sudah masuk atau diambil oleh distro-distro
    • Menarik bahwa komentar ini salah dan sudah dikoreksi tepat di bawahnya, tetapi tetap berada di posisi teratas selama 2 hari
      Saya bertanya-tanya apakah orang-orang hanya membaca komentar pertama di thread, memberi upvote, lalu pergi dengan kesan yang keliru

  • Ada bagian menarik di catatan rilis OpenSSH
    “Eksploitasi yang berhasil telah didemonstrasikan pada sistem Linux/glibc 32-bit dengan ASLR aktif. Dalam kondisi lab, serangan perlu mempertahankan koneksi berturut-turut hingga batas maksimum yang diizinkan server selama rata-rata 6–8 jam. Serangan ini diyakini mungkin juga pada sistem 64-bit, tetapi belum dibuktikan. Serangan semacam ini kemungkinan besar akan membaik.”
    https://www.openssh.com/releasenotes.html

  • Melihat diff [1] tempat bug masuk, menurut analisis masalahnya adalah sigdie() semula dibungkus dengan #ifdef DO_LOG_SAFE_IN_SIGHAND, lalu direfaktor menjadi sshsigdie() yang langsung memanggil sshlogv(), sehingga #ifdef tersebut hilang
    Apa yang bisa mencegahnya? Apakah pull request seharusnya ditinjau lebih banyak? Mengejutkan bahwa software yang menjadi tumpuan seluruh dunia untuk koneksi aman tampaknya secara efektif dipelihara oleh dua orang [2]
    [1] https://github.com/openssh/openssh-portable/commit/752250caa...
    [2] https://github.com/openssh/openssh-portable/graphs/contribut...

    • Secara retrospektif, mudah untuk mengatakan apa yang seharusnya dilakukan agar ini bisa dicegah
      Dalam kasus ini, mungkin akan membantu jika ada komentar yang menjelaskan mengapa #ifdef diperlukan. Misalnya, “kode di sini harus aman untuk sinyal asinkron, dan status lock bisa tidak pasti”
      Meski begitu, sejujurnya getrlimit juga tidak ada dalam daftar ini: https://man7.org/linux/man-pages/man7/signal-safety.7.html
      Namun, jika kode yang diberi komentar terkait keamanan sinyal asinkron dihapus atau diubah, kemungkinan itu akan terlihat saat review. Pada kode yang dikutip, hanya SAFE_IN_SIGHAND yang kurang lebih mengisyaratkan bahwa kode ini harus aman di dalam signal handler
    • Karena OpenBSD telah merefaktor sistemnya agar memakai fungsi syslog yang reentrant dan aman untuk sinyal asinkron, penulis kode ini mungkin saja sekadar berasumsi bahwa perubahan tersebut aman
      Mereka mungkin lupa atau tidak tahu bahwa pada platform lain, yang menurut para developer ssh OpenBSD sendiri sebenarnya tidak mereka klaim dukung, masih digunakan fungsi yang tidak aman untuk sinyal asinkron
    • Ini open source. Kalau merasa bisa membuatnya lebih baik, silakan fork kapan saja
      Tidak ada hak untuk menerima sesuatu dari developer open source. Mereka juga bisa melakukan kesalahan, dan mereka sendiri yang berhak menentukan berapa banyak maintainer atau reviewer yang mereka miliki
      https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
    • Pernyataan “software yang menjadi tumpuan seluruh dunia untuk koneksi aman dipelihara secara efektif oleh dua orang” wajib membuat saya teringat xkcd ini: https://xkcd.com/2347/
    • Ada beberapa cara untuk mencegahnya
      1. Menggunakan bahasa pemrograman yang benar-benar tidak memungkinkan fungsi sembarang dijadikan signal handler. Pada libc biasa ini jelas tidak aman, dan dalam bahasa yang aman seperti Rust atau Java, hal seperti itu tidak bisa dilakukan
      2. Menggunakan libc yang diimplementasikan dengan baik, sehingga pemanggilan fungsi yang tidak aman untuk sinyal asinkron hanya menyebabkan deadlock, bukan korupsi memori. Ini relatif mudah dilakukan jika kode yang berjalan di dalam sinyal diperlakukan seperti thread terpisah dari sudut pandang akses thread-local storage; deadlock pun bisa dihindari bila tidak ada mutex global atau bila kode yang terinterupsi saat memegang mutex dapat dilanjutkan
      3. Berpikir saat mengubah dan menyetujui kode. Jangan seperti orang-orang yang menghapus #ifdef tanpa dasar seperti di [1]
      4. Menggunakan software sederhana dan dirancang dengan baik yang ditulis oleh programmer bagus, alih-alih OpenSSH

  • Catatan rilisnya juga layak dibaca: https://www.openssh.com/releasenotes.html
    Ini sebenarnya varian dari bug race condition sinyal yang menarik. Menurut laporan kerentanannya, “OpenBSD secara khusus tidak rentan, karena handler SIGALRM memanggil syslog_r(), versi syslog() yang lebih aman terhadap sinyal asinkron yang dibuat OpenBSD pada 2001”
    Dengan kata lain, mitigasi keamanan sinyal membuat para pengembang OpenBSD memasukkan kode yang tidak sepele ke dalam handler sinyal, dan ketika kode itu di-porting ke sistem lain, ia menjadi tidak aman. Jika dilakukan refactoring untuk meminimalkan kode di dalam handler sinyal sesuai kebijaksanaan umum dan konvensi kode Unix, bug ini mungkin bisa dihindari

    • Theo de Raadt membuat pengamatan yang cukup masuk akal tentang pencegahan bug ini dan bug serupa: tidak ada handler sinyal yang boleh memanggil fungsi yang bukan system call yang aman terhadap sinyal
      Karena seiring waktu, sangat mudah ada pemanggilan yang tidak aman terhadap sinyal asinkron terselip di salah satu panggilan transitif, dan tidak selalu jelas bahwa jalur itu dapat dicapai dari konteks sinyal
    • Cukup mungkin ada banyak sysadmin muda atau intern yang harus menambal kerentanan ini yang bahkan belum lahir ketika OpenBSD mengimplementasikan solusi ini

  • Setelah meng-upgrade instance OpenSSH saya, saya melihat bahwa semuanya tertaut ke musl, bukan glibc, jadi saya mengecek apakah syslog(3) milik musl juga melakukan alokasi, sehingga mudah dieksploitasi dengan cara yang sama
    Tampaknya tidak: https://github.com/bminor/musl/blob/master/src/misc/syslog.c
    Semua yang ada di sana adalah variabel di stack atau variabel statis yang mencegah reentrancy dengan lock. Pemanggilan {d,sn,vsn}printf() juga tidak melakukan alokasi di musl, tetapi bisa saja di glibc. Apakah ada yang saya lewatkan?

    • Konfirmasi dari Rich: https://fosstodon.org/@musl/112711796005712271
    • Jika penilaian tentang alokasi itu benar, kasus terburuknya sepertinya hanya deadlock karena lock-nya tidak rekursif
      Meski begitu, deadlock di dalam sigalrm bisa mencegah pembersihan koneksi, sehingga dapat berujung pada denial of service

  • Patch untuk FreeBSD sudah keluar
    Belum jelas apakah terdampak. Eksploit yang diketahui hanya mungkin di glibc dan FreeBSD tidak memakai glibc, tetapi lebih baik bermain aman
    https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04...

  • Menurut laporan, jika tidak bisa memperbarui atau mengompilasi ulang sshd, cukup mengatur LoginGraceTime menjadi 0 di file konfigurasi dapat memperbaiki race condition handler sinyal ini
    Dalam kasus ini, sshd menjadi rentan terhadap denial of service ketika semua koneksi MaxStartups habis, tetapi aman dari eksekusi kode jarak jauh yang dijelaskan dalam advisori ini
    Jadi tampaknya menetapkan LoginGraceTime 0 di sshd_config bisa menjadi mitigasi

    • Tunggu, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html mengatakan bahwa nilai 0 berarti tidak ada batas waktu
      Bukankah itu malah lebih buruk?
    • Workaround yang lebih realistis mungkin adalah memperpanjang grace time secukupnya, atau sebaliknya menyesuaikan jumlah koneksi maksimum agar probabilitas serangan yang berhasil menjadi begitu jauh di masa depan sehingga tidak layak dicoba
    • Apakah cold restart sshd setiap jam juga bisa menurunkan kemungkinan eksploitasi atau membuatnya lebih sulit?

  • Patch untuk Debian 12 sudah keluar, dan Debian 11 tidak terdampak
    https://security-tracker.debian.org/tracker/CVE-2024-6387

    • Focal(20.04) sepertinya bukan versi yang terdampak, sedangkan Jammy(22.04) tampaknya terdampak
    • Saya baru saja menjalankan apt update dan upgrade di server Debian 12, dan satu-satunya yang di-upgrade adalah paket OpenSSH
    • Saya mengonfirmasi bahwa openssh yang diperbarui juga sudah masuk ke Pi OS bullseye

  • Temuan yang benar-benar bagus
    Meski bukan berada di posisi yang langsung mengerjakannya, dalam riset keamanan sering terasa ada suasana bahwa untuk “menang”, yang harus ditemukan bukan sekadar satu masalah untuk diperbaiki atau diberi imbalan, melainkan seluruh rantai yang berujung pada akses jarak jauh
    Rasanya, bukankah menemukan satu celah saja—misalnya satu kerusakan memori atau satu pelolosan sandbox—seharusnya sudah cukup. Saat ini ada begitu banyak masalah kecil, sampai mungkin untuk membuat orang benar-benar menanggapinya serius atau membayar bug bounty, kita harus menunjukkan peretasan yang tersambung sampai akhir

    • Ada banyak calon peneliti keamanan yang menemukan masalah yang tidak bisa dieksploitasi lalu meminta nomor CVE, pengakuan, bahkan imbalan
      Misalnya, jika sebuah aplikasi crash ketika menerima input tepercaya yang keliru, tetapi berdasarkan sifat aplikasi itu memang tidak dimaksudkan untuk terekspos kepada pihak adversarial dan secara realistis hal itu tidak akan terjadi, kebanyakan orang akan menganggapnya sekadar bug, bukan bug keamanan. Bagus kalau diperbaiki, tetapi levelnya tidak sama, dan hal seperti ini juga tidak terlalu sulit ditemukan
      Karena itu perlu dibedakan antara bug keamanan “nyata” seperti kasus ini dan bug yang tidak memiliki dampak keamanan, dan pekerjaan membuktikan bahwa masalah dapat dieksploitasi menjadi sangat penting
      Bug tanpa dampak keamanan akan ada tanpa habisnya, jadi rasanya tuntutan pembuktian seperti ini tidak akan segera hilang
    • Dari sudut pandang lain, anggap saja saya membuat library serialisasi/deserialisasi yang menjadi rentan jika saya memasukkan data yang tidak tepercaya
      Itu memang demikian secara desain, dan pengguna bisa menserialisasi serta mendeserialisasi apa pun, termasuk fungsi lambda. Library saya hanya dimaksudkan untuk memproses data dari sumber tepercaya
      Sejauh yang saya tahu, tidak ada yang memakai library ini untuk memproses data yang tidak tepercaya. Satu library populer memakai library saya untuk membaca file konfigurasi, tetapi mereka menganggap file konfigurasi sebagai data tepercaya. Dan bukan tugas saya untuk mengawasi bagaimana orang lain memakai library saya
      Dalam kasus seperti ini, apakah benar mendaftarkan CVE prioritas tertinggi dengan alasan ada kerentanan eksekusi kode jarak jauh di proyek saya?
    • Saya pernah berada di pihak yang melaporkan, dan “kerentanan yang dapat dieksploitasi” sangat berbeda dari “kelemahan keamanan yang suatu hari bisa berujung pada kerentanan yang dapat dieksploitasi”
      Imbalan selalu dibayarkan untuk kategori pertama. Laporan kategori kedua, tanpa bukti konsep atau pembuktian kemungkinan eksploitasi, malah bisa merusak reputasi atau sinyal
      Kelemahan yang tidak menjadi dapat dieksploitasi sampai kondisi tertentu terpenuhi hampir selalu ada. Bahkan di kompetisi seperti Pwn2Own, sering terlihat beberapa kerentanan dirangkai hingga akhirnya mengambil alih perangkat, dan banyak yang tetap tidak dipatch selama bertahun-tahun. Para peneliti kadang menyimpan kelemahan seperti itu lama-lama untuk memaksimalkan dampaknya
      Menyedihkan, tetapi begitulah kenyataannya
    • Sesuai pepatah keamanan: POC || GTFO
    • Pembeli membayar untuk hasil. Vendor memang juga membayar untuk mata rantai individual dalam chain tersebut

  • Catatan rilis OpenSSH: https://www.openssh.com/txt/release-9.8
    Patch minimal untuk orang-orang yang tidak bisa atau tidak ingin upgrade: https://marc.info/?l=oss-security&m=171982317624594&w=2

    • “Eksploitasi pada sistem 64-bit juga dianggap mungkin, tetapi saat ini belum terbukti”