Model ancaman dan fitur penilaian kerentanan di kernel. Linux

Linus Torvalds menyetujui sebuah dokumen untuk kernel yang menguraikan proses penanganan bug terkait keamanan, mendefinisikan model ancaman, mengklarifikasi bug kernel mana yang diperlakukan sebagai kerentanan, dan membahas cara menangani bug yang diidentifikasi menggunakan AI. Dokumen tersebut disiapkan oleh Willy Tarreau, penulis HAProxy dan pengembang kernel senior. Linux, bertanggung jawab untuk memelihara beberapa cabang kernel yang stabil. Kerangka kerja ini didasarkan pada kesepakatan yang dicapai selama diskusi tentang kerentanan kernel kritis yang baru diidentifikasi (1, 2, 3, 4) yang diungkapkan sebelum patch diterbitkan dan yang, berkat AI, eksploitasi yang berfungsi segera dibuat.

Sebagian besar bug terkait keamanan akan ditangani secara publik untuk menjangkau khalayak seluas mungkin dan menemukan solusi optimal. Milis pribadi terpisah akan digunakan hanya untuk mengirimkan laporan mendesak tentang kerentanan yang mudah dieksploitasi, menimbulkan ancaman bagi banyak pengguna, dan memungkinkan perolehan hak akses atau kemampuan yang lebih luas.

Kerentanan yang ditemukan menggunakan asisten AI selalu dianjurkan untuk didiskusikan secara publik, karena masalah tersebut sering kali ditemukan secara bersamaan oleh banyak peneliti. Namun, eksploitasi itu sendiri tidak perlu diungkapkan dalam laporan; cukup menyebutkan ketersediaannya dan membagikannya secara pribadi sebagai tanggapan atas permintaan pengelola sudah cukup.

Aturan untuk mengirimkan laporan yang dihasilkan oleh asisten AI dijelaskan secara terpisah. Laporan-laporan tersebut dikirimkan dalam jumlah besar dan terkadang membantu mengidentifikasi kesalahan di bagian kode yang kurang ditinjau, tetapi pengelola sering mengabaikannya karena kualitasnya yang rendah dan ketidakakuratannya. Persyaratan utama untuk laporan yang dihasilkan AI adalah:

  • Singkat, tanpa basa-basi, dan dengan inti serta detail penting yang dinyatakan di awal.
  • Hanya teks biasa tanpa tag Markdown atau hiasan.
  • Memahami model ancaman dan memberikan fakta yang dapat diverifikasi (misalnya, "bug tersebut memungkinkan setiap pengguna untuk mendapatkan CAP_NET_ADMIN") daripada spekulasi teoretis dan dugaan tentang konsekuensi dari kerentanan tersebut.
  • Sebelum mengirimkan laporan, pastikan untuk menguji secara menyeluruh fungsionalitas eksploitasi yang dihasilkan AI dan memastikan bahwa masalah tersebut dapat direproduksi.
  • Memanfaatkan AI untuk mengembangkan dan menguji solusi untuk masalah yang telah diidentifikasi.

Menurut statistik pengelola, sebagian besar laporan bug yang diajukan dengan kedok perbaikan kerentanan sebenarnya bukanlah kerentanan dan harus ditangani sebagai bug biasa. Sebuah model ancaman kernel telah dikembangkan untuk membedakan antara kerentanan dan bug biasa. LinuxDi antara kemampuan dan jaminan tersebut, pelanggaran terhadapnya dapat dianggap sebagai kerentanan:

  • Isolasi tingkat pengguna: akses file dibatasi untuk pemilik, memori proses tidak dapat diakses oleh pengguna lain, ptrace dinonaktifkan untuk proses lain, isolasi komunikasi IPC dan jaringan.
  • Perlindungan berbasis kemampuan: tanpa CAP_SYS_ADMIN Anda tidak dapat mengubah konfigurasi kernel, memori, atau status sistem; tanpa CAP_NET_ADMIN Anda tidak dapat mengubah pengaturan jaringan atau mencegat lalu lintas; tanpa CAP_SYS_PTRACE Anda tidak dapat memantau proses pengguna lain.
  • Namespace ID pengguna (CONFIG_USER_NS) memungkinkan pengguna tanpa hak istimewa untuk membuat lingkungan terisolasi mereka sendiri yang dari situ mereka tidak dapat memengaruhi namespace global, seperti mengubah waktu, memuat modul, atau memasang perangkat blok.
  • Antarmuka debugging (/proc/kmsg, perf, debugfs), yang melaluinya informasi rahasia dapat diakses, hanya dapat diakses setelah akses eksplisit diberikan oleh administrator.

Fitur yang tidak dianggap sebagai kerentanan:

  • Menggunakan cabang kernel yang sudah usang.
  • Bangun dengan opsi pengembang atau opsi pengurangan keamanan diaktifkan (misalnya CONFIG_NOMMU).
  • Mengatur pengaturan sysctl yang tidak aman, opsi baris perintah, hak akses sistem file, kemampuan, atau mengizinkan pengguna yang tidak memiliki hak istimewa untuk mengakses antarmuka yang memiliki hak istimewa (misalnya, akses tulis ke procfs dan debugfs).
  • Masalah pada fitur yang hanya ditujukan untuk pengembangan dan debugging kernel, seperti LOCKDEP, KASAN, dan FAULT_INJECTION, yang tidak dimaksudkan untuk diaktifkan dalam konfigurasi produksi.
  • Masalah pada driver, modul, dan subsistem yang berada di bagian STAGING atau ditandai sebagai eksperimental, tidak aman, atau rusak.
  • Menggunakan modul kernel pihak ketiga atau fork kernel tidak resmi.
  • Membutuhkan hak akses yang berlebihan, seperti mengharuskan tindakan dilakukan sebagai root atau oleh pengguna yang memiliki hak CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO, dan CAP_SYS_MODULE.
  • Serangan teoretis yang membutuhkan kondisi laboratorium, miliaran percobaan, emulasi atau modifikasi perangkat keras, biaya yang tidak proporsional, dan konfigurasi yang tidak realistis (misalnya, sistem dengan puluhan ribu inti CPU).
  • Melewati mekanisme keamanan (seperti ASLR) tanpa menunjukkan adanya celah keamanan. Kurangnya validasi argumen dan kode kesalahan yang tidak memiliki konsekuensi yang jelas.
  • Kebocoran informasi yang tidak disengaja di luar kendali penyerang, seperti data sisa dalam pesan kesalahan dan kebocoran alamat/penunjuk memori kernel tanpa eksploitasi langsung.
  • Kesalahan terjadi saat memasang citra disk yang rusak jika driver tidak dinyatakan cocok untuk digunakan dengan media yang tidak tepercaya. Masalah pada citra disk dapat dideteksi dan diperbaiki dengan menjalankan utilitas fsck.
  • Serangan yang memerlukan akses fisik ke perangkat keras, modifikasi perangkat keras, atau koneksi perangkat keras seperti papan serangan DMA dan penganalisis logika kecuali sistem dikonfigurasi secara khusus untuk melindungi terhadap serangan tersebut (IOMMU).
  • Masalah fungsionalitas dan performa yang menurun berhasil diatasi dengan menyesuaikan izin dan batasan.

Sumber: opennet.ru

Beli hosting yang andal untuk situs dengan perlindungan DDoS, server VPS VDS 🔥 Beli hosting website andal dengan perlindungan DDoS, server VPS VDS | ProHoster