Mengatasi Supply Chain Attacks – Salah satu pencapaian tanpa tanda jasa dari pengembangan perangkat lunak modern adalah sejauh mana ia telah menjadi komponen: belum lama ini, ketika Anda ingin menulis sebuah perangkat lunak, Anda harus menulis hampir semuanya menggunakan alat apa pun yang disediakan oleh bahasa tersebut. Anda menulis, mungkin dengan beberapa pustaka khusus seperti OpenSSL. Tidak lagi. Kombinasi bahasa yang lebih baru, pengembangan Open Source, dan sistem manajemen paket yang mudah digunakan seperti npm JavaScript atau Rust’s Cargo / crates.io telah merevolusi cara orang menulis perangkat lunak, menjadikannya praktik standar untuk menarik pustaka pihak ketiga bahkan untuk tugas yang paling sederhana ; tidak jarang program bergantung pada ratusan atau ribuan paket pihak ketiga.
Mengatasi Supply Chain Attacks
firefoxfacts – Supply Chain Attacks : Meskipun paradigma baru ini telah merevolusi pengembangan perangkat lunak, hal itu juga meningkatkan risiko serangan rantai pasokan, di mana penyerang membahayakan salah satu dependensi Anda dan melalui perangkat lunak Anda. Contoh terkenal dari hal ini disediakan oleh kompromi 2018 dari paket aliran acara untuk mencuri Bitcoin dari komputer orang. Riwayat singkat Register memberikan gambaran tentang skala masalah:
Ayrton Sparling, seorang mahasiswa ilmu komputer di California State University, Fullerton (FallingSnow di GitHub), menandai masalah tersebut minggu lalu di postingan masalah GitHub. Menurut Sparling, sebuah commit ke modul event-stream menambahkan flatmap-stream sebagai dependensi, yang kemudian menyertakan kode injeksi yang menargetkan paket lain, ps-tree.
Baca juga : Logo Firefox Tidak Sedang Diubah
Ada beberapa cara penyerang dapat memasukkan malware ke dalam sebuah paket. Dalam kasus ini, yang tampaknya telah terjadi adalah pengelola asli aliran peristiwa tidak lagi mengerjakannya dan orang lain secara sukarela mengambil alih. Biasanya, itu bagus, tapi di sini tampaknya sukarelawan itu jahat, jadi itu tidak bagus.
Standar untuk Paket Kritis
Baru-baru ini, Eric Brewer, Rob Pike, Abhishek Arya, Anne Bertucio, dan Kim Lewandowski memposting proposal di blog keamanan Google untuk mengatasi kerentanan dalam perangkat lunak Open Source. Mereka mencakup sejumlah masalah termasuk manajemen kerentanan dan keamanan kompilasi, dan ada banyak hal bagus di sini, tetapi bagian yang paling mendapat perhatian adalah saran bahwa paket tertentu harus dianggap “kritis” :
Untuk perangkat lunak yang sangat penting bagi keamanan, kami perlu menyetujui proses pengembangan yang memastikan tinjauan yang memadai, menghindari perubahan sepihak, dan secara transparan mengarah ke versi resmi yang terdefinisi dengan baik dan dapat diverifikasi.
Baca juga : 10 Aplikasi Edit Gambar Terbaik serta Instagramable di Smartphone
Ini adalah praktik pengembangan yang baik, dan yang kami ikuti di sini di Mozilla, jadi saya pasti mendorong orang untuk mengadopsinya. Namun, mencoba meminta mereka untuk perangkat lunak kritis sepertinya akan memiliki beberapa masalah.
Ini menciptakan gesekan bagi pengembang paket
Salah satu manfaat nyata dari model baru pengembangan perangkat lunak ini adalah gesekannya rendah: mudah untuk mengembangkan perpustakaan dan membuatnya tersedia – Anda cukup menulisnya, meletakkannya di repositori paket seperti crates.io – dan mudah digunakan paket-paket itu – Anda cukup menambahkannya ke konfigurasi build Anda. Tapi kemudian Anda berhasil dan tiba-tiba paket Anda digunakan secara luas dan dianggap “penting” dan sekarang Anda harus menerapkan semua jenis praktik baru. Mungkin akan lebih baik jika Anda melakukan ini, tetapi bagaimana jika tidak? Pada titik ini paket Anda banyak digunakan – atau tidak akan menjadi kritis – jadi bagaimana sekarang?
Itu tidak cukup
Bahkan paket yang dipelihara dengan baik dan memiliki praktik pengembangan yang baik secara rutin memiliki kerentanan. Misalnya, Firefox baru-baru ini merilis versi baru yang memperbaiki kerentanan pada mesin grafis ANGLE yang populer, yang dikelola oleh Google. Baik Mozilla dan Google mengikuti praktik yang direkomendasikan oleh entri blog ini, tetapi hanya saja orang-orang membuat kesalahan. Untuk (mungkin salah) mengutip Steve Bellovin, “Perangkat lunak memiliki bug. Perangkat lunak yang relevan dengan keamanan memiliki bug yang relevan dengan keamanan ”. Jadi, meskipun praktik ini penting untuk mengurangi risiko kerentanan, kami tahu praktik tersebut tidak dapat menghilangkannya.
Tentu saja ini berlaku untuk kerentanan yang tidak disengaja, tetapi bagaimana dengan aktor jahat (meskipun perhatikan bahwa Brewer dkk. Mengamati bahwa “Mundur selangkah, meskipun serangan rantai pasokan berisiko, sebagian besar kerentanan bersifat biasa dan tidak disengaja — kesalahan jujur dibuat oleh pengembang yang bermaksud baik. ”)? Ada kemungkinan bahwa beberapa perubahan yang mereka usulkan (khususnya melarang penulis anonim) mungkin berdampak di sini, tetapi sangat sulit untuk melihat bagaimana hal ini dapat ditindaklanjuti. Apa standar untuk tidak menjadi anonim? Bahwa Anda punya alamat email? Halaman Web? Nomor DUNS? [3] Tak satu pun dari hal ini yang tampaknya sangat sulit bagi penyerang berdedikasi untuk memalsukan dan tentu saja semakin ketat Anda membuat persyaratan, semakin menjadi beban bagi (sebagian besar) pengembang yang sah.
Saya ingin mengakui pada titik ini bahwa Brewer et al. dengan jelas menyatakan bahwa perlindungan berlapis diperlukan dan bahwa itu perlu memiliki mekanisme yang kuat untuk menangani pertahanan kerentanan. Saya setuju dengan semua itu, saya hanya kurang yakin tentang karya khusus ini.
Mendefinisikan Ulang Kritis
Bagian dari kesulitannya di sini adalah ada beberapa cara di mana sebuah perangkat lunak bisa menjadi “kritis”:
Itu dapat melakukan sesuatu yang secara inheren sensitif terhadap keamanan (misalnya, tumpukan SSL / TLS OpenSSL yang bertanggung jawab untuk mengamankan sebagian besar lalu lintas Internet).
Ini dapat digunakan secara luas (mis., Log Rust), tetapi tidak secara inheren sensitif.
Sebagian besar paket – digunakan secara luas atau tidak – termasuk dalam kategori kedua: mereka melakukan sesuatu yang penting tetapi tidak penting bagi keamanan. Sayangnya, karena cara pembuatan perangkat lunak secara umum, ini tidak menjadi masalah: bahkan ketika perangkat lunak dibuat dari tumpukan komponen kecil, ketika mereka dikemas ke dalam satu program, setiap komponen memiliki semua hak istimewa itu. program memiliki. Jadi, misalnya, Anda menyertakan komponen untuk melakukan penghitungan statistik: jika komponen itu dikompromikan, tidak ada yang menghentikannya untuk membuka file di disk Anda dan mencuri kata sandi atau Bitcoin atau apa pun. Ini benar apakah penyusupan itu disebabkan oleh kerentanan yang tidak disengaja atau malware yang disuntikkan ke dalam paket: masalah di setiap komponen membahayakan seluruh sistem. Memang, komponen non-keamanan kecil menjadi target yang menarik karena mereka mungkin tidak memiliki pengawasan sebanyak komponen keamanan profil tinggi.
Hak Istimewa Paling Sedikit dalam Praktik: Sandboxing yang Lebih Baik
Jika dilihat dari perspektif ini, jelas terlihat bahwa kami memiliki masalah teknologi: Tidak ada alasan yang tepat untuk setiap komponen memiliki kekuatan sebesar ini. Sebaliknya, mereka seharusnya hanya memiliki kemampuan yang mereka butuhkan untuk melakukan pekerjaan yang mereka inginkan (istilah teknisnya adalah hak istimewa yang paling rendah); hanya saja alat perangkat lunak yang kami miliki tidak berfungsi dengan baik dalam menyediakan properti ini. Ini adalah situasi yang telah lama dikenali dalam perangkat lunak yang rumit seperti browser Web, yang menggunakan teknik yang disebut “kotak pasir proses” (dipelopori oleh Chrome) di mana kode yang berinteraksi dengan situs Web dijalankan di “kotak pasir” -nya sendiri dan memiliki kemampuan terbatas untuk berinteraksi dengan komputer Anda. Saat ingin melakukan sesuatu yang tidak diizinkan, ia akan berbicara dengan kode browser Web utama dan memintanya untuk melakukannya, sehingga memungkinkan kode tersebut untuk menegakkan aturan tanpa terkena kerentanan di browser lainnya.
Proses sandboxing adalah alat yang penting dan kuat, tapi ini adalah salah satu alat kelas berat; tidak praktis untuk memisahkan setiap subkomponen dari program besar ke dalam prosesnya sendiri. Kabar baiknya adalah ada beberapa teknologi terkini yang memungkinkan jenis sandboxing halus ini, keduanya didasarkan pada WebAssembly. Untuk program WebAssembly, proses nano memungkinkan masing-masing komponen berjalan di kotak pasir mereka sendiri dengan daftar kontrol akses khusus komponen. Baru-baru ini, kami telah bereksperimen dengan teknologi yang disebut RLBox yang dikembangkan oleh para peneliti di UCSD, UT Austin, dan Stanford yang memungkinkan program reguler seperti Firefox untuk menjalankan komponen kotak pasir. Ide dasar di balik keduanya adalah sama: gunakan teknik kompilasi statis untuk memastikan bahwa komponen tersebut aman dari memori (yaitu, tidak dapat menjangkau bagian luarnya untuk menyentuh bagian lain dari program) dan kemudian berikan hanya kemampuan yang diperlukan. lakukan tugasnya.
Teknik seperti ini menunjukkan jalan menuju pendekatan teknis yang dapat diskalakan untuk melindungi diri Anda dari komponen pihak ketiga: setiap komponen diisolasi dalam kotak pasirnya sendiri dan dilengkapi dengan daftar kemampuan yang dibutuhkannya (sering disebut manifes) dengan kompilator yang memberlakukannya. tidak memiliki kemampuan lain (ini tidak terlalu berbeda dengan – tetapi jauh lebih terperinci daripada – izin yang diminta aplikasi seluler). Hal ini membuat masalah memasukkan komponen baru menjadi lebih sederhana karena Anda hanya dapat melihat kapabilitas yang dimintanya, tanpa perlu memverifikasi bahwa kode itu sendiri berperilaku dengan benar.
Membuat Auditing Lebih Mudah
Meskipun kuat, sandboxing itu sendiri – baik proses tradisional atau variasi WebAssembly – tidaklah cukup, karena dua alasan. Pertama, API yang harus kami tangani kurang terperinci. Pertimbangkan kasus komponen yang dirancang untuk memungkinkan Anda membuka dan memproses file pada disk; ini diperlukan untuk dapat membuka file, tetapi apa yang menghentikannya dari membaca Bitcoin Anda alih-alih file yang ingin dibaca oleh programmer? Dimungkinkan untuk membuat daftar kemampuan yang mencakup hanya membaca file tertentu, tetapi itu bukan API yang diberikan oleh sistem operasi kepada Anda, jadi sekarang kita perlu menciptakan sesuatu. Ada banyak kasus seperti ini, jadi semuanya menjadi rumit.
Alasan kedua adalah bahwa beberapa komponen penting karena menjalankan fungsi kritis. Misalnya, tidak peduli seberapa banyak Anda melakukan sandbox OpenSSL, Anda masih harus khawatir tentang fakta bahwa OpenSSL menangani data sensitif Anda, dan jika disusupi, hal itu mungkin membocorkannya. Untungnya, kelas komponen penting ini lebih kecil, tetapi bukan nol.
Ini tidak berarti bahwa kotak pasir tidak berguna, hanya saja itu tidak cukup. Yang kami butuhkan adalah perlindungan berlapis , dengan lapisan pertama merupakan mekanisme prosedural untuk mempertahankan kode yang dikompromikan dan lapisan kedua adalah kotak pasir yang sangat halus untuk menampung dampak penyusupan. Seperti disebutkan sebelumnya, tampaknya bermasalah untuk membebani pengembang komponen dengan beban proses yang lebih baik, terutama bila ada sejumlah besar proyek yang bergantung, banyak di antaranya didanai dengan sangat baik.
Sesuatu yang telah kami lihat secara internal di Mozilla adalah cara bagi proyek tersebut untuk menandai dependensi yang mereka gunakan dan andalkan. Cara kerjanya adalah setiap proyek kemudian akan diberi tag dengan sekumpulan proyek lain yang menggunakannya (mis., “Firefox menggunakan peti ini”). Kemudian ketika Anda mempertimbangkan untuk menggunakan komponen, Anda dapat melihat siapa lagi yang menggunakannya, yang memberi Anda tingkat kepercayaan. Tentu saja, Anda tidak tahu jenis audit yang dilakukan organisasi tersebut, tetapi jika Anda tahu bahwa Project X sangat memperhatikan keamanan dan mereka menggunakan komponen Y, itu akan memberi Anda tingkat kepercayaan tertentu. Ini benar-benar hanya mengotomatiskan sesuatu yang sudah terjadi secara informal: orang menilai komponen berdasarkan siapa lagi yang menggunakannya. Ada beberapa ekstensi yang jelas di sini, misalnya memberi label pada versi tertentu, memiliki indikasi jenis audit apa yang dilakukan oleh proyek yang bergantung, atau memungkinkan orang untuk mengonfigurasi sistem pembangunan mereka untuk secara otomatis mempercayai proyek yang dijamin oleh beberapa rangkaian proyek lain dan menolak untuk menyertakan tanpa jaminan. proyek, memelihara database versi yang tidak aman (ini juga disarankan oleh proposal Brewer dkk.). Keuntungan dari pendekatan semacam ini adalah bahwa hal itu memberikan beban pada orang-orang yang mendapat manfaat dari suatu proyek, daripada membuat beberapa proyek yang banyak digunakan tiba-tiba tunduk pada seluruh tumpukan persyaratan baru yang mungkin tidak tertarik untuk mereka penuhi. Pekerjaan ini masih dalam tahap eksplorasi, jadi hubungi saya jika Anda tertarik.
Jelas, ini hanya berfungsi jika orang benar-benar melakukan semacam uji tuntas sebelum bergantung pada suatu komponen. Di sini, di Mozilla, kami melakukan itu sampai batas tertentu, meskipun tidak benar-benar praktis untuk meninjau setiap baris kode dalam paket raksasa seperti WebRTC Ada beberapa harapan juga di sini: karena bahasa modern seperti Rust atau Go aman dari memori, banyak lebih mudah untuk meyakinkan diri sendiri bahwa perilaku tertentu tidak mungkin – bahkan jika program memiliki cacat – yang membuatnya lebih mudah untuk diaudit. Di sini juga dimungkinkan untuk memiliki manifes yang jelas yang menggambarkan kemampuan apa yang dibutuhkan program dan memverifikasi (setelah beberapa pekerjaan) bahwa itu akurat.
