‘Jumat Biru’ tidak ada lagi

 (brendangregg.com)
1 poin oleh GN⁺ 2024-07-23 | 1 komentar | Bagikan ke WhatsApp
  • Insiden Windows global pada 19 Juli 2024 adalah kasus ketika pembaruan driver kernel dari produk keamanan menyebabkan pembacaan memori yang salah, memicu blue screen dan boot loop
  • eBPF berjalan di dalam kernel, tetapi menolak kode berbahaya melalui verifier dan sandbox, sehingga satu program tidak dirancang untuk dapat membuat seluruh sistem crash
  • Linux sudah memiliki eBPF, dan ketika eBPF for Windows dari Microsoft siap untuk produksi, perangkat lunak keamanan Windows juga dapat dipindahkan dengan cara yang sama
  • Perusahaan teknologi besar seperti Google, Meta, dan Cisco serta startup keamanan berbasis eBPF memanfaatkan kecepatan, visibilitas mendalam, dan jaminan keamanan untuk memperluas produk keamanan dan sistem deteksi
  • Perusahaan yang membeli perangkat lunak komersial yang menyertakan driver kernel atau modul kernel dapat menjadikan dukungan eBPF sebagai persyaratan vendor: sekarang di Linux, dan segera di Windows

Risiko kode kernel yang diungkap insiden Windows 19 Juli

  • Insiden pada 19 Juli 2024 merupakan contoh yang belum pernah terjadi sebelumnya yang menunjukkan risiko bawaan dari pemrograman kernel
  • Komputer Windows di seluruh dunia mengalami blue screen of death dan boot loop, menimbulkan gangguan pada rumah sakit, maskapai, bank, toko bahan makanan, stasiun penyiaran, dan lainnya
  • Penyebabnya adalah pembaruan konfigurasi (config update) dari produk keamanan yang digunakan secara luas, dan produk tersebut menyertakan driver kernel untuk sistem Windows
  • Setelah pembaruan, driver kernel mencoba membaca memori yang salah, dan jenis kesalahan seperti ini dapat membuat kernel crash

Crash yang dapat dicegah eBPF

  • eBPF bukan lagi sekadar singkatan, melainkan lingkungan eksekusi kernel yang aman yang mirip dengan runtime JavaScript aman yang tertanam di browser web
  • Pengguna Linux kemungkinan besar sudah memiliki eBPF di sistem mereka, karena eBPF telah dimasukkan ke dalam kernel Linux beberapa tahun lalu
  • Program eBPF dibatasi agar tidak dapat membuat seluruh sistem crash
    • Verifier perangkat lunak memeriksa keamanannya
    • Program pada dasarnya berjalan di dalam sandbox
    • Jika verifier menemukan kode yang tidak aman, program akan ditolak dan tidak dijalankan
  • Verifier pada implementasi Linux terdiri dari lebih dari 20 ribu baris kode, dengan kontribusi dari industri seperti Meta, Isovalent, dan Google serta dari akademisi seperti Rutgers University dan University of Washington
  • Keamanan yang diperkuat, penggunaan sumber daya yang rendah, dan pencegahan crash adalah keunggulan utama eBPF

Kemungkinan penerapan di Linux dan Windows

  • Perusahaan keamanan yang menyebabkan insiden ini sudah berada dalam proses adopsi eBPF pada sistem Linux
  • Ketika dukungan eBPF untuk Windows dari Microsoft siap untuk produksi, perangkat lunak keamanan Windows juga dapat di-port ke eBPF
  • Agen keamanan Windows yang dipindahkan ke eBPF akan menjadi bentuk yang tidak dapat menyebabkan crash pada kernel Windows

Adopsi oleh industri keamanan dan perusahaan teknologi besar

  • Startup keamanan berbasis eBPF seperti Oligo dan Uptycs menyoroti keunggulan migrasi ke eBPF setelah insiden terbaru
  • Perusahaan teknologi besar juga mulai mengadopsi eBPF untuk keamanan
    • Cisco mengakuisisi startup eBPF Isovalent dan mengumumkan Cisco Hypershield, sebuah fabric untuk penegakan keamanan dan pemantauan
    • Google dan Meta mendeteksi dan memblokir aktivitas berbahaya di lingkungan berskala besar dengan memanfaatkan kecepatan, visibilitas mendalam, dan jaminan keamanan dari eBPF
  • Selain keamanan, eBPF juga digunakan untuk networking dan observability

Keterbatasan eBPF dan langkah pelengkap operasional

  • Hal terburuk yang dapat dilakukan program eBPF adalah mengonsumsi sumber daya pada tingkat yang tidak diinginkan, seperti siklus CPU atau memori
  • eBPF tidak menghentikan kode yang boros, tetapi mencegah masalah serius yang berujung pada crash sistem
  • eBPF juga merupakan teknologi baru, sehingga pernah ada bug pada kode pengelolaannya, termasuk kasus Linux kernel panic yang ditemukan oleh perusahaan keamanan yang sama dan sempat muncul dalam berita terbaru
  • Jika bug seperti ini diperbaiki di eBPF, perbaikannya dapat diterapkan ke semua vendor eBPF, sehingga meningkatkan keamanan keseluruhan dengan lebih cepat
  • Risiko deployment tidak berhenti pada eBPF saja, dan masih ada teknik operasional yang dapat digunakan bersama
    • pengujian canary
    • rollout bertahap
    • rekayasa ketahanan secara umum

Perubahan yang dapat dituntut pembeli

  • Hal penting dari pendekatan eBPF adalah bahwa ini merupakan solusi perangkat lunak yang akan tersedia secara bawaan di kernel Linux dan Windows, dan sudah diadopsi untuk use case ini
  • Jika perusahaan membayar untuk perangkat lunak komersial yang menyertakan driver kernel atau modul kernel, mereka dapat menjadikan eBPF sebagai persyaratan
  • Di Linux hal itu sudah bisa dilakukan hari ini, dan di Windows akan segera bisa
  • Beberapa vendor sudah lebih dulu mengadopsi eBPF secara proaktif, tetapi vendor lain mungkin memerlukan tuntutan dari pelanggan yang membayar

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-23
Komentar Hacker News

  • Jika melihat daftar “hook” yang disediakan eBPF untuk Windows, tampaknya masih jauh dari kenyataan. Saat ini hanya sebatas paket masuk dan operasi socket, jadi levelnya masih seperti Microsoft mengharapkan Berkeley Packet Filter dipakai secara harfiah untuk pemfilteran paket
    Ini berbeda dari pemfilteran I/O, pembuatan/penggunaan objek, dan banyak sekali titik yang dipasang driver seperti CrowdStrike ke kernel NT
    Selain itu, untuk mengawasi sampah pihak ketiga lain yang berjalan di ruang kernel, antimalware juga harus berada di dalam kernel. ELAM (early-launch anti-malware) memuat driver antimalware lebih dulu agar dapat mengawasi perilaku driver lain, dan sangat diragukan apakah hal seperti ini bisa dilakukan dengan eBPF
    Microsoft masih punya jalan yang sangat panjang jika ingin mengganti driver antimalware ruang kernel dengan eBPF
    https://microsoft.github.io/ebpf-for-windows/ebpf__structs_8...

    • Benar bahwa eBPF harus bisa menempel pada event yang setara dengan Linux, tetapi Windows sudah memiliki banyak produsen dan konsumen event. Yang perlu dilakukan bukan membuat framework instrumentasi dari nol, melainkan menjadikan eBPF sebagai satu konsumen lagi
      Analogi: orang-orang melakukan urusan perbankan melalui situs web JavaScript di Google Chrome, tetapi di Microsoft Edge situasinya seperti, “kami tidak mendukung JavaScript, jadi unduh dan jalankan .EXE ini.” Ini lebih dekat ke pertanyaan “kapan” Microsoft akan mendukung JavaScript atau eBPF, bukan “apakah” mereka akan mendukungnya
    • Microsoft sudah memiliki fitur filter sistem berkas yang dapat diperluas yang dipakai antivirus saat ini. Saya penasaran apakah masuk akal menambahkan eBPF di atasnya, dan jika iya, apakah ada penalti performa seperti yang terlihat pada filter sistem berkas
    • Setelah insiden ini, saya berharap Microsoft berinvestasi lebih kuat pada dukungan eBPF untuk Windows

  • Saya tidak ingin berdebat dengan orang seperti Brendan Gregg, tetapi saya berharap para vendor di bidang ini menyelidiki seluruh rantai kegagalan secara lebih menyeluruh. Jika tiga hari setelah kegagalan muncul usulan bahwa “x menyelesaikan masalah yang terjadi pada tanggal y”, saya jadi berhati-hati
    Bisa saja benar, tetapi tanpa analisis, blind spot bisa tetap ada, dan mungkin ada banyak alternatif yang setelah ditinjau seharusnya dibuang dengan tepat
    Secara khusus, saya sulit setuju dengan bagian “hasil negatif terburuknya hanyalah pemborosan CPU.” Untuk kelas bug tertentu mungkin begitu, tetapi ada cukup banyak mode kegagalan di mana kumpulan aturan yang keliru dapat membuat sistem benar-benar brick dan sulit dipulihkan
    Ini bukan berarti modul keamanan berbasis eBPF bukan pilihan yang tepat bagi banyak vendor, melainkan ajakan untuk memahami risiko apa yang dihindari dan risiko apa yang tidak, serta bagian mana dari rantai kegagalan yang ditangani

    • Fakta bahwa Anda tidak tahu diskusi tentang topik ini sudah berlangsung selama beberapa tahun bukan berarti diskusi itu tidak pernah ada. Ini bukan analisis yang tiba-tiba muncul tiga hari setelah insiden, melainkan lebih dekat ke konsensus yang umumnya diterima di antara berbagai pakar yang telah memperkenalkan API baru seperti ini untuk meningkatkan stabilitas, keamanan, dan lain-lain dari sistem
    • Microsoft telah mengerjakan eBPF setidaknya selama beberapa tahun
      https://opensource.microsoft.com/blog/2021/05/10/making-ebpf...
      https://lwn.net/Articles/857215/
      Jika memang ada kekhawatiran, ada juga kanal diskusi untuk menyampaikan pendapat, dan semuanya dirangkum di GitHub
      https://github.com/microsoft/ebpf-for-windows
      Jawabannya mungkin sudah ada, dan jika belum, hal itu bisa dibahas di sana

  • Itu tidak benar. Jika strukturnya mengharuskan ada potongan kode tertentu agar sistem bisa berjalan, maka saat kode itu rusak, sistem semestinya sama sekali tidak berjalan. Mengabaikan kegagalan itu aneh
    Misalnya, jika kode driver suatu perangkat medis menjamin pengunci keselamatan agar perangkat itu tidak membakar orang, saya akan memilih seluruh sistem berhenti daripada tetap beroperasi seolah tidak terjadi apa-apa dengan pengaman dalam keadaan mati
    Pada akhirnya, meski turun ke level yang lebih rendah, masalahnya tetap sama

    • Saya rasa premisnya sendiri keliru. Apa yang harus dilakukan saat ada input yang salah bisa ditentukan oleh implementor eBPF, dan kernel juga bisa memilih penghentian yang terkendali dalam kasus itu
      Saya tidak tahu Linux sebenarnya melakukan apa, tetapi kita juga bisa membayangkan dunia di mana perilaku terhadap input yang salah dapat dikonfigurasi
      Selain itu, pernyataan itu tidak selalu benar. Dalam kasus umum saya setuju, tetapi dalam konteks tertentu sistem harus terus bergerak. Contoh yang langsung terpikir adalah komputer pemandu pendarat Mars otomatis. Latensi pulang-pergi dengan Bumi terlalu panjang untuk melempar tanggung jawab
      Jika berhenti, ia akan jatuh; tetapi jika melakukan yang terbaik dalam kondisi rusak, mungkin ia hanya akan jatuh juga, jadi opsi itu bisa lebih baik
    • Perangkat lunak perangkat medis cukup mengeluarkan pesan kesalahan dan menolak berjalan jika driver penting belum dimuat
      Jika seluruh sistem operasi menjadi brick, teknisi IT harus memperbaikinya secara langsung, sehingga itu menjadi masalah yang jauh lebih besar. Kalau tidak begitu, cukup memperbarui driver yang bermasalah saja
      Mobil juga tidak gagal menyala hanya karena cairan wipernya habis
    • Saya setuju bahwa beberapa komponen sistem harus selalu diperlakukan sebagai penting, tetapi Falcon Sensor yang bermasalah kali ini, atau antivirus pada umumnya, bersifat preventif dan bagaimanapun merupakan upaya best effort
      Sebagian besar organisasi yang terdampak pada hari Jumat mungkin akan lebih memilih sedikit peningkatan risiko serangan malware atau penggunaan tanpa izin selama 24 jam daripada keruntuhan total IT yang benar-benar mereka alami
      Selain itu, bug tersebut tidak harus selalu menyebabkan blue screen. Sistem bisa saja terus berjalan dalam keadaan tidak terdefinisi dengan konsekuensi tak terbatas
      Dengan eBPF, setidaknya sebagian kesalahan yang mungkin terjadi bisa dideteksi, lalu keputusan manajemen risiko dapat diambil berdasarkan hasilnya
    • Karena alasan ini, saya menyukai pendekatan Unison. Fungsi dipanggil melalui hash kriptografis, sehingga ada jaminan tertentu bahwa fungsi yang dipanggil sama dengan yang dipanggil kemarin
      Untuk melakukan pembaruan, pemanggil harus memanggil fungsi lain, sehingga tanggung jawab berada pada pemanggil, bukan pada orang yang bisa menyentuh kernel lewat jalan samping
      Jika tidak ada fungsi yang sesuai dengan hash yang ditampilkan, fungsi itu tidak bisa dipanggil; dan sekalipun ada, ia tidak bisa dipanggil selain dengan cara yang dimaksudkan, sehingga kita mendapatkan sifat yang diinginkan: “berfungsi sempurna atau tidak berfungsi sama sekali”
    • Sistemnya memang sudah beroperasi dengan cara mengabaikan kegagalan. Sebab perbaikan sebenarnya pun hanya menghapus file yang bermasalah. Jika itu adalah sebuah opsi, loader juga bisa melakukannya, atau bisa bertindak lebih cerdas seperti “kembali ke versi sebelumnya”
      Selain itu, respons terhadap keadaan yang salah tidak harus selalu berupa “mengabaikan”. Bisa juga menonaktifkan login pengguna secara terbatas atau mematikan layar
      Jika kekhawatirannya adalah malware dapat menyalahgunakan ini, saya ragu apakah merupakan ide bagus untuk percaya bahwa sistem itu sendiri bisa menanganinya ketika malware sudah berada dalam posisi dapat menimpa file antivirus di disk
      Mungkin lebih aman melaporkannya ke sistem keamanan tingkat lebih tinggi dan membiarkan sistem eksternal mengambil tindakan untuk menonaktifkan atau membatasi akses jaringan. Lebih jauh lagi, tindakan seperti ini hanya memerlukan hak observasi, bukan hak untuk mengintervensi sistem, sehingga kemungkinan sistem antivirus itu sendiri menjadi jalur malware atau penyebab bug semacam ini juga berkurang

  • eBPF itu bagus dan bisa dipakai untuk banyak tujuan serta memperbaiki banyak hal, tetapi pernyataan bahwa “komputer tidak akan crash karena pembaruan perangkat lunak yang buruk” tampak berlebihan
    Bahkan dengan asumsi BPF sendiri tidak memiliki bug, cakupan hook kernel cukup luas, hook tersebut memanggil kode eBPF, dan kode itu pada gilirannya bisa memanggil kernel lagi
    https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html
    Khususnya bpf_probe_read_kernel() sangat sering digunakan, tetapi tidak aman. Ada cukup banyak upaya untuk menghindari OOPS atau crash, tetapi sama sekali tidak sempurna
    Di daftar lainnya juga ada banyak hal yang dapat dengan mudah merusak sistem meskipun tidak benar-benar menyebabkan oops atau panic
    Dan jika itu adalah alat untuk mendeteksi dan memblokir “perilaku jahat” di ruang pengguna, alat tersebut juga bisa mulai menilai semuanya sebagai jahat dan membuat komputer tidak dapat digunakan
    Sementara itu, eBPF tidak memiliki model keamanan nyata di sisi ruang pengguna. Pemasangan aktual program eBPF dilakukan melalui system call bpf(), bukan operasi izin yang masuk akal terhadap objek kernel target tempat ia menempel, dan sama sekali tidak ada mekanisme untuk mengurung eBPF yang digunakan sebuah container di dalam container tersebut. bpf_probe_read_kernel() pada dasarnya dapat membaca seluruh memori kernel
    Jadi keunggulan eBPF dibanding kode C kernel biasa adalah mirip dengan menulis kode dalam bahasa yang aman dengan permukaan API unsafe yang terbatas. Untuk pekerjaan seperti ini, itu peningkatan besar, tetapi sama sekali tidak sempurna
    Ada juga yang mengatakan verifier-nya ketat dan implementasi Linux-nya lebih dari 20 ribu baris, tetapi verifier itu luar biasa kompleks. Saya lebih ingin melihatnya berbasis metode formal daripada logika 20 ribu baris yang ditulis tangan

    • Saya penasaran bagaimana mungkin menyebabkan panic dengan bpf_probe_read_kernel. Bisakah memberi contoh yang berjalan pada versi kernel saat ini?

  • Saya jadi meragukan pernyataan bahwa “program eBPF menjalani pemeriksaan keamanan oleh verifier perangkat lunak dan pada dasarnya berjalan di sandbox, sehingga tidak bisa membuat seluruh sistem crash.”
    Bukankah salah satu tujuan sistem operasi adalah mengawasi perangkat lunak? Saya tahu ini masalah yang berkaitan dengan sistem operasi itu sendiri, tetapi kalau kita menambahkan lapisan untuk mengawasi sang pengawas, bukankah pada akhirnya lapisan itu juga harus diawasi lagi?
    Tidak bisakah kita memilih pengurangan kompleksitas, alih-alih secara naif percaya bahwa kompleksitas baru akan lebih baik dalam jangka panjang?

    • eBPF bukan “mengawasi sang pengawas”, melainkan alat yang memungkinkan alat-alat lain mengakses elemen tingkat rendah kernel melalui sandbox yang sangat ketat.
      Cara lama adalah memuat driver kernel, memasang hook pada banyak sekali system call, lalu berdoa semoga tidak merusak apa pun. Kalau salah bisa terjadi panic, tetapi Linux cukup tangguh.
      Pendekatan eBPF lebih mendekati meminta informasi yang diinginkan lewat instruksi khusus eBPF.
      Ringkasan cara kerjanya ada di sini: https://ebpf.io/what-is-ebpf/
    • Mungkin bisa juga meminta chatbot AI menjelaskan proses pembenaran yang sejak awal membuat orang memakai sesuatu seperti CrowdStrike.

  • Terdengar seperti teknologi yang keren, tetapi masalah yang benar-benar serius adalah bagian bahwa “metode mitigasi risiko deployment perangkat lunak seperti canary testing, rollout bertahap, dan resilience engineering juga bisa digunakan.”
    Tidak perlu teknologi baru untuk menerapkan quality control dasar yang merupakan standar industri.

  • Untuk memperingati insiden ini, rasanya boleh juga mulai meliburkan hari Jumat. Kalau orang bekerja dengan tekanan yang lebih rendah, dan punya lebih banyak waktu untuk berhenti sejenak memikirkan ke mana situasi mengalir serta pengaruh apa yang bisa mereka berikan pada aliran itu, mungkin kerugiannya bisa lebih kecil.

  • Penjelasan bahwa verifier pada implementasi Linux berisi lebih dari 20 ribu baris dan mendapat kontribusi dari industri serta akademisi justru tidak membuat saya tenang. Selain attack surface tambahan, siapa yang bisa menjamin codebase sebesar itu?

    • Saya juga berpikir persis begitu. Entah angka 20 ribu baris itu dimaksudkan untuk menumbuhkan kepercayaan atau tidak, tetapi bagi saya efeknya justru sebaliknya. Kalau 300 baris, saya akan lebih percaya.
      Kesan saya, verifier WebAssembly jauh lebih sederhana.

  • Jika filter dimuat saat boot dan memasang hook pada semuanya, satu bug saja bisa membuat sistem terkunci sampai tidak bisa dioperasikan ataupun dipatch. Misalnya ketika memuat allowlist kosong; pada akhirnya itu bisa mengubah boot loop menjadi bentuk lain dari denial of service.
    Jika Microsoft memasukkan elemen-elemen inti yang diperlukan untuk pemulihan ke dalam allowlist hardcoded, bug pada alat seperti ini mungkin bisa diperbaiki lebih mudah, tetapi sampai perbaikannya didistribusikan, bisa muncul downtime nyata di mana sistem menyala tetapi tidak bisa dipakai.

  • Di tulisan blog disebutkan bahwa “eBPF kebal terhadap crash seperti ini.”
    Saya sudah mencari, tetapi tidak menemukan penjelasan yang pasti, dan sepertinya eBPF tetap bisa merusak sesuatu. Saya berharap ada pakar eBPF yang menjelaskan klaim ini. Materi terbaik yang saya temukan adalah ini: https://stackoverflow.com/questions/70403212/why-is-ebpf-sai...

    • Program eBPF tidak bisa membuat kernel crash, dengan asumsi tidak ada bug pada verifier eBPF. Dulu pernah ada bug seperti itu, tetapi tampaknya makin jarang terjadi.