Artık ‘Mavi Cuma’ yok

 (brendangregg.com)
1 puan yazan GN⁺ 2024-07-23 | 1 yorum | WhatsApp'ta paylaş
  • 19 Temmuz 2024’te dünya çapında yaşanan Windows kesintisi, bir güvenlik ürününün çekirdek sürücüsü güncellemesinin hatalı bellek okumasına yol açarak mavi ekranlara ve önyükleme döngülerine neden olduğu bir vakaydı
  • eBPF, çekirdek içinde çalışsa da doğrulayıcı ve sandbox ile tehlikeli kodu reddedecek, böylece tek bir programın tüm sistemi çökertmesini engelleyecek şekilde tasarlanmıştır
  • Linux’ta eBPF zaten mevcut; Microsoft’un eBPF for Windows’u üretime hazır hale geldiğinde Windows güvenlik yazılımları da aynı şekilde taşınabilir
  • Google, Meta, Cisco gibi büyük teknoloji şirketleri ve eBPF tabanlı güvenlik startup’ları; hız, derin görünürlük ve güvenlik garantilerinden yararlanarak güvenlik ürünlerini ve tespit sistemlerini ölçeklendiriyor
  • Çekirdek sürücüsü veya çekirdek modülü içeren ticari yazılım satın alan şirketler, Linux için şimdiden, Windows içinse yakında eBPF desteğini tedarikçi gereksinimi haline getirebilir

19 Temmuz Windows kesintisinin ortaya koyduğu çekirdek kodu riski

  • 19 Temmuz 2024’teki kesinti, çekirdek programlamanın doğasında bulunan riskleri gösteren benzeri görülmemiş bir örnekti
  • Dünya genelinde Windows bilgisayarları mavi ekran(blue screen of death) ve önyükleme döngüleri yaşadı; hastaneler, havayolları, bankalar, marketler ve yayın kuruluşlarında kesintiler meydana geldi
  • Neden, yaygın kullanılan bir güvenlik ürününün yapılandırma güncellemesi(config update) idi; söz konusu ürün Windows sistemleri için bir çekirdek sürücüsü içeriyordu
  • Güncellemeden sonra çekirdek sürücüsü hatalı belleği okumaya çalıştı; bu tür bir hata çekirdeği çökertebilir

eBPF’nin önleyebileceği çökmeler

  • eBPF artık bir kısaltma değil; web tarayıcılarına yerleşik güvenli JavaScript çalışma zamanına benzeyen güvenli bir çekirdek yürütme ortamıdır
  • Linux kullanıcılarının sistemlerinde eBPF bulunma ihtimali yüksektir; eBPF birkaç yıl önce Linux çekirdeğine dahil edildi
  • eBPF programları, tüm sistemi çökerteemeyecek şekilde sınırlandırılır
    • Yazılım doğrulayıcısı(verifier) güvenliği denetler
    • Programlar fiilen bir sandbox içinde çalışır
    • Doğrulayıcı güvenli olmayan kod bulursa program reddedilir ve çalıştırılmaz
  • Linux uygulamasındaki doğrulayıcı 20 binden fazla satır koddan oluşur; Meta, Isovalent, Google gibi sektörden ve Rutgers University, University of Washington gibi akademiden katkılar içerir
  • Güçlendirilmiş güvenlik, düşük kaynak kullanımı ve çökme önleme eBPF’nin temel avantajlarıdır

Linux ve Windows’ta uygulanabilirlik

  • Bu kesintiye neden olan güvenlik şirketi, Linux sistemlerinde zaten eBPF’ye geçiş sürecindeydi
  • Microsoft’un Windows için eBPF desteği üretime hazır hale geldiğinde Windows güvenlik yazılımları da eBPF’ye port edilebilir
  • eBPF’ye taşınan Windows güvenlik ajanı, Windows çekirdeğini çökerteemeyecek bir biçime dönüşür

Güvenlik sektörü ve büyük teknoloji şirketlerindeki benimsenme

  • eBPF tabanlı güvenlik startup’ları Oligo ve Uptycs, son kesintiyi eBPF’ye geçişin avantajlarını vurgulamak için bir fırsat olarak öne çıkardı
  • Büyük teknoloji şirketleri de güvenlik amaçlı eBPF’yi benimsiyor
    • Cisco, eBPF startup’ı Isovalent’i satın aldı ve güvenlik uygulama ve izleme için bir fabric olan Cisco Hypershield’ı duyurdu
    • Google ve Meta, eBPF’nin hızı, derin görünürlüğü ve güvenlik garantileri sayesinde büyük ölçekli ortamlarda kötü amaçlı davranışları tespit edip engelliyor
  • eBPF, güvenlik dışında ağ ve gözlemlenebilirlik(observability) için de kullanılıyor

eBPF’nin sınırları ve operasyonel tamamlayıcılar

  • Bir eBPF programının yapabileceği en kötü şey, CPU çevrimleri veya bellek gibi kaynakları istenmeyen düzeyde daha fazla tüketmektir
  • İsrafçı kodu tamamen engellemez, ancak sistem çökmesine yol açan ciddi sorunları önler
  • eBPF de yeni bir teknoloji olduğundan yönetim kodunda hatalar oldu; yakın zamanda haberlerde yer alan aynı güvenlik şirketinin keşfettiği Linux kernel panic vakası da var
  • Bu tür hatalar eBPF’de giderildiğinde düzeltme tüm eBPF tedarikçilerine uygulanır ve genel güvenlik daha hızlı iyileştirilebilir
  • Dağıtım riski yalnızca eBPF ile sona ermez; birlikte kullanılabilecek operasyonel teknikler hâlâ vardır
    • Canary testleri
    • Aşamalı rollout
    • Genel dayanıklılık mühendisliği

Satın alanların talep edebileceği değişim

  • eBPF yaklaşımının önemli yanı, hem Linux hem de Windows çekirdeklerinde yerleşik olarak sunulacak bir yazılım çözümü olması ve bu kullanım senaryosu için zaten benimsenmiş olmasıdır
  • Şirketler, çekirdek sürücüsü veya çekirdek modülü içeren ticari yazılımlar için ödeme yapıyorsa eBPF’yi bir gereksinim haline getirebilir
  • Linux’ta bu bugün mümkün, Windows’ta ise yakında mümkün olacak
  • Bazı tedarikçiler eBPF’yi zaten proaktif şekilde benimsedi; ancak diğer tedarikçiler için ödeme yapan müşterilerin talebi gerekebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-23
Hacker News yorumları

  • Windows için eBPF'nin sunduğu “hook” listesini görünce bunun gerçek dünyadan kopuk olduğu hissi doğuyor. Şu anda yalnızca gelen paketler ve soket işlemleri düzeyinde; yani Microsoft sanki Berkeley Packet Filter'ın kelimenin tam anlamıyla paket filtreleme için kullanılmasını bekliyor
    Bu, I/O filtreleme, nesne oluşturma/kullanımı ve CrowdStrike benzeri sürücülerin NT çekirdeğine bağlandığı sayısız noktayla aynı şey değil
    Ayrıca çekirdek alanında çalışan diğer üçüncü taraf çöplüklerini izlemek için anti-malware'in de çekirdeğin içinde olması gerekir. ELAM (early-launch anti-malware), anti-malware sürücüsünü önce yükleyip diğer sürücülerin davranışını izlemesini sağlar; eBPF ile bunun mümkün olacağı ise son derece şüpheli görünüyor
    Microsoft'un eBPF ile çekirdek alanı anti-malware sürücülerinin yerini alması için daha kat etmesi gereken çok yol var
    https://microsoft.github.io/ebpf-for-windows/ebpf__structs_8...

    • eBPF'nin Linux ile eşdeğer olaylara bağlanması gerektiği doğru, ancak Windows'ta zaten çok sayıda olay üreticisi ve tüketicisi var. Yapılması gereken şey, enstrümantasyon çerçevesini sıfırdan yeniden kurmak değil; eBPF'yi bir ek tüketici haline getirmek
      Benzetmek gerekirse, insanlar Google Chrome'un JavaScript'li web siteleri üzerinden bankacılık işlemlerini yaparken Microsoft Edge'in “JavaScript desteklemiyoruz, bunun yerine bu .EXE dosyasını indirip çalıştırın” demesi gibi. Soru, Microsoft'un JavaScript'i ya da eBPF'yi destekleyip desteklemeyeceği değil, bunu ne zaman destekleyeceğine daha yakın
    • Microsoft'un zaten mevcut antivirüslerin kullandığı genişletilebilir dosya sistemi filtresi özelliği var. Bunun üzerine eBPF eklemenin mantıklı olup olmadığını ve eğer mantıklıysa, dosya sistemi filtrelerinde görüldüğü gibi bir performans dezavantajı getirip getirmeyeceğini merak ediyorum
    • Bu olaydan sonra Microsoft'un Windows için eBPF desteğine daha güçlü yatırım yapmasını umuyorum

  • Brendan Gregg gibi biriyle tartışmak istemem ama bu alandaki satıcıların tüm arıza zincirini daha bütüncül biçimde incelemesini isterdim. Arıza yaşandıktan 3 gün sonra “x, y tarihinde yaşanan sorunu çözer” şeklinde bir öneri gelince temkinli yaklaşıyorum
    Doğru olabilir ama analiz yapılmazsa kör noktalar kalabilir ve inceledikten sonra yerinde biçimde elenmesi gereken çok sayıda alternatif de olabilir
    Özellikle “en kötü olumsuz sonucun sadece CPU israfı olması” kısmına katılmak zor. Belirli hata sınıfları için böyle olabilir ama yanlış bir kural kümesinin sistemi ciddi biçimde brick etmesine ve kurtarmayı zorlaştırmasına yol açabilecek yeterince çok arıza modu var
    Bunun anlamı, eBPF tabanlı güvenlik modüllerinin birçok satıcı için doğru seçim olmayabileceği değil; hangi risklerden kaçınıldığını, hangilerinden kaçınılamadığını ve arıza zincirinin hangi bölümünün ele alındığını anlamamız gerektiği

    • Bu konuya dair tartışmaların birkaç yıldır sürdüğünü bilmiyor olmanız, böyle tartışmaların hiç olmadığı anlamına gelmez. Bu, kazadan 3 gün sonra birden ortaya atılmış bir analiz değil; sistemlerin kararlılığını ve güvenliğini iyileştirmek için bu tür yeni API'leri devreye alan birçok uzmanın genel olarak benimsediği bir uzlaşıya daha yakın
    • Microsoft en az birkaç yıldır eBPF üzerinde çalışıyor
      https://opensource.microsoft.com/blog/2021/05/10/making-ebpf...
      https://lwn.net/Articles/857215/
      Gerçekten bir endişeniz varsa görüş bildirebileceğiniz tartışma kanalları da var ve bunlar GitHub'da derlenmiş durumda
      https://github.com/microsoft/ebpf-for-windows
      Yanıt zaten verilmiş olabilir; verilmediyse de orada ele alınabilir

  • Bu doğru değil. Eğer sistemin çalışması için belirli bir kod parçası gerekiyorsa, o kod bozulduğunda sistemin hiç çalışmaması gerekir. Başarısızlığı görmezden gelmek garip
    Örneğin bir tıbbi cihazın sürücü kodu insanları yakmamasını sağlayan bir güvenlik kilidini garanti ediyorsa, güvenlik kapalıyken normalmiş gibi çalışmasındansa her şeyin durmasını tercih ederim
    Sonuçta aşağı indikçe de aynı sorun devam ediyor

    • Ön kabulün kendisi yanlış gibi görünüyor. Hatalı girdi geldiğinde ne yapılacağına eBPF uygulayıcısı karar verebilir ve kernel bu durumda kontrollü kapanmayı seçebilir
      Linux'un gerçekte bunu nasıl yaptığını bilmiyorum ama hatalı girdiye verilecek tepkinin yapılandırılabildiği bir dünyayı hayal etmek mümkün
      Ayrıca bu ifade her zaman doğru değil. Genel durumda katılıyorum ama bazı bağlamlarda çalışmaya devam etmek gerekir. Aklıma ilk gelen örnek otomatik bir Mars iniş aracının yönlendirme bilgisayarı. Dünya ile gidiş-dönüş gecikmesi o kadar uzun ki sorumluluğu ertelemek mümkün değil
      Kapatırsan düşer; hasarlı halde elinden gelenin en iyisini yaparsa muhtemelen yine düşer, bu yüzden o seçenek daha iyi olabilir
    • Tıbbi cihaz yazılımı, kritik bir sürücü yüklenmediyse bir hata mesajı gösterip çalışmayı reddedebilir
      Tüm işletim sisteminin kullanılamaz hale gelmesi çok daha büyük bir sorundur çünkü bir BT teknisyeninin gelip bunu bizzat düzeltmesi gerekir. Aksi halde yalnızca hatalı sürücünün güncellenmesi yeterli olurdu
      Arabalar da silecek suyu yok diye çalışmaz hale gelmez
    • Bazı sistem bileşenlerinin mutlaka kritik sayılması gerektiğine katılıyorum ama bu olaydaki Falcon Sensor ya da genel olarak antivirüs önleyici nitelikte ve zaten best-effort karakterinde
      Cuma günü etkilenen kurumların çoğu, gerçekten yaşadıkları tam kapsamlı BT çöküşü yerine 24 saat boyunca kötü amaçlı yazılım saldırısı veya yetkisiz kullanım riskinin biraz artmasını tercih ederdi
      Üstelik bu hatanın mutlaka mavi ekrana yol açması da gerekmiyordu. Sistem tanımsız durumda ve sınırsız sonuç riskiyle çalışmayı sürdürebilirdi
      eBPF ile en azından mümkün olan bazı hatalar tespit edilebilir ve sonuca göre risk yönetimi kararı alınabilir
    • Bu yüzden Unison yaklaşımını seviyorum. Fonksiyonlar kriptografik hash ile çağrılıyor, dolayısıyla bugün çağrılanın dün çağrılanla aynı fonksiyon olduğuna dair bir güvence var
      Güncelleme için çağıranın farklı bir fonksiyonu çağırması gerekir; böylece sorumluluk, kerneli dolaylı yoldan kurcalayabilen kişide değil çağırandadır
      İşaret edilen hash'e karşılık gelen bir fonksiyon yoksa çağrılamaz; varsa da amaçlanan yol dışında çağrılamaz, böylece istenen “ya kusursuz çalışır ya da hiç çalışmaz” özelliği elde edilir
    • Sistem zaten başarısızlığı görmezden gelerek çalışıyordu. Çünkü fiilî düzeltme, sorunlu dosyayı basitçe silmekti. Bu bir seçenekse yükleyici de aynısını yapabilir, hatta “önceki sürüme geri dön” gibi daha akıllı davranabilir
      Ayrıca hatalı duruma verilen tepkinin illa “yok saymak” olması gerekmez. Kısıtlı kullanıcı girişleri devre dışı bırakılabilir veya ekran kapatılabilir
      Endişe bunun kötü amaçlı yazılımlar tarafından istismar edilmesi ise, kötü amaçlı yazılımın zaten antivirüsün disk üzerindeki dosyalarını değiştirebildiği bir durumda sistemin bunu kendi başına güvenle ele alabileceğine inanmanın ne kadar mantıklı olduğu şüpheli
      Üst güvenlik katmanına rapor vermek ve harici bir sistemin ağ erişimini kapatması veya kısıtlaması daha güvenli olabilir. Hatta böyle önlemler, sisteme müdahale etme yetkisi yerine yalnızca gözlem yetkisi gerektirdiğinden, antivirüs sisteminin kendisinin kötü amaçlı yazılım yolu ya da bu tür hataların kaynağı olma olasılığı da azalır

  • eBPF harika ve pek çok amaç için kullanılarak birçok şeyi iyileştirebilir, ancak “kötü bir yazılım güncellemesi yüzünden bilgisayar çökmeyecek” demek abartılı görünüyor
    BPF'nin kendisinde hata olmadığını varsaysak bile kernel hook'larının kapsamı oldukça geniş, bu hook'lar eBPF kodunu çağırıyor ve o kod da tekrar kerneli çağırabiliyor
    https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html
    Özellikle bpf_probe_read_kernel() çok yaygın kullanılıyor ama güvenli değil. OOPS ya da çökme olmaması için ciddi çaba var ama asla kusursuz değil
    Listenin geri kalanında da gerçekten oops ya da panic üretmese bile sistemi kolayca bozabilecek birçok şey var
    Ayrıca kullanıcı alanındaki “kötü davranışı” tespit edip engelleyen bir araçsa, her şeyi kötü niyetli sanmaya başlayıp bilgisayarı kullanılamaz hale getirebilir
    Öte yandan eBPF'nin kullanıcı alanı tarafında gerçek bir güvenlik modeli yok. eBPF programlarının fiilen eklenmesi, eklendikleri kernel nesnelerine dair makul bir yetki işlemiyle değil, bpf() sistem çağrısı üzerinden yapılıyor; ayrıca konteynerlerin kullandığı eBPF'yi o konteyner içinde tutacak bir mekanizma da yok. bpf_probe_read_kernel() özünde tüm kernel belleğini okuyabiliyor
    Dolayısıyla eBPF'nin sıradan kernel C koduna göre daha iyi yanı, sınırlı bir unsafe API yüzeyi olan güvenli bir dilde kod yazmaya benzemesi. Bu tür işler için büyük bir iyileşme ama kesinlikle kusursuz değil
    Doğrulayıcının katı olduğu ve Linux uygulamasının 20 bin satırı aştığı da söyleniyor, ama doğrulayıcı inanılmaz derecede karmaşık. Elle yazılmış 20 bin satırlık mantık yerine biçimsel yöntemler temelli bir yaklaşım görmeyi tercih ederim

    • bpf_probe_read_kernel ile panic üretmenin nasıl mümkün olduğunu merak ediyorum. Mevcut kernel sürümünde çalışan bir örnek verebilir misin?

  • “eBPF programları yazılım doğrulayıcı tarafından güvenlik kontrolünden geçirilip fiilen bir sandbox içinde çalıştırıldığı için tüm sistemi çökertemez” sözü şüpheli geliyor
    Bir işletim sisteminin amaçlarından biri yazılımı denetlemek değil mi? Bunun doğrudan işletim sisteminin kendisiyle ilgili bir sorun olduğunu biliyorum, ama denetleyeni denetleyen bir katman eklersen sonunda o katmanı da yeniden denetlemek gerekmez mi?
    Yeni karmaşıklığın uzun vadede daha iyi olacağına safça inanmak yerine karmaşıklığı azaltmayı seçemez miyiz?

    • eBPF, “denetleyeni denetlemek” değil; diğer araçların çok sıkı bir sandbox üzerinden çekirdeğin düşük seviyeli bileşenlerine erişmesini sağlayan bir araç
      Eski yöntem, kernel driver yüklemek, sayısız system call’a hook koymak ve bir şeylerin bozulmamasını ummak şeklindeydi. Hata yapılırsa panic yaşanabilir ama Linux oldukça sağlamdır
      eBPF yaklaşımı, istediğiniz bilgiyi eBPF’ye özgü komutlarla istemeye daha yakın
      Nasıl çalıştığına dair genel bakış burada: https://ebpf.io/what-is-ebpf/
    • Hatta CrowdStrike gibi bir şeyin kullanılmasının nasıl gerekçelendirildiğini bir yapay zeka sohbet botuna anlattırmak da ilginç olabilir

  • Kulağa harika bir teknoloji gibi geliyor ama gerçekten ciddi olan kısım, “kanarya testi, kademeli dağıtım, dayanıklılık mühendisliği gibi yazılım dağıtım riski azaltma yöntemleri de kullanılabilir” bölümü
    Temel sektör standardı kalite kontrolünü uygulamak için yeni teknolojiye ihtiyaç yok

  • Bu olayı anmak için cuma gününü tatil ilan etmeye başlayabiliriz sanırım. İnsanlar daha az baskıyla çalışıp işlerin nasıl geliştiğini ve bu akışı nasıl etkileyebileceklerini durup düşünmeye daha fazla zaman bulsaydı, zararın daha az olması mümkün olabilirdi

  • Linux uygulamasındaki doğrulayıcının 20 bin satırı aştığı ve sanayi ile akademiden katkılar aldığı açıklaması beni rahatlatmak yerine daha da huzursuz ediyor. Ek saldırı yüzeyi bir yana, bu kadar büyük bir kod tabanına kim kefil olabilir?

    • Ben de aynısını düşündüm. O 20 bin satır sayısının güven vermek için mi söylendiğini bilmiyorum ama bende tam tersi etki yarattı. 300 satır olsaydı daha çok güvenirdim
      WebAssembly doğrulayıcısı çok daha basitmiş gibi duruyor

  • Filtre açılışta yüklenip her şeye hook atıyorsa, tek bir hata sistemi ne yönetilebilir ne de yama uygulanabilir olacak kadar kilitleyebilir. Örneğin boş bir izin listesi yüklenmesi böyle bir durum yaratabilir; sonuçta boot loop’u başka bir hizmet reddi biçimine çevirmiş olur
    Microsoft, kurtarma için gerekli temel bileşenleri sabit kodlanmış bir izin listesine koyarsa bu tür araçlardaki hataları düzeltmek daha kolay olabilir, ancak düzeltme dağıtılana kadar sistem açık olsa bile kullanılamayan fiili bir kesinti yaşanabilir

  • Blog yazısında “eBPF bu tür çökmelere karşı bağışıktır” deniyor
    Aradım ama kesin bir bilgi bulamadım; hâlâ bir şeyleri bozmak mümkünmüş gibi görünüyor. Bir eBPF uzmanının bu iddiayı açıklamasını isterdim. Bulduğum en iyi kaynak şu oldu: https://stackoverflow.com/questions/70403212/why-is-ebpf-sai...

    • eBPF programları, eBPF doğrulayıcısında hata olmadığı varsayımıyla çekirdeği çökertemez. Geçmişte bu tür hatalar vardı ama giderek daha seyrek hale geliyor gibi görünüyor