OpenSSH mengeluarkan 10.6p2 pada 5 November untuk membaiki satu pintasan pengesahan kata laluan, CVE-2026-123158 (penemunya menamakannya sshole; CVSS 8.1). Pada 9 November, Agensi Keselamatan Siber dan Keselamatan Infrastruktur AS (CISA) memasukkannya ke dalam katalog Known Exploited Vulnerabilities (KEV), iaitu senarai kerentanan yang diketahui telah dieksploitasi, dengan memetik bukti eksploitasi aktif. Ia hanya menjejaskan sistem Linux yang menggunakan pustaka C musl tanpa PAM, dan Alpine ialah contoh lazimnya. Halaman keselamatan Ubuntu menandakan openssh sebagai "Not affected" (tidak terjejas) pada setiap keluaran dan Debian menilai tahap kesegeraannya sebagai unimportant (tidak penting), jadi VPS yang menjalankan Ubuntu atau Debian tidak perlu berbuat apa-apa untuk pepijat ini. Yang perlu disemak ialah sistem Alpine, dan mana-mana sshd yang anda pasang sendiri di dalam kontena Alpine. Untuk pusingan perubahan OpenSSH sebelum ini, lihat laporan Oktober kami.

Keempat-empat Syarat Mesti Dipenuhi

  • Anda menjalankan pakej openssh-server Alpine, yang dibina tanpa PAM, atau anda menjalankan openssh-server-pam dengan UsePAM no.
  • PasswordAuthentication bernilai yes. Itu nilai lalai OpenSSH, jadi ia aktif melainkan anda telah mengubahnya.
  • Mesin itu mempunyai akaun yang medan kata laluannya ialah *, iaitu akaun tanpa kata laluan yang dimaksudkan untuk log masuk dengan kunci sahaja. Imej asas Alpine telah menetapkan root sebagai root:* sejak kira-kira 3.16, dan pengguna alpine dalam imej rasmi tiny-cloud juga begitu serta mempunyai doas tanpa kata laluan untuk menjadi root. Root sendiri dilindungi oleh tetapan lalai PermitRootLogin prohibit-password, tetapi itu tidak memadai jika ada akaun lain yang boleh menjadi root.
  • Sekurang-kurangnya satu akaun lain pada mesin itu mempunyai cincangan kata laluan sebenar yang bermula dengan $5$ atau $6$. Apabila keempat-empat syarat ini dipenuhi, penyerang yang mengetahui satu nama akaun menghantar kata laluan yang sangat panjang, 257 hingga 1024 bait (NVD menyebutnya sebagai 256 hingga 1024 aksara), dan terus berjaya log masuk pada sambungan pertama. Puncanya ialah crypt() dalam musl memulangkan * sebagai penanda ralat apabila kata laluan melebihi 256 bait, dan * itulah yang tersimpan pada akaun-akaun tersebut, jadi sshd menganggapnya sepadan.

Apa yang Tidak Terjejas

  • Kontena yang tidak menjalankan sshd, dan ini merangkumi sebahagian besar kontena Docker.
  • Sistem yang sudah menetapkan PasswordAuthentication no; imej awan yang dikonfigurasikan melalui cloud-init menulis baris itu. Sistem yang menggunakan openssh-server-pam dengan UsePAM yes juga tidak terjejas.
  • Penemunya turut menamakan OpenWrt, Buildroot dan Yocto sebagai sistem berasaskan musl. Sistem ini hanya perlu diberi perhatian jika sshd OpenSSH dipasang, dan pembaikannya datang daripada kemas kini projek masing-masing.

Cara Membaikinya

  • Naik taraf, kemudian mulakan semula sshd: jalankan apk upgrade -U -a, kemudian rc-service sshd restart. Menaik taraf pakej tidak memulakan semula sshd yang sedang berjalan. Alpine 3.21.10, 3.22.8, 3.23.8 dan 3.24.4 mengandungi pakej yang telah dibaiki; versi pakejnya ialah 10.3_p1-r2 pada 3.24, 10.2_p1-r1 pada 3.23, 10.0_p1-r11 pada 3.22, 9.9_p2-r1 pada 3.21 dan 10.6_p2-r0 pada edge, dan pembaikan turut diterbitkan untuk cabang lama sehingga 3.16.
  • Jika anda belum boleh menaik taraf, matikan log masuk dengan kata laluan: tetapkan PasswordAuthentication no dalam konfigurasi sshd, mulakan semula sshd, dan sahkan dengan sshd -T | grep -i passwordauthentication bahawa ia memaparkan no. Pastikan log masuk dengan kunci anda berfungsi terlebih dahulu, dan biarkan sesi semasa anda terbuka.
  • Jika anda menulis Dockerfile yang memasang openssh-server ke dalam imej Alpine, tarik imej asas yang baharu, bina semula dan mulakan semula kontena itu. Menaik taraf hos tidak memberi apa-apa kesan kepadanya.

Cara Mengetahui Sama Ada Seseorang Telah Log Masuk

Alpine menyarankan anda mencari dalam /var/log/messages baris sshd yang berbunyi Accepted password for: log masuk kata laluan yang berjaya bagi akaun yang tidak mempunyai kata laluan (alpine, root, atau pengguna yang hanya menggunakan kunci) bermakna pepijat itu telah digunakan. Kemudian semak penggunaan doas, pengguna yang baru dicipta dan authorized_keys, dan jika anda tidak dapat menolak kemungkinan berlakunya log masuk, anggap mesin itu telah diceroboh dan ikuti panduan siasatan pencerobohan dan pengukuhan kami. BleepingComputer melaporkan pada 9 November bahawa GreyNoise merekodkan eksploitasi pertama yang berjaya pada 00:46 UTC, 7 November, kira-kira 40 jam selepas pembaikan dikeluarkan; selepas berjaya masuk, penyerang menjalankan peninjauan sistem dan kontena, membuat pertanyaan kepada perkhidmatan metadata awan, cuba membaca cincangan kata laluan dan kunci SSH root, serta menyunting authorized_keys untuk mengekalkan akses. Untuk asas kontena, lihat pengenalan Docker kami; pada mana-mana pengedaran, log masuk SSH dengan kunci sahaja ialah tetapan yang paling banyak mengelakkan masalah, seperti yang diterangkan dalam tembok api ufw dan log masuk kunci SSH.