Baru-baru ini saya memberi kuliah tentang topik ini di GoTo Chicago dan berpikir akan menyenangkan untuk menulis artikel dengan kesimpulan. Posting ini adalah tentang mengapa firmware open source penting untuk keamanan.
Tingkat hak istimewa
Dalam tumpukan biasa, Anda memiliki tingkat hak istimewa yang berbeda.
- Dering 3. Aplikasi: hak minimum, dengan pengecualian kotak pasir di ruang pengguna, yang bahkan lebih terbatas.
- Dering 0. Kernel: kernel sistem operasi, dalam kasus OS open source, Anda melihat kodenya.
- Dering −1. Hypervisor: Virtual Machine Monitoring (VMM), membuat dan menjalankan mesin virtual. Di hypervisor sumber terbuka seperti Xen, KVM, bhyve dan lainnya, Anda melihat kode.
- Dering −2. Mode Manajemen Sistem (SMM), inti UEFI: kode hak milik, lebih lanjut tentang ini di bawah.
- Dering −3. Kontrol mesin: kode hak milik, lebih lanjut tentang ini di bawah.
Cincin negatif menunjukkan level dengan hak istimewa lebih besar dari nol.
Dari uraian di atas, jelas bahwa dalam lingkaran dari −1 hingga 3, kita memiliki kesempatan untuk menggunakan perangkat lunak sumber terbuka, untuk sebagian besar melihat dan mengendalikannya. Untuk level di bawah −1 ring, kami memiliki kontrol yang lebih sedikit, tetapi situasinya membaik berkat pengembangan firmware open source dan komunitas.
Ini adalah situasi yang kontradiktif: kode yang paling tertutup memiliki hak istimewa paling dalam sistem kami. Paradoks ini harus memperbaiki firmware open source.Dering −2. SMM, inti UEFI
Cincin ini mengontrol semua sumber daya CPU.
Mode Manajemen Sistem (SMM) tidak terlihat oleh tumpukan lainnya di atasnya. Ia memiliki setengah inti. Awalnya digunakan untuk manajemen daya dan kontrol perangkat keras sistem. Ini berisi banyak kode hak milik dan merupakan tempat di mana pemasok menambahkan fitur hak milik baru. Ini menangani peristiwa sistem, seperti kesalahan memori atau chipset, serta banyak logika lainnya.
Inti UEFI sangat kompleks, dengan jutaan baris kode. Aplikasi UEFI aktif setelah diunduh. Inti dikembangkan pada prinsip "keamanan melalui ketidakjelasan."
Spesifikasi ini benar
- benar gila jika Anda ingin mencari-cari.
Dering −3. Mesin kontrol
Cincin paling istimewa. Dalam kasus Intel (x86), ini adalah Intel Management Engine. Sistem ini dapat dengan diam-diam menghidupkan node dan menimpa disk, kernel memulai
Minix 3 , serta server web dan seluruh tumpukan jaringan. Ternyata berkat ini, Minix adalah sistem operasi desktop paling populer. Mesin kontrol memiliki banyak fungsi. Mungkin perlu waktu sehari penuh untuk mendaftarkan mereka. Jika Anda mau, ada
banyak sumber daya untuk studi yang lebih rinci.
Antara ring −2 dan ring −3 di stack kami ada setidaknya dua setengah kernel lainnya, serta sekelompok kompleksitas kepemilikan dan tidak perlu. Masing-masing core ini memiliki tumpukan jaringan dan server web sendiri. Kode dapat berubah dengan sendirinya, bertahan setelah mematikan daya dan menginstal ulang.
Kami hanya memiliki sedikit informasi tentang apa yang sebenarnya dilakukan kode dalam cincin ini, yang mengerikan, mengingat cincin ini memiliki hak istimewa paling banyak.Mereka semua punya eksploitasi
Seharusnya tidak mengejutkan siapa pun bahwa ada kerentanan di cincin −2 dan −3. Ketika mereka ditemukan, itu benar-benar mengerikan. Sama seperti contoh, meskipun Anda dapat mencari contoh lain sendiri, ada
bug di server web Intel Management Engine yang belum diketahui pengembang selama tujuh tahun .
Bagaimana situasinya dapat diperbaiki?
NERF: Firmware Berkurang Non-Dapat Diperpanjang
NERF adalah apa yang sedang dikerjakan masyarakat. Tujuannya adalah untuk membuat firmware kurang mampu melakukan kerusakan dan membuat tindakannya lebih terlihat. Mereka berusaha untuk menghapus semua komponen runtime, tetapi ini masih sulit dilakukan di Intel Management Engine. Tetapi Anda dapat menghapus server web dan tumpukan IP dari sana. Pengembang juga ingin menghapus tumpukan IP UEFI, driver lain, dan menghapus fitur firmware mandiri Intel Management / UEFI.
me_cleaner
Proyek untuk membersihkan Intel Management Engine hingga fungsionalitas minimum yang disyaratkan (
pada GitHub ).
u-boot dan coreboot
u-boot dan
coreboot adalah firmware sumber terbuka. Mereka menangani inisialisasi chip dan DRAM. Chromebook menggunakan keduanya, coreboot pada x86, dan sisanya u-boot. Ini adalah salah satu langkah yang mereka
periksa untuk memuat .
Filosofi desain Coreboot adalah untuk
"membuat minimum yang diperlukan untuk menggunakan perangkat keras, dan kemudian mentransfer kontrol ke program lain yang disebut payload .
" Dalam hal ini, itu adalah linuxboot.
linuxboot
Linuxboot menangani driver perangkat, tumpukan jaringan, dan menyediakan lingkungan multi-pengguna multi-tasking. Itu dibangun di Linux, sehingga satu inti dapat berjalan di beberapa papan. Linux sudah cukup teruji dan banyak orang mengikuti kodenya, karena cukup banyak digunakan. Lebih baik menggunakan inti terbuka dengan sejumlah besar "pengontrol" daripada dua setengah kernel lainnya, berbeda dan tertutup. Ini berarti kami mengurangi permukaan serangan karena varian kode yang lebih sedikit dan bergantung pada kode sumber terbuka. Linux meningkatkan keandalan boot dengan mengganti driver firmware yang tidak teruji dengan driver Linux yang ditingkatkan.
Dengan menggunakan kernel, kami sudah memiliki perangkat firmware: pengembang dapat menggunakan alat yang sudah dikenal ketika mereka perlu menulis logika untuk memverifikasi tanda tangan, mengenkripsi disk, dan sebagainya. Semua ini dalam bahasa modern, teruji, didukung, dan mudah dibaca.
me-root
u-root adalah toolkit dan bootloader golang userspace. Ini digunakan sebagai initramfs untuk kernel Linux di linuxboot.
Mereka mengatakan tumpukan NERF telah mengurangi waktu boot sebanyak 20 kali. Tapi ini adalah artikel keamanan, jadi mari kita kembali ke keamanan ...
Tumpukan NERF meningkatkan visibilitas banyak komponen yang sebelumnya sepenuhnya milik. Namun, perangkat masih memiliki banyak firmware lain.
Bagaimana dengan firmware lain?
Kami membutuhkan firmware terbuka untuk Pengendali Antarmuka Jaringan (NIC), Solid State Drive (SSD) dan Pengendali Manajemen Dasar (BMC).
Proyek Open Compute sedang melakukan beberapa pekerjaan pada firmware
NIC 3.0 . Menarik melihat apa yang mereka lakukan.
Ada
OpenBMC dan
u-bmc untuk BMC . Saya menulis sedikit tentang mereka di
artikel sebelumnya .
Kita perlu memiliki semua firmware open source untuk memastikan visibilitas penuh pada stack dan benar-benar memeriksa status perangkat lunak pada mesin.
Akar kepercayaan
Tujuan dari akar kepercayaan adalah untuk memverifikasi bahwa perangkat lunak yang sesuai diinstal pada setiap komponen peralatan. Anda dapat memastikan bahwa peralatan tersebut tidak diretas. Karena kita sekarang memiliki banyak kode sumber tertutup di banyak bidang peralatan, ini sulit dilakukan. Bagaimana benar-benar tahu bahwa tidak ada kerentanan atau backdoors di firmware komponen? Tidak mungkin. Open source adalah hal lain.
Tampaknya setiap cloud dan masing-masing vendor menawarkan akar kepercayaannya sendiri. Microsoft punya
Cerberus , Google punya
Titan , Amazon punya
Nitro . Mereka tampaknya menyiratkan kepercayaan eksplisit pada kode eksklusif (kode yang tidak kita lihat). Ini meninggalkan perasaan aneh.
Bukankah lebih baik menggunakan open source sepenuhnya? Kemudian kita dapat memverifikasi tanpa ragu bahwa kode yang dikompilasi dari kode sumber adalah sama dengan yang bekerja pada peralatan di mana pun firmware dipasang. Kemudian kita dapat memeriksa bahwa mesin dalam kondisi yang benar, tanpa ragu bahwa itu rentan atau dengan pintu belakang.Ini membuat Anda bertanya-tanya apa yang digunakan penyedia cloud kecil seperti DigitalOcean atau Packet sebagai akar kepercayaan. Saya bertanya tentang hal itu di Twitter, tetapi tidak mendapatkan jawaban yang layak ...
Ada kuliah hebat oleh
Paul McMillan dan Matt King
tentang keamanan peralatan saat penskalaan . Para penulis menjelaskan secara rinci bagaimana melindungi perangkat keras, sementara pada saat yang sama memberikan pelanggan akses ke sana. Ketika mereka menerima kembali peralatan dari pelanggan, mereka perlu secara konsisten dan andal memastikan bahwa semuanya tetap tidak berubah dan bahwa tidak ada kejutan yang tersembunyi di komponen apa pun.
Semua penyedia cloud harus memastikan bahwa peralatan tidak terganggu setelah klien melakukan perhitungan di atasnya.
Toleransi kesalahan platform firmware
Namun, pembuat chip tampaknya memiliki tampilan khusus. Intel memiliki
Ketahanan Platform Firmware , dan Lattice memiliki
Ketahanan Platform Firmware . Mereka tampaknya lebih fokus pada pedoman NIST untuk
toleransi kesalahan firmware platform .
Saya mencoba bertanya di Internet siapa yang menggunakannya, tetapi menerima beberapa tanggapan, jadi jika Anda menggunakan perangkat dengan teknologi Platform Firmware Resiliency, beri tahu saya!
Dari
kuliah OCP tentang inovasi dalam firmware Intel, tampaknya Platform Firmware Resilience (PFR) Intel dan Cerberus berjalan beriringan. Intel menggunakan PFR untuk menerapkan Prinsip Sertifikasi Cerberus. Terima kasih
@msw atas klarifikasi.
Akan menyenangkan untuk mengurangi array alat yang berbintik-bintik untuk melakukan pekerjaan ini. Saya juga ingin melihat kode sumber untuk melihat sendiri bahwa itu aman.
Bagaimana cara membantu
Saya harap Anda tahu beberapa proyek apa yang ada untuk mengembangkan firmware open source dan betapa pentingnya itu! Jika Anda ingin membantu, beri tahu orang lain. Coba gunakan platform sumber terbuka. Chromebook adalah contoh yang bagus, juga komputer
Purism . Anda dapat bertanya kepada pemasok Anda apa yang mereka lakukan untuk merilis firmware sumber terbuka dan untuk memastikan keamanan peralatan dengan akar kepercayaan. Selamat nerd! :)