Apa itu SBAT dan mengapa tiba-tiba semua orang memperhatikannya

Definisi SBAT (Secure Boot Advanced Targeting)

• Saat UEFI Secure Boot pertama kali ditetapkan, semua pihak yang terlibat agak naif
• Model keamanan dasar Secure Boot adalah bahwa semua kode yang berjalan dalam lingkungan hak akses level kernel harus diverifikasi sebelum dijalankan
• Di dalamnya termasuk cara untuk mencabut komponen bertanda tangan yang ditemukan memiliki kerentanan
• Namun, semua distribusi Linux yang beroperasi dalam ekosistem Secure Boot membuat biner bootloader mereka sendiri, jadi ketika kerentanan teridentifikasi, ada banyak biner yang harus dicabut
• Karena ruang untuk menyimpan hash terbatas, SBAT pun dikembangkan

Cara kerja SBAT

• Semua komponen penting dalam rantai boot mendeklarasikan generasi keamanan yang disertakan di dalam biner bertanda tangan
• Jika kerentanan teridentifikasi dan diperbaiki, generasi tersebut akan dinaikkan
• Melalui pembaruan, generasi minimum dapat ditentukan
• Komponen boot memeriksa item berikutnya dalam rantai, lalu membandingkan nama dan nomor generasinya dengan yang disimpan dalam variabel firmware untuk menentukan apakah komponen itu boleh dijalankan
• Alih-alih mencabut banyak hash individual, satu pembaruan dapat didorong untuk menyatakan bahwa versi grub dengan generasi keamanan di bawah angka tertentu tidak lagi tepercaya

Penyebab isu terbaru

• Microsoft merilis pembaruan Windows agar versi grub dengan generasi keamanan di bawah tingkat tertentu tidak lagi dipercaya
• Ini karena versi grub tersebut memiliki kerentanan keamanan nyata yang dapat merusak rantai Secure Boot Windows
• Masalahnya adalah beberapa distribusi Linux belum menyediakan versi grub dengan versi keamanan baru
• Niat Microsoft adalah menerapkan pembaruan SBAT hanya pada sistem yang hanya memiliki Windows, tetapi ini tidak berjalan sesuai rencana

Ringkasan

• Microsoft mendorong pembaruan Windows agar versi grub yang rentan tidak bisa digunakan untuk menyerang Windows
• Pembaruan ini seharusnya tidak diterapkan pada sistem dual-boot, tetapi hal itu diabaikan
• Beberapa distribusi Linux belum memperbarui kode grub dan generasi keamanan SBAT
• Akibatnya, sebagian pengguna tidak dapat mem-boot sistem mereka

Siapa yang patut disalahkan

• Microsoft seharusnya melakukan lebih banyak pengujian agar dapat mengidentifikasi konfigurasi dual-boot dengan tepat
• Namun, distribusi yang menyediakan bootloader bertanda tangan juga harus memperbaruinya dan memperbarui generasi keamanannya
• Ini karena hal tersebut dapat menyediakan vektor yang bisa digunakan untuk menyerang sistem operasi lain

Kesimpulan

• Sangat disayangkan bahwa pengguna akhir yang tiba-tiba tidak bisa lagi mem-boot OS yang mereka inginkan menjadi korban
• Hal seperti ini seharusnya sama sekali tidak boleh terjadi
• Meski UEFI Secure Boot terasa tidak memberi manfaat bagi sebagian besar pengguna akhir, tetap tidak menyenangkan baru menyadari setelah kejadian bahwa fitur itu sebenarnya dibutuhkan, jadi saya bisa memahami pilihan Microsoft untuk mengaktifkannya secara default
• Selain upaya yang gagal untuk menghindari pembaruan pada sistem dual-boot, saya bisa memahami pilihan Microsoft

Opini GN⁺

• Insiden ini menunjukkan betapa sulitnya menyeimbangkan keamanan dan pengalaman pengguna
• Baik Microsoft maupun distribusi Linux berusaha sebaik mungkin untuk melindungi pengguna, tetapi dalam prosesnya pengalaman pengguna bisa dikorbankan
• Bagi pengguna yang memakai sistem dual-boot, kemungkinan menghadapi masalah seperti ini lebih tinggi
• Karena itu, penting bagi pengguna dual-boot untuk menjaga kedua sistem operasi tetap pada versi terbaru dan melakukan pembaruan secara berkala
• Dalam jangka panjang, tampaknya dibutuhkan kerja sama dan koordinasi yang lebih baik antara komunitas Linux dan Windows

[GN⁺]

Opini Hacker News

• Dalam episode Linux Unplugged terbaru, dibahas cara menggunakan TPM untuk membangun rantai kepercayaan pada proses boot Linux, dan itu sangat menarik dengan menggunakan Clevis
• Niat Microsoft tampaknya adalah agar Windows Update hanya menerapkan pembaruan SBAT pada sistem khusus Windows, sementara konfigurasi dual-boot tetap rentan sampai distribusi yang terpasang memperbarui grub dan mendistribusikan pembaruan SBAT sendiri
  • Jika membaca urutan boot EFI, seharusnya terlihat jelas bahwa shim harus di-boot lebih dulu, jadi saya penasaran apa yang sebenarnya salah
  • Saya juga penasaran apakah ini terjadi pada konfigurasi dual-boot di mana pengguna memilih Linux atau Windows melalui menu firmware
  • Ini tampak seperti perbaikan yang sah dari Microsoft, tetapi komunikasinya buruk
• Saya sangat tidak suka pesan galat saat pemeriksaan keamanan umum shim atau SB gagal; saya ingin diberi tahu apa tepatnya yang gagal dan bagaimana cara memperbaikinya
• Saya rasa salah satu alasan MS mewajibkan TPM2.0 dan memberlakukan pembaruan SBAT adalah karena adanya malware tingkat rootkit yang tersebar luas
• Soal realitas dual-boot, 10 tahun lalu di Win7/8/10 ada banyak masalah dengan suspend-to-hiberfile.sys dan pembaruan yang merusak grub
  • Sejak 10 tahun lalu saya memutuskan untuk hanya memakai Linux, dan bila perlu menggunakan VM atau komputer cadangan terpisah
  • Sejak itu saya berhasil menyiapkan Secure Boot pada distro, mempelajari cara menyetel performa dan passthrough QEMU, dan berhasil menjalankan VM macOS di QEMU
  • Harus memperbaruinya setiap beberapa bulan demi menjaga XCode tetap jalan memang merepotkan, tetapi secara keseluruhan saya puas
• Bukankah menonaktifkan Secure Boot adalah hal pertama yang dilakukan saat memasang Linux?
• Pertanyaan utamanya adalah apakah grub yang ditolak itu memang belum sepenuhnya ditambal, atau apakah distro menambalnya tanpa memperbarui "generasi keamanan"
  • Saya sangat penasaran bagaimana MS mencoba mendeteksi dual-boot, dan berharap ada seseorang (yang lebih ahli) yang melakukan reverse engineering terhadap bagian itu dari pembaruan tersebut
• Alasan Microsoft merusak sistem dual-boot adalah agar tidak menyediakan vektor untuk menyerang sistem operasi lain, dan itu merupakan pelanggaran terhadap kontrak sosial
• Saya penasaran apakah ini menghalangi penghapusan Windows dari sistem dan pemasangan Linux, atau apakah memasang Windows membuat modul TPM tercemar permanen
• Saya penasaran apakah grub bisa diperbarui dari Windows, atau cukup dengan menonaktifkan Secure Boot, mem-boot Linux, lalu melakukan upgrade dan mengaktifkannya kembali
• Sikap MS yang memblokir instalasi grub lama yang rentan tampak masuk akal, tetapi saya hanya memakai Windows untuk game dan satu perangkat lunak lawas, tanpa akses jaringan
  • Begitu Anda mengizinkan Windows Update, semuanya jadi soal keberuntungan
  • Fakta bahwa MS memindahkan registry key dan mempermainkan pengguna demi memaksakan "telemetri" (ML untuk pemindaian iklan dan data perilaku) sudah cukup menjelaskan banyak hal
  • Hal seperti ini juga terjadi di Windows Pro, dan saya memakai Win 10