Keluaran OpenSSH 8.3 dengan pembetulan kerentanan scp

Selepas tiga bulan pembangunan dibentangkan melepaskan OpenSSH 8.3, pelaksanaan klien dan pelayan terbuka untuk bekerja melalui protokol SSH 2.0 dan SFTP.

Keluaran baharu menambah perlindungan terhadap serangan scp yang membenarkan pelayan menghantar nama fail lain daripada yang diminta (berbanding dengan kelemahan masa lalu, serangan itu tidak memungkinkan untuk menukar direktori atau topeng glob yang dipilih pengguna). Ingat bahawa dalam SCP, pelayan memutuskan fail dan direktori mana yang hendak dihantar kepada klien, dan klien hanya menyemak ketepatan nama objek yang dikembalikan. Intipati masalah yang dikenal pasti ialah jika panggilan sistem utimes gagal, maka kandungan fail ditafsirkan sebagai metadata fail.

Ciri ini, apabila menyambung ke pelayan yang dikawal oleh penyerang, boleh digunakan untuk menyimpan nama fail lain dan kandungan lain dalam FS pengguna apabila menyalin menggunakan scp dalam konfigurasi yang membawa kepada kegagalan apabila memanggil utimes (contohnya, apabila utimes dilarang oleh dasar SELinux atau penapis panggilan sistem) . Kemungkinan serangan sebenar dianggarkan minimum, kerana dalam konfigurasi biasa panggilan utimes tidak gagal. Di samping itu, serangan itu tidak disedari - apabila memanggil scp, ralat pemindahan data ditunjukkan.

Perubahan umum:

  • Dalam sftp, pemprosesan argumen "-1" telah dihentikan, serupa dengan ssh dan scp, yang sebelum ini diterima tetapi diabaikan;
  • Dalam sshd, apabila menggunakan IgnoreRhosts, kini terdapat tiga pilihan: "ya" - abaikan rhosts/shosts, "tidak" - hormati rhosts/shosts dan "shosts-only" - benarkan ".shosts" tetapi lumpuhkan ".rhosts";
  • Ssh kini menyokong penggantian %TOKEN dalam tetapan LocalFoward dan RemoteForward yang digunakan untuk mengubah hala soket Unix;
  • Benarkan memuatkan kunci awam daripada fail tidak disulitkan dengan kunci peribadi jika tiada fail berasingan dengan kunci awam;
  • Jika libcrypto tersedia dalam sistem, ssh dan sshd kini menggunakan pelaksanaan algoritma chacha20 daripada perpustakaan ini, bukannya pelaksanaan mudah alih terbina dalam, yang ketinggalan dalam prestasi;
  • Melaksanakan keupayaan untuk membuang kandungan senarai binari sijil yang dibatalkan apabila melaksanakan arahan "ssh-keygen -lQf /path";
  • Versi mudah alih melaksanakan definisi sistem di mana isyarat dengan pilihan SA_RESTART mengganggu operasi pilih;
  • Masalah binaan pada sistem HP/UX dan AIX telah diselesaikan;
  • Memperbaiki masalah dengan membina kotak pasir seccom pada beberapa konfigurasi Linux;
  • Pengesanan perpustakaan libfido2 dipertingkatkan dan menyelesaikan isu binaan dengan pilihan "--dengan-kunci-terbina-keselamatan".

Pembangun OpenSSH juga sekali lagi memberi amaran tentang penguraian algoritma yang akan datang menggunakan cincang SHA-1 disebabkan oleh kenaikan pangkat keberkesanan serangan perlanggaran dengan awalan yang diberikan (kos memilih perlanggaran dianggarkan kira-kira 45 ribu dolar). Dalam salah satu keluaran yang akan datang, mereka merancang untuk melumpuhkan secara lalai keupayaan untuk menggunakan algoritma tandatangan digital kunci awam "ssh-rsa", yang disebut dalam RFC asal untuk protokol SSH dan kekal meluas dalam amalan (untuk menguji penggunaan daripada ssh-rsa dalam sistem anda, anda boleh cuba menyambung melalui ssh dengan pilihan "-oHostKeyAlgorithm=-ssh-rsa").

Untuk melancarkan peralihan kepada algoritma baharu dalam OpenSSH, pada keluaran akan datang tetapan UpdateHostKeys akan didayakan secara lalai, yang secara automatik akan memindahkan pelanggan kepada algoritma yang lebih dipercayai. Algoritma yang disyorkan untuk penghijrahan termasuk rsa-sha2-256/512 berdasarkan RFC8332 RSA SHA-2 (disokong sejak OpenSSH 7.2 dan digunakan secara lalai), ssh-ed25519 (disokong sejak OpenSSH 6.5) dan berasaskan ecdsa-sha2-nistp256/384/521 pada RFC5656 ECDSA (disokong sejak OpenSSH 5.7).

Mulai keluaran terakhir, "ssh-rsa" dan "diffie-hellman-group14-sha1" telah dialih keluar daripada senarai CASignatureAlgorithm yang mentakrifkan algoritma yang dibenarkan untuk menandatangani sijil baharu secara digital, kerana menggunakan SHA-1 dalam sijil menimbulkan risiko tambahan disebabkan itu penyerang mempunyai masa tanpa had untuk mencari perlanggaran bagi sijil sedia ada, manakala masa serangan pada kunci hos dihadkan oleh tamat masa sambungan (LoginGraceTime).

Sumber: opennet.ru

Tambah komen