OpenBSD diposisikan sebagai OS yang aman. Namun, selama beberapa bulan terakhir, sejumlah kerentanan telah ditemukan dalam sistem. Tentu saja, tidak ada yang luar biasa dalam hal ini. Meskipun beberapa kerentanan sangat tidak biasa. Anda bahkan bisa mengatakan kritis. Pengembang OpenBSD memiliki beberapa panduan tentang cara memastikan keamanan. Inilah dua di antaranya:

menghindari kesalahan;
meminimalkan risiko kesalahan.

Tidak semua orang setuju bahwa prinsip-prinsip ini cukup untuk membangun sistem yang aman. Menurut saya masuk akal untuk mempelajari apakah pendekatan OpenBSD bekerja, atau jika pendekatan itu pada awalnya ditakdirkan.

Sebagai ilustrasi, saya tidak memilih semua, tetapi hanya beberapa bug menarik yang secara tidak sengaja bertepatan dengan topik pembicaraan kami.

libc auth

Fungsi auth menjalankan pembantu tanpa memeriksa argv. Laporkan . Patch .

Ini adalah kesalahan yang sangat sederhana, tetapi mungkin tidak tampak terlalu jelas selama tinjauan kode. Sepertinya saya, sebagian, alasan dalam beberapa kebingungan adalah siapa yang bertanggung jawab untuk memeriksa data input. Anda dapat memanggil masing-masing dari tiga komponen yang terlibat: program, perpustakaan, atau login_passwd - dan masuk akal untuk menganggap bahwa orang lain sedang memeriksa. Pada akhirnya, saya pikir perpustakaan itu terbukti bersalah, karena bagi dia sebuah tambalan muncul, tetapi secara pribadi bagi saya pada pandangan pertama kodenya tampaknya tidak jelas salah.

Bagian yang lebih menarik dari cerita ini adalah bahwa bahkan dengan kesalahan libc yang disebutkan, fungsi login_passwdSaya tidak akan rentan jika tidak ada bug lain. Pada tahun 2001, login_passwd ditulis ulang untuk mendukung kerberos, dan mungkin saat itulah mereka memperkenalkan apa penyebab sebenarnya dari kesalahan tersebut. Penawaran otentikasi jenis permintaan-respons (seperti pada s / key system) mengembalikan status terotentikasi, bukan diam. Bertahun-tahun kemudian, kode kerberos telah dihapus, tetapi bagian dari kode untuk mendukungnya tetap ada, serta kesalahan yang diperkenalkan.

Jika kode kerberos dibersihkan secara menyeluruh, bug otentikasi masih akan tetap ada (ada beberapa masalah terkait lainnya dengan penguraian argv), tetapi efeknya tentu akan sangat berkurang.

Tidak mudah untuk mem-parsing argv dengan benar dalam konteks keamanan. Banyak tip dan pendekatan logis tidak berfungsi di sini. Saya hanya akan mencatat bahwa kerentanan ini muncul setelahdiskusi lain tentang masalah dengan nama file di Unix / Linux / POSIX , meskipun minus utama (tanda hubung) tidak benar-benar merujuk pada nama file.

jadi

Variabel lingkungan buruk belum dihapus dari kode ld.so. Laporkan . Patch .

Sesuatu seperti kesalahan memori. Tapi tidak. Bug di sini adalah untuk menghubungkan keberhasilan satu operasi - memisahkan variabel lingkungan - untuk menghapus variabel itu. Sangat percaya diri.

Tentu saja, para pendukung berbagai sistem pengetikan akan memastikan bahwa mereka akan memproses operasi ini dalam urutan yang benar, tetapi bukan fakta bahwa ini akan membantu. Kode C tidak macet karena kurangnya penanganan kesalahan atau karena kesalahan alokasi memori tetap tidak terlihat.

ftp

ftp mengikuti pengalihan ke file lokal. Laporkan . Patch .

Bug redirect ftp NetBSD telah lama menjadi contoh khas fungsi yang tidak terkontrol . Dan di sini lagi kesalahan yang sama (untungnya, dengan konsekuensi kecil)! Kawan, duduklah di rumah. Jangan menambahkan fitur tambahan ke program Anda.

smtpd dari

smtpd tidak dapat memeriksa beberapa alamat pengirim. Laporkan . Patch . Komentar .

Saya pikir semuanya dikatakan dalam komentar Gilles, tetapi saya akan mengingatkan latar belakangnya. Sekali waktu, semua email disimpan secara lokal untuk setiap pengguna di / var / maildalam file mbox. Ini tidak terlalu keren, karena ada kemungkinan kerusakan jika mua menghapus email sementara mda memberikan yang baru (belum lagi masalah lain seperti mendistorsi bidang Dari). Oleh karena itu, file mbox perlu dikunci. Tetapi mengunci pada sistem file jaringan tidak bekerja dengan andal. Jadi alih-alih mengunci kita menggunakan file kunci. Namun, Anda harus mencapai kesepakatan tentang protokol pemblokiran tertentu, karena pengguna memiliki file mbox, dan root itu sendiri memiliki direktori. Jadi, untuk benar-benar memodifikasi file mbox, Anda harus menjalankan fungsi pembantu setuid setiap kali. Nah, ini masalah pertama. Peninggalan lain dari masa lalu adalah pengaturan mda, yang dapat digunakan tidak hanya sebagai program, tetapi sebagai pipa shell. Orang meresepkan sesuatu sepertispam-assassin | mail.mdadan Anda tidak bisa meneruskannya execve().

Ada banyak kesulitan yang berakar di masa lalu. Dan, sayangnya, kode bermasalah ini tidak bisa diganti begitu saja. E-mail sudah lama digunakan, dan sistem dan alur kerja yang sangat kompleks dibangun atas dasar itu, sehingga sangat sulit untuk hanya memotong satu potong kode dan menempel yang baru. Terlepas dari berbagai tingkat pemisahan hak istimewa, proses induk tingkat root masih sangat bergantung pada proses anak yang kurang istimewa. Dia akan menjalankan perintah dan argumen yang akan dia terima.

Menghindari ini tampaknya sesederhana beralih ke format penyimpanan maildir, tetapi membutuhkan berbagai perubahan di banyak tempat. Surat mua standartidak mengerti format ini. Bagi saya, mbox telah lama hidup, tetapi masih cocok untuk banyak orang, dan prosedur pembaruan mungkin tidak sepenuhnya transparan dan tidak akan bekerja secara otomatis.

smtpd baca

Membaca di luar ruang lingkup di smtpd dapat digunakan untuk menjalankan perintah. Laporkan . Patch .

Ini benar-benar masalah keamanan memori. Dengan mengirimkan beberapa bilah status lucu, server smtp jarak jauh dapat menyuntikkan perintah ke antrian smtpd untuk dieksekusi. Ketika sebuah email di-antri untuk pengiriman ulang, smtpd menambahkan beberapa informasi tujuan ke header untuk mengetahui perintah mana yang harus dieksekusi (lihat di atas). Serangan ini mirip dengan "penyelundupan" permintaan http . Jika Anda dapat menghasilkan "omong kosong" dengan perintah yang tidak terduga di header, smtpd akan menjalankannya ketika Anda mencoba mengirim ulang.

Seperti di atas, salah satu masalahnya adalah bagian smtpd yang paling sensitif terlalu dekat dengan permukaan serangan. Tampaknya bagi saya bahwa masalah sebenarnya adalah bahwa smtpd menyimpan metadata sendiri di dalam data email. Karena itu, penguraian serangan sinkronisasi menjadi mungkin. Jika respons yang dikutip dari server disimpan sepenuhnya terpisah dari file dengan instruksi pengiriman, maka membaca di luar perbatasan tidak akan banyak merugikan.

Kerentanan ini tampaknya menjadi indikasi bagi saya, karena di sini kita melihat bahaya pencampuran data dengan berbagai tingkat kepercayaan. Bahaya ini belum pernah dibahas. Dan dia memang benar.

temuan

Tentu saja, kesimpulannya sudah jelas dari awal, tetapi kami akan tetap membicarakannya.

Saya pikir beberapa kesalahan ini membantu menunjukkan bagaimana prinsip-prinsip seperti menghapus antarmuka yang usang dan mengurangi kompleksitas kode sangat penting untuk keamanan . Sebagian besar, kegagalan terjadi karena fakta bahwa prinsip-prinsip ini tidak ditindaklanjuti sampai akhir, dan bukan karena prinsip-prinsip itu sendiri rusak atau tidak dapat dipertahankan. Beberapa hal tidak terlihat, tetapi saya tidak setuju bahwa pengembang memerlukan semacam kewaspadaan manusia super. Sangat mudah untuk memberikan saran yang tidak berguna, seperti hati-hati, jangan membuat kesalahan dan git gud [ungkapan slang gamer berarti 'menjadi baik', yaitu, "menjadi lebih baik, cepat sembuh" - kira-kira. trans.]. Tetapi saya pikir OpenBSD memiliki masalah yang lebih serius.

Bahkan OpenBSD dapat mengambil risiko keamanan untuk kepraktisan utilitarian. Itu sebabnya beberapa proyek yang sudah ketinggalan zaman tidak diubah untuk waktu yang lama. Jadi, mungkin pelajarannya adalah bahwa prinsip-prinsip yang efektif harus selalu diikuti, dan tidak hanya jika nyaman. Meskipun seringkali sulit untuk membuat pilihan yang tepat.

Tiga kerentanan paling serius, auth dan dua smtpd, lebih atau kurang cocok untuk eksploitasi hanya karena masalah arsitektur yang melampaui cakupan bug asli. Mereka seharusnya tetap hanya cacat kecil yang menunjukkan bahwa dalam sistem yang dilindungi dengan baik tidak perlu berusaha untuk kode yang sempurna, yaitu, kesalahan kecil diperbolehkan - dan mereka tidak mempengaruhi keamanan. Sayangnya, sulit untuk mengidentifikasi cacat desain dalam bentuk abstrak. Dan semua bagian sistem secara individual terlihat terlindungi, tetapi jika digabungkan, kelemahan mungkin muncul.

Pemisahan hak istimewa adalah komponen kunci dari keamanan OpenBSD, dan didasarkan pada komunikasi antarproses. Masuk akal untuk melihat lebih dekat masalah apa yang mungkin timbul dengan proses yang rusak. Browser yang dilindungi semakin memperkuat perlindungan dan menghambat serangan. Secara khusus, smtpd harus dilindungi terhadap kerusakan memori dalam tugas-tugas jaringan. Tetapi kemudahan yang dia dapat mengendalikan proses orangtua sangat mengkhawatirkan.

Hanya satu kesalahan yang bisa dicegah menggunakan bahasa yang lebih aman. Ya, mungkin, ada semacam idiom program, yang dalam beberapa kasus dapat membantu jika Anda mengikutinya dengan ketekunan agama. Tapi saya belum yakin bahwa secara default setiap programmer akan mengkodekan semua invarian yang sesuai dengan benar.

Menulis server surat adalah bisnis yang sulit. Terutama jika bingkai lama memperketat Anda.

Sudah waktunya untuk memikirkan kembali keamanan OpenBSD

libc auth

jadi

ftp

smtpd dari

smtpd baca

temuan

More articles: