SBAT nedir ve neden birden herkes bununla ilgilenmeye başladı?

SBAT(Secure Boot Advanced Targeting) tanımı

• UEFI Secure Boot ilk tanımlandığında, ilgili herkes biraz saf davranmıştı
• Secure Boot’un temel güvenlik modeli, çekirdek seviyesindeki ayrıcalık ortamında çalışan tüm kodların çalıştırılmadan önce doğrulanması gerektiğidir
• Buna, zafiyet bulunan imzalı bileşenlerin devre dışı bırakılmasına yönelik bir yöntem de dahildir
• Ancak Secure Boot ekosisteminde çalışan tüm Linux dağıtımları kendi önyükleyici ikililerini ürettiği için, bir zafiyet tespit edildiğinde geçersiz kılınması gereken çok sayıda ikili ortaya çıkıyor
• Hash saklamak için ayrılan alan sınırlı olduğundan SBAT geliştirildi

SBAT nasıl çalışır

• Önyükleme zincirindeki tüm kritik bileşenler, imzalı ikilinin içine gömülü bir güvenlik nesli bildirir
• Bir zafiyet tespit edilip düzeltildiğinde bu nesil artırılır
• Güncellemeler aracılığıyla asgari nesil tanımlanabilir
• Önyükleme bileşeni zincirdeki bir sonraki öğeye bakar, adını ve nesil numarasını ürün yazılımı değişkeninde saklanan değerle karşılaştırır ve çalıştırılıp çalıştırılmayacağına karar verir
• Çok sayıda ayrı hash’i geçersiz kılmak yerine, belirli bir numaranın altındaki güvenlik nesline sahip grub sürümlerinin güvenilmez olduğunu söyleyen tek bir güncelleme gönderilebilir

Son sorunun nedeni

• Microsoft, belirli bir seviyenin altındaki güvenlik nesline sahip grub sürümlerine güvenilmemesi için bir Windows güncellemesi yayımladı
• Bunun nedeni, söz konusu grub sürümlerinde Windows güvenli önyükleme zincirini bozabilecek gerçek bir güvenlik zafiyetinin bulunmasıydı
• Sorun şu ki bazı Linux dağıtımları hâlâ güvenlik sürümü yükseltilmiş yeni grub sürümlerini sunmamıştı
• Microsoft’un amacı SBAT güncellemesini yalnızca sadece Windows bulunan sistemlere uygulamaktı, ancak bu beklendiği gibi çalışmadı

Özet

• Microsoft, zafiyetli grub sürümleri kullanılarak Windows’a saldırılamaması için bir Windows güncellemesi dağıttı
• Bu güncellemenin çift önyüklemeli sistemlere uygulanmaması gerekiyordu, ancak bu dikkate alınmadı
• Bazı Linux dağıtımları grub kodunu ve SBAT güvenlik neslini güncellememişti
• Sonuç olarak bazı kullanıcılar sistemlerini önyükleyemez hâle geldi

Kimin suçu

• Microsoft, çift önyükleme yapılandırmalarını doğru şekilde tespit edebilmek için daha fazla test yapmalıydı
• Ancak imzalı önyükleyici sağlayan dağıtımların da bunları ve güvenlik neslini güncellemesi gerekiyordu
• Çünkü bu, başka işletim sistemlerine saldırmak için kullanılabilecek bir vektör sağlıyor

Sonuç

• Bir anda istediği işletim sistemini önyükleyemez hâle gelen son kullanıcıların mağdur olması üzücü
• Bu asla yaşanmaması gereken bir durum
• UEFI Secure Boot’un çoğu son kullanıcı için fayda sağlamadığını hissetsem de, ihtiyaç duyulan bir şeyi ancak olaydan sonra fark etmek de istenmeyen bir durum olduğundan, Microsoft’un bunu varsayılan olarak açık tutma tercihine katılıyorum
• Çift önyüklemeli sistemlerde güncellemeden kaçınmaya yönelik başarısız girişim dışında Microsoft’un tercihine katılıyorum

GN⁺ görüşü

• Bu olay, güvenlik ile kullanıcı deneyimi arasında denge kurmanın ne kadar zor olduğunu gösteriyor
• Microsoft ve Linux dağıtımları kullanıcıları korumak için ellerinden geleni yapıyor, ancak bu süreçte kullanıcı deneyimi zarar görebiliyor
• Çift önyüklemeli sistem kullanan kullanıcıların bu tür sorunlarla karşılaşma olasılığı daha yüksek
• Bu nedenle çift önyükleme kullanan kullanıcıların her iki işletim sistemini de güncel tutması ve düzenli olarak güncellemesi önem taşıyor
• Uzun vadede Linux ve Windows toplulukları arasında daha iyi iş birliği ve koordinasyona ihtiyaç olduğu görülüyor

[GN⁺]

Hacker News görüşleri

• Yakın tarihli bir Linux Unplugged bölümünde, Linux önyükleme sürecinin güven zincirini TPM kullanarak nasıl kurabileceklerini ele aldılar; Clevis ile oldukça ilginçti
• Microsoft'un niyeti, Windows Update'in SBAT güncellemesini yalnızca Windows'a özel sistemlere uygulaması ve çift önyükleme yapılandırmalarının, kurulu dağıtım grub'u güncelleyip SBAT güncellemesini kendisi dağıtana kadar savunmasız kalmasıydı
  • EFI önyükleme sırasını okuyunca, önce shim'in önyüklenmesi gerektiği açıkça yazıyor gibi görünüyor; neyin ters gittiğini merak ediyorum
  • Çift önyükleme kurulumlarında kullanıcıların ürün yazılımı menüsünü kullanarak Linux veya Windows'u seçtiği durum bu muydu diye merak ediyorum
  • Bu, Microsoft'un meşru bir düzeltmesi gibi görünüyor ama iletişim kötüydü
• shim veya SB'nin genel güvenlik denetimi başarısız olduğunda çıkan hata mesajlarından gerçekten nefret ediyorum; tam olarak neyin başarısız olduğunu ve bunun nasıl çözüleceğini söylemelerini isterdim
• MS'in TPM2.0'ı zorunlu kılmasının ve SBAT güncellemesini dayatmasının nedenlerinden birinin, yaygın rootkit seviyesinde kötü amaçlı yazılımın varlığı olduğunu düşünüyorum
• Çift önyüklemenin gerçekliği konusunda, 10 yıl önce Win7/8/10'da suspend-to-hiberfile.sys sorunu ve güncellemeler yüzünden grub'un bozulmasıyla ilgili çok sorun yaşanıyordu
  • 10 yıl önce yalnızca Linux kullanmaya karar verdim; gerekirse VM kullanıyor ya da ayrı bir yedek bilgisayar kullanıyorum
  • O zamandan beri dağıtımlarda Secure Boot'u başarıyla kurmayı, QEMU performansını ve passthrough'u ince ayarlamayı öğrendim, hatta bir QEMU macOS VM'ini çalıştırdım
  • XCode'u korumak için birkaç ayda bir güncellemek zorunda olmak can sıkıcı ama genel olarak memnunum
• Linux kurarken ilk yapılan şey Secure Boot'u devre dışı bırakmak değil mi?
• Asıl soru, reddedilen grub'un tamamen yamalanmamış olup olmadığı ya da dağıtımın "güvenlik neslini" güncellemeden yamalayıp yamalamadığı
  • MS'in çift önyüklemeyi algılamayı nasıl denediğini gerçekten çok merak ediyorum; umarım birileri (daha yetkin biri) güncellemedeki o kısmı tersine mühendislikle inceler
• Microsoft'un çift önyüklemeli sistemleri bozmasının nedeni, başka işletim sistemlerine saldırmak için bir vektör sağlamamak ve bu toplumsal sözleşmenin ihlalidir
• Bunun sistemi Windows'tan temizleyip Linux kurmaya engel olup olmadığını ya da Windows kurulunca TPM modülünün kalıcı olarak kirlenip kirlenmediğini merak ediyorum
• Windows içinden grub güncellenebilir mi, yoksa Secure Boot'u kapatıp Linux'u başlatmak, yükseltmeyi yapmak ve sonra tekrar etkinleştirmek yeterli mi diye merak ediyorum
• MS'in eski ve savunmasız grub kurulumlarını engelleme yönündeki tutumu makul görünüyor ama Windows'u yalnızca oyunlar ve tek bir eski yazılım parçası için kullanıyorum, onu da ağ erişimi olmadan
  • Windows Update'e izin verdiğiniz anda her şey şansa kalıyor
  • MS'in kayıt defteri anahtarlarını taşıması ve "telemetriyi" (reklamlar ve davranış verisi taraması için ML) zorla kabul ettirmek adına kullanıcılarla oyun oynaması yeterince şey anlatıyor
  • Bunlar Windows Pro'da da oluyor; ben Win 10 kullanıyorum