Rincian awal penyebab crash CrowdStrike CSAgent.sys

• Crash Windows di seluruh dunia pada analisis awal diperkirakan berasal dari alur saat CSAgent.sys milik CrowdStrike mereferensikan alamat memori yang salah
• Instruksi yang bermasalah adalah mov r9d, [r8], dan R8 berisi alamat yang tidak dipetakan yang diambil sebagai indeks dari array pointer
• Berkas C-00000291-...xxx.sys tampak bukan driver kernel, melainkan data terobfuskasi yang dibaca oleh CSAgent.sys, dan CrowdStrike mengonfirmasi ini sebagai berkas konfigurasi Channel Files
• CrowdStrike menyatakan C-00000291- memicu kesalahan logika yang berujung pada crash OS, dan menolak dugaan bahwa penyebabnya adalah null byte di dalam Channel File
• Rilis kali ini diperlakukan sebagai pembaruan konten, bukan pembaruan versi, sehingga dalam beberapa kasus melewati kontrol staging klien, dan crash report menjadi petunjuk kunci dalam analisis penyebab

---

Alur crash CSAgent.sys

• Analisis awal dilakukan melalui reverse engineering terhadap CSAgent.sys milik CrowdStrike dan analisis statis berdasarkan satu crash dump
  • Saat itu materi dibagikan tanpa sistem Windows atau VM, sambil meminta investigasi tambahan
  • CSAgent.sys dianalisis berdasarkan berkas yang diunggah ke VirusTotal: Sampel VirusTotal
• Titik crash ada pada instruksi mov r9d, [r8]
  • R8 adalah alamat yang tidak dipetakan
  • Nilai ini adalah alamat yang diambil dari array pointer di RAX menggunakan indeks RDX (0x14 * 0x8)
• Berkas .sys lain seperti C-00000291-...32.sys tampak sebagai data terobfuskasi, bukan driver sungguhan
  • Ada indikasi bahwa CSAgent.sys merujuk atau membaca berkas-berkas ini
  • Karena crash dapat teratasi dengan menghapus berkas tersebut, muncul kemungkinan bahwa isi berkas memengaruhi crash CSAgent.sys
  • Disebutkan pula bahwa hal ini akan lebih mudah dipastikan lewat debugging
• .zip yang dibagikan berisi beberapa versi CSAgent.sys, IDB, dan beberapa berkas C-....sys
  • Salah satu berkas terbaru tampak mengandung “fix”
  • Tautan berbagi: Google Drive zip

Channel Files dan konfirmasi dari CrowdStrike

• Kevin Beaumont menulis bahwa berkas .sys yang menyebabkan masalah adalah channel update files, dan format yang salah membuat driver CS tingkat atas crash
  • Tautan: posting Kevin Beaumont
• Penjelasan teknis CrowdStrike mengonfirmasi arah yang sama dengan analisis awal
  • Berkas C-...sys bukan driver kernel, melainkan berkas konfigurasi bernama Channel Files
  • C-00000291- memicu kesalahan logika, yang kemudian menyebabkan crash OS melalui CSAgent.sys
  • Tautan: penjelasan teknis CrowdStrike
• Sebagian pihak menduga Channel File 0x0 yang kosong sebagai penyebab, tetapi CrowdStrike membantah bahwa masalah ini terkait dengan null byte di dalam Channel File
  • Malware Utkonos menyoroti pemeriksaan bahwa berkas harus diawali dengan 0xaaaaaaaa: posting terkait
• Dipastikan bahwa channel update didistribusikan dengan melewati kontrol staging pada sebagian klien
  • Beberapa staf TI mengonfirmasi bahwa mereka telah mengatur kebijakan CrowdStrike untuk mengabaikan versi terbaru, tetapi pembaruan kali ini tetap lolos karena merupakan pembaruan konten, bukan pembaruan versi
  • Posting terkait: thread ResetEra
• Dalam paten CrowdStrike, istilah channel files juga muncul berkali-kali
  • Contohnya disebutkan US11822515B2 dan US11645397B2
  • Kata kunci pencarian: channel file assignee:(Crowdstrike, Inc.)

Crash report dan petunjuk dari macOS System Extensions

• Crash report menjadi sarana untuk memahami crash CrowdStrike, dan juga pernah digunakan untuk mengungkap 0day lain di macOS
  • Judul presentasi Black Hat terkait adalah “The Hidden Treasure of Crash Reports?”
  • Tautan: halaman presentasi Black Hat
• Langkah Apple menghentikan 3rd-party kext dan beralih ke System Extensions mode pengguna dinilai positif
  • Namun, dicatat bahwa selama transisi ini sempat ada masalah kernel panic, eskalasi hak akses, dan unload alat keamanan
• Pada macOS, kode kernel yang mendukung System Extensions mode pengguna memiliki banyak bug, dan pernah ada kasus alat keamanan yang dipindahkan ke mode pengguna memicu kernel panic luas pada kext inti Apple
• Masalah eskalasi hak akses pada framework inti macOS System Extension disebut sebagai CVE-2019-8805
  • Presentasi terkait: Endpoint Security and Insecurity
• Karena cacat dalam penanganan System Extensions, kode tak berprivileg atau malware dapat memicu unload alat keamanan
  • Sebagai contoh, disebutkan bahwa bahkan pada macOS terbaru, firewall LuLu yang berjalan sebagai System Extension tepercaya dapat dihentikan
  • Bug ini bukan masalah yang hanya berlaku pada LuLu

[GN⁺]

Komentar Hacker News

• Begitu melihat pernyataan “ini adalah pembaruan konten yang menyebabkan BSOD, dan menghapusnya menyelesaikan masalah”, saya merasa bisa bertaruh £100 bahwa ini adalah kombinasi data biner yang rusak dan parser yang ditulis dengan buruk
  Saya sudah cukup serius berkecimpung di komputasi selama sekitar 10 tahun dan sama sekali tidak bekerja di keamanan siber, tetapi menurut saya hampir semua CVE, crash, bug, penurunan performa, dan penderitaan berasal dari proses deserialisasi data biner kembali menjadi struktur data yang bisa dibaca mesin
  Itu terjadi karena programmer manusia melewatkan edge case, dan bahasa imperatif mengizinkannya. Ini mencakup algoritme dekompresi, pembaca outline font, parser gambar·video·audio, parser data game, parser XML/HTML, parser sertifikat·tanda tangan·kunci milik OpenSSL, sampai parser konten EDR CrowdStrike kali ini
  Saya bahkan bisa menambah taruhan £50 untuk hipotesis kedua

  • Menurut saya setidaknya ada lima hal yang salah secara bersamaan. Penanganan error yang buruk pada modul kernel mematikan seluruh sistem operasi, lalu file rusak terus diparsing hingga membuat boot loop, dan file itu juga tidak dihapus atau ditandai sebagai rusak
    File rusak itu mungkin lolos pengujian internal atau memang tidak ada pengujian internal, dan sepertinya pengaturan individual soal waktu penerapan pembaruan juga diabaikan. Selain itu, distribusinya dilakukan serentak ke seluruh dunia sehingga dampaknya tidak dibatasi, dan sampai sekarang juga belum jelas kenapa kerusakan file itu bisa terjadi sejak awal
  • Daftar 25 kelemahan umum teratas tahun 2023 ada di https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
    Deserialisasi data yang tidak tepercaya (CWE-502) berada di peringkat 15, sementara peringkat 1 adalah write out-of-bounds (CWE-787), dan peringkat 4 adalah use-after-free (CWE-416). Kelemahan yang selalu masuk daftar sejak 2019 dirangkum di https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html
  • Bukan “hampir 100%”, tapi lebih ke sekitar 98%. Sisa 2% diisi oleh bug logika, salah konfigurasi, default yang buruk, dan pilihan desain yang sejak awal tidak aman
    Sebagai catatan, saya sudah bekerja di bidang keamanan informasi selama lebih dari 30 tahun
  • Menurut saya sulit menyalahkan pemrograman imperatif. Misalnya Rust itu imperatif, tetapi cukup bagus dalam menangkap kasus yang terlewat di switch
    Sebaliknya, varian Scheme yang saya pakai 20 tahun lalu bersifat fungsional tetapi tidak memeriksa apakah semua kasus sudah tercakup, dan ghc milik Haskell juga beberapa tahun lalu belum mengaktifkan pemeriksaan itu secara default. Saya tidak tahu apakah sekarang sudah berubah
  • Saya tidak tahu mana yang lebih fatal. Apakah fakta bahwa pada dasarnya tidak ada penanganan error/kegagalan, atau fakta bahwa “pembaruan channel melewati kontrol staging pelanggan dan didorong ke semua orang”
    Beberapa staf IT sudah memastikan bahwa meskipun kebijakan CS mereka diatur untuk mengabaikan versi terbaru, ini tetap lolos karena bukan “pembaruan versi” melainkan “pembaruan konten”. Jika pembaruan konten bisa merusak klien, maka pembaruan itu tidak boleh bisa melewati kontrol staging atau kebijakan

• Terlepas dari apakah perangkat lunak pemantauan endpoint berbasis rootkit seperti CS benar-benar diperlukan, alternatif open source bisa menjadi cara yang kuat untuk mendorong bidang ini ke standar yang lebih etis
  Jika alat intinya open source, maka akan transparan soal apa yang sebenarnya dilakukannya, dan publik bisa mengaudit apakah ada backdoor atau bug serius. Sementara itu, cara tim keamanan memasok signature malware masih bisa tetap menjadi model bisnis

  • Saya rasa tidak. Kolide adalah salah satu upaya ke arah itu, tetapi praktik nyata dan cara pemakaiannya di perusahaan sama suramnya dengan produk tertutup
    Dari sudut pandang pengguna, tidak ada alasan untuk merasa tenang bahwa rootkit pemantauan open source akan lebih teruji, lebih baik dikembangkan, atau mempertimbangkan kepentingan saya. Masalahnya adalah keseluruhan kategori perangkat lunak pemantauan itu sendiri. Seharusnya itu tidak ada. Perusahaan yang memakai hal seperti ini tidak memahami keamanan, tidak memercayai karyawannya, dan juga bukan tempat kerja yang baik
  • Ada GRR sebagai alternatif open source: https://github.com/google/grr
    Digunakan di semua perangkat klien milik Google
  • Dari sudut pandang tim red team yang mengembangkan malware untuk menghindari EDR, saya bisa bilang sistem EDR itu penting. Ungkapan “pemantauan endpoint berbasis rootkit” adalah deskripsi yang tidak akurat dan sering muncul dari kesalahpahaman di komunitas game
    Alat seperti ini memberikan perlindungan yang penting terhadap ancaman canggih dan benar-benar berhasil mendeteksinya. Jika pengujian melibatkan perangkat Windows, pekerjaan saya menjadi 90% lebih mudah ketika tidak ada EDR
    Ada juga EDR open source seperti OpenEDR, tetapi sudah usang dan kualitas telemetrinya buruk: https://github.com/ComodoSecurity/openedr. Mengumpulkan berbagai kode proof-of-concept dari GitHub untuk membuat EDR produksi itu tidak realistis dan tidak aman
    Sensor EDR itu sendiri menjadi target serangan. Dari sudut pandang penyerang, sering kali EDR adalah satu-satunya penghalang, jadi jika dibuat open source risikonya lebih besar: kontribusi berbahaya bisa memperlambat pengembangan atau menyisipkan kerentanan. Pengembangan sensor keamanan berlangsung di lingkungan yang sangat bermusuhan, di mana Anda tidak pernah benar-benar yakin siapa lawannya
    Kenyataannya justru hampir sebaliknya. Ada aturan heuristik malware open source seperti aturan deteksi Elastic Security: https://github.com/elastic/detection-rules. Elastic juga menyediakan EDR yang mencakup driver kernel, dan dari pengalaman saya itu lebih sulit untuk dilewati. Jika Anda membuat EDR tanpa driver di Windows, pekerjaan saya akan jadi lebih mudah
    Sensor EDR memang sudah “diaudit” oleh peneliti keamanan dan penyerang. Reverse engineering dan debugging terus dilakukan untuk mencari kelemahannya. Jika ditemukan masalah setingkat EDR yang langsung menerima dan mengeksekusi shellcode mode kernel, tentu itu akan dipublikasikan
  • Nilai yang diberikan CrowdStrike adalah pemeliharaan basis data signature dan kemampuan memantau kampanye serangan di seluruh dunia. Ini membutuhkan sumber daya besar yang sulit dimiliki proyek open source
    Jauh lebih kompleks daripada sekadar program pencarian hash
  • Keamanan pada dasarnya bukan produk yang bisa begitu saja dibeli atau dialihdayakan, tetapi realitasnya memang sudah jadi seperti ini

• Sulit memahami mengapa hal ini tidak tertangkap dalam deployment pengujian. Saya penasaran apa perbedaan yang membuat masalah ini hanya muncul saat didistribusikan ke dunia luar
  Sulit dipercaya bahwa ini tidak diuji sebelum deployment, dan perusahaan juga seharusnya memiliki lingkungan pengujian sebelum merilis komponen pihak ketiga. Gagal saat memasang paket selama pengembangan atau menimbulkan masalah itu hal yang umum, tetapi tidak ada yang menganggap baik untuk langsung memasukkannya ke lingkungan produksi tanpa pengujian. Saya tidak paham mengapa kasus ini berbeda

  • Dugaan saya, kemungkinan besar ada dua pipeline terpisah: satu untuk perubahan kode dan satu untuk file data
    Pada pipeline 1, pembaruan kode perangkat lunak mungkin diperlakukan sebagai perubahan penting dan melewati lingkungan nonproduksi serta pengujian kanari sebelum “versi” baru dirilis secara global
    Pada pipeline 2, pembaruan konten·kanal mungkin diperlakukan berbeda. Melalui jalur ini, kemungkinan hanya hal seperti signature malware baru yang didistribusikan, sehingga diasumsikan file baru itu adalah file data berformat standar yang tidak “dieksekusi” dan hanya dibaca
    Pipeline ini sendiri mungkin pada awalnya telah diuji dan dinilai bekerja memuaskan, tetapi tampaknya tidak ada tahap pengujian untuk memverifikasi integritas file data yang dihasilkan atau, yang lebih penting, memastikan file itu berjalan tanpa error saat didistribusikan ke versi perangkat lunak yang sedang digunakan terbaru
    Perangkat lunak agen yang setiap hari membaca file kanal kemungkinan telah diuji “secara menyeluruh” di pipeline 1 terhadap semua ukuran file data yang mungkin dan konten simulasi. Tentu saja file data yang salah seharusnya ditolak sebagai error
    Skenario pastinya kali ini mungkin adalah pipeline rusak di jalur kedua menghasilkan file data salah dengan bentuk yang tidak biasa, dan kasus spesifik itu mungkin tidak pernah dibayangkan atau diuji dalam pipeline pengembangan·pengujian·deployment versi perangkat lunak
    Jika ini benar, pelajarannya jelas. Bahkan untuk deployment khusus “data”, pengujian tetap wajib sebelum deployment skala besar, tidak peduli seberapa terstandarisasi dan stabil pipeline-nya. Biaya dan penundaan akan bertambah, tetapi itu harus diterima. Mirip dengan alasan orang sejak awal membayar untuk perangkat lunak “keamanan”
    Hal yang sama berlaku bagi pelanggan perusahaan; mereka juga harus menguji artefak deployment baru di area nonproduksi dari lingkungan TI mereka atau menerapkan deployment kanari sebelum mengizinkannya ke seluruh fleet produksi
  • Jika hanya melihat bukti terbatas yang ada saat ini, kemungkinan deployment ini diuji secara ekstensif tampak sangat rendah. Lebih masuk akal jika pembaruan definisi dikelola dengan longgar demi memenuhi SLA tertentu, lalu akhirnya meledak
    Ketika perusahaan itu mencoba masuk ke keamanan endpoint dan deteksi anomali jaringan, banyak calon pelanggan menuntut SLA 4 jam untuk berbagai jenis dan tingkat keparahan CVE. Artinya dibutuhkan insinyur keamanan on-call 24/7 dan pembuatan·deployment definisi dalam waktu kurang dari 4 jam, dan 4 jam itu berarti harus bisa didistribusikan ke 100% target
    Menulis dan mendistribusikan definisi berkualitas tinggi untuk zero-day dalam 4 jam saja sudah sulit, apalagi harus melewati pipeline pengujian, belum lagi menulis pengujian baru yang benar-benar mencakup kasus tersebut. Di bidang itu, hal seperti itu dianggap “normal”, jadi saya cepat menyerah. Tidak akan mengejutkan jika CS juga bekerja dengan cara serupa di sini
  • Ada kemungkinan deployment pengujian otomatis untuk pembaruan definisi tidak menjalankan konsumen definisi versi saat ini, melainkan hanya menjalankan versi lama yang tidak terdampak
  • Saya pernah melihat tempat yang memperlakukan rilis yang gagal hanya sebagai “bagian biasa dari rekayasa”. Semacam tidak ada yang sempurna
  • Sulit percaya bahwa sama sekali tidak ada pengujian. Mungkin signature virus diuji terhadap engine, tetapi artefak rilis akhirnya yaitu file .sys tidak diperiksa, dan saya penasaran apakah ada bug yang masuk pada tahap packaging
    Tetap saja itu buruk sekali, tetapi jika benar dirilis tanpa pengujian apa pun, itu adalah tingkat kelalaian yang benar-benar mengejutkan

• Hal yang tidak saya pahami justru bagian yang jauh kurang teknis tetapi lebih penting. Saya tidak mengerti mengapa radius dampaknya bisa sebesar ini
  Saya pernah melakukan deployment jauh lebih lambat, lengkap dengan pemantauan otomatis dan rollback, bahkan untuk layanan yang jauh kurang penting. Pertama dirilis ke beta tanpa traffic pelanggan, lalu jika tidak ada masalah didorong ke sebagian kecil fleet, kemudian persentase host yang menerima pembaruan dinaikkan perlahan
  Dengan cara ini, masalahnya pasti bisa dihentikan segera, dan saya kira ini praktik umum

  • Ini bukan pembaruan perangkat lunak, melainkan pembaruan basis data signature. Ini memang jenis hal yang harus didistribusikan secepat mungkin
    Saat Anda mengetahui virus baru, itu berarti virus tersebut sudah beredar di alam liar, jadi setiap menit penting. Anda tentu tidak ingin menundanya sehari lalu mengetahui server sudah dikompromikan 20 jam sebelumnya
  • Bahkan jika ada prosedur rilis kanari untuk pembaruan kode, pembaruan konfigurasi tampaknya berada di kanal terpisah
    Mungkin ada ekspektasi bahwa Anda tidak menginginkan perubahan yang berpotensi merusak, tetapi tetap menginginkan aturan deteksi virus terbaru terus masuk. Edge case yang terlewat adalah situasi ketika konfigurasi yang tidak diuji merusak kode yang sudah ada
    Sumbernya murni spekulasi, jadi jangan dikutip di artikel berita
  • Mengingat dampak insiden ini, mereka seharusnya memiliki lingkungan staging klien Windows yang besar untuk deployment awal
    Ada banyak cara untuk menghindari masalah ini atau setidaknya mengurangi risikonya, tetapi seperti biasa keuntungan didahulukan daripada manusia
  • Sepertinya mereka tidak benar-benar melakukan dogfooding terhadap perangkat lunak mereka sendiri. Mungkin bahkan di dalam perusahaan mereka sendiri pun perangkat lunak itu tidak dianggap terlalu berguna
  • Jawabannya ada di dalam thread ini. Sebagai perbandingan, saat bekerja di vendor AV, kami mendorong pembaruan sekitar 4 kali sehari ke basis pelanggan yang jauh lebih besar, jika angka yang dilaporkan MS benar

• Mengejutkan bahwa peran Microsoft hampir tidak dibahas dalam insiden ini. Microsoft memang bukan pihak yang bertanggung jawab atas bug yang langsung menyebabkan crash, tetapi Microsoft telah menciptakan lingkungan yang minim insentif—yakni keuntungan dan persaingan—untuk membuat Windows tahan menghadapi situasi seperti ini
  Microsoft pada dasarnya memiliki posisi monopoli di ranah komputasi workstation, dan kini posisinya nyaris seperti infrastruktur, sehingga punya kewajiban kehati-hatian untuk menjamin keamanan, keandalan, dan fungsi produknya
  Karena tidak ada persaingan, Microsoft berhenti mendorong inovasi Windows, dan sebagian di antaranya mungkin bisa mencegah gangguan kali ini. Misalnya, CrowdStrike berjalan di user space pada macOS dan Linux; apakah Windows tidak menyediakan kemampuan agar CrowdStrike bisa berjalan di user space?
  Bukankah inovasi sandboxing aplikasi juga bisa mengurangi kebutuhan akan tingkat kontrol yang diminta CrowdStrike?
  Microsoft pada praktiknya memegang kunci infrastruktur komputasi dunia hampir tanpa persaingan dan nyaris tanpa pengawasan. Windows dulu menyumbang lebih dari 80% pendapatan Microsoft, tetapi sekarang turun ke sekitar 10%
  Tidak masalah jika perusahaan swasta mengejar uang, tetapi jika produknya esensial bagi operasi rumah sakit, maskapai penerbangan, dan infrastruktur kritis, mereka tidak bisa hanya terpaku pada asisten AI dan iklan demi meningkatkan profitabilitas
  Microsoft telah gagal menjalankan kewajiban kehati-hatian terhadap konsumen, dan CrowdStrike menurut saya adalah gejalanya. Pemerintah harus serius mendorong persaingan di pasar desktop workspace, atau kalau tidak, mengatur produk Microsoft Windows

  • Benar. Ini kegagalan di banyak lini, dan pertanda pembusukan sistem yang sudah berlangsung puluhan tahun
    Satu sisi baik dari turunnya porsi pendapatan Windows adalah mungkin MS tidak lagi memperlakukannya sebagai wilayah suci yang tak boleh disentuh

• Saya tidak memakai CrowdStrike secara langsung, dan setahu saya juga belum pernah memasangnya di sistem saya. Sepertinya perangkat kerja terakhir saya menjalankan sesuatu yang mirip, jadi mohon koreksi kalau saya salah
  Driver CS dipasang lebih dulu dan tidak bisa dihapus, kemungkinan memantau apakah monitor jarak jauh mendeteksinya, dan tampaknya upaya besar dilakukan agar karena merupakan driver bertanda tangan, ia sulit dimodifikasi
  Namun driver itu memuat file data tanpa tanda tangan yang bisa dihapus oleh pengguna akhir sesuka hati? Apakah pengguna akhir juga bisa menambahkan file semacam ini sesuka hati agar driver berperilaku dengan cara yang seharusnya tidak boleh dilakukan?
  Saya penasaran apa yang mencegah pelaku jahat memakai file data berbahaya untuk memicu gangguan massal lain, atau lebih buruk lagi, mendapatkan hak akses kernel

  • File-file ini tidak bisa dihapus atau diubah pengguna, bahkan dengan hak administrator. Jika bisa, akan terlalu mudah mematikan antivirus
    Itu hanya mungkin jika file system dipasang dari sistem operasi lain, dan biasanya BitLocker mencegah hal itu

• Apakah pelanggan CrowdStrike punya hak bicara soal pembaruan seperti ini yang dirilis, atau mereka hanya menerima begitu saja bahwa CrowdStrike memiliki eksekusi kode jarak jauh penuh di semua mesin perusahaan
  Setidaknya orang-orang di bidang otoritas sertifikat dan kriptografi pasti ingin bisa mengecualikan hal seperti ini dari sistem mereka

  • Saya tidak tahu apakah ada cara untuk mengalihdayakan keamanan endpoint berkelanjutan ke pihak ketiga seperti CrowdStrike tanpa memberi mereka eksekusi kode jarak jauh dan hak ring 0 di semua endpoint yang harus dilindungi
    Justru otomatisasi bagian itu adalah inti dari produk CrowdStrike
  • Dalam masa hidup kita, akan ada pembaruan otomatis mobil swakemudi yang menewaskan jutaan orang
    Mungkin kita tidak akan sempat melihatnya. Bisa jadi kita termasuk salah satu dari jutaan itu
  • Pembaruan otomatis untuk “konten”, yaitu apa yang dianggap sebagai malware, memang wajib dan melewati opsi penundaan pembaruan: https://twitter.com/patrickwardle/status/1814367918425079934

• Saya penasaran apakah ada yang tahu apakah “channel file” ini ditandatangani dan diverifikasi oleh driver CS. Jika tidak, ini tampak seperti celah besar yang bisa berujung pada rootkit ring 0
  Memasang channel file mungkin memang butuh izin, tetapi begitu itu bisa dilakukan, ia dapat bersembunyi jauh lebih dalam di sistem. Jika channel file bisa menyebabkan segmentation fault, mungkin ia juga bisa melakukan lebih banyak hal
  Semua input yang masuk ke sesuatu yang berjalan dengan hak setinggi itu setidaknya harus melewati pemeriksaan integritas. Ini hal mendasar. Fakta bahwa channel file bisa dihapus saja sudah mengisyaratkan bahkan tidak ada mekanisme anti-tamper