Retbleed saldırısı ya da Spectre’nin dönüşü

Temmuz ayının ortalarında Zürih’teki İsviçre Federal Teknoloji Enstitüsü araştırmacıları, modern işlemcilerdeki güvenlik açıklarını (ya da özellikleri) kötüye kullanan yeni bir saldırıyı anlatan bir çalışma yayınladı. Saldırıya Retbleed adı verildi. Bu isim, belirli bir tür Spectre saldırısına karşı bir savunma yöntemi olan Retpoline‘den geliyordu. Yazarlar temelde eskiden Spectre’nin ikinci varyantına karşı etkili bir koruma olduğu düşünülen program derleme tekniğinin yalnızca ara sıra çalıştığını, bazense hiç çalışmadığını göstermiş oldu. İşlemcilerdeki donanım güvenlik açıkları hakkındaki tüm diğer araştırmalar gibi bu araştırma da oldukça karmaşık. Her zaman yaptığımız gibi bu yazıda da ilgili bilimsel makalelerin labirentinde kaybolmadan sonuçları basit bir dille anlatmaya çalışacağız. Bazı temel arkaplan bilgileriyle başlayalım.

Spectre v2 nedir? Dallanma öngörüsünden bahsedelim

Dört yıldan daha uzun bir süre önce, 2018’in başlarında, Spectre ve Meltdown güvenlik açıklarını anlatan iki araştırma makalesi yayınlandı. Bunlar donanım güvenlik açıklarıydı, yani işlemcilerin çalışma biçimi dolayısıyla potansiyel bir veri hırsızlığı saldırısı mümkün hale geliyordu. O günden bu yana Spectre’nin birçok varyantı daha keşfedildi. Araştırmacılar ortak bir güvenlik açığı sınıfına saldırmanın, saldırı için işlemcinin “dallanma öngörüsü” denen varsayılan işlevini kullanmak gibi başka yollarını da buldu.

Dallanma öngörüsü ve talimatların spekülatif yürütülmesi, işlemci performansını önemli ölçüde geliştirmeye yardımcı olur. Tüm programlarda ileriki aşamaların yürütülmesi çoğunlukla önceki hesaplamaların sonucuna bağlıdır. En basit örnek olarak kullanıcının bazı gizli verilere erişmek için bir parola girmesini gösterebiliriz. Parola doğruysa veriler kullanıcıya gösterilir. Parola yanlışsa kullanıcıdan tekrar denemesi istenir. Basit CPU talimatları düzeyinde bu kabaca RAM’deki belirli verilere erişim haklarının kontrol edilmesine karşılık gelir: Gerekli haklar doğrulanırsa veriye erişim verilir, doğrulanmazsa erişim reddedilir.

İşlemci bu tür operasyonlardan saniyede milyarlarcasını gerçekleştirir ve belirli bir koşul kontrol edilirken çoğunlukla boşta kalır (çok geniş anlamda konuşursak kullanıcının parola girmesini veya erişim haklarının kontrol edilmesini beklerken). Peki ya boşta kalınan bu zamanı, yapılan kontrolün en olası sonucunun ardından yapılan hesaplamaları önceden yapmak için kullanırsak? Böylelikle varsayımsal kullanıcımız varsayımsal parolasını girdiğinde hesaplama sonucu hazır olur ve kullanıcı gizli verilere daha hızlı ulaşabilir.

Peki kodunuzun hangi kısmının yürütülme olasılığının en yüksek olduğunu nereden bileceksiniz? Elbette benzer talimatların önceki yürütülme istatistiklerinden! Eğer kullanıcımız, (lütfen bunun tamamen teorik ve aşırı derecede basitleştirilmiş bir örnek olduğunu unutmayın) on seferin dokuzunda doğru parolayı girdiyse gizli verileri önden hazırlayabiliriz. Parola yanlışsa sadece sonuçları göstermekten vazgeçeriz ve biraz daha uzun sürecek olsa da bir hata mesajı görüntüleriz.

2018’de yayınlanan makalenin yazarları Spectre saldırısının iki varyantından bahsediyordu. Dal Hedefi Ekleme olarak da bilinen İkinci Varyant, dallanma öngörüsünü, ihtiyaç duyduğumuz talimatları yerine getirecek şekilde eğitiyordu, yani saldırganın erişmemesi gereken verileri okuyabilmesini sağlıyordu. Evet, ardından bu hesaplamalar atılıyordu, ancak sonuçları (son derece hassas veriler) geçici olarak önbellekte saklanıyordu ve buradan çalınabiliyorlardı.

Bu çok karmaşık bir saldırı. Öncelikle saldırganın, istenen ayrıcalıklara sahip olmasa da, yani hassas verilere erişemese de, saldırı altındaki sistemde kod yürütebiliyor olması gerekiyor. Bunun için örneğin bir kullanıcı, tarayıcısında kötü amaçlı kod içeren bir web sayfasını açmaya ikna edilebilir. İkinci olarak saldırganın hedef sistemde saldırıya uygun kodu içeren bir yazılıma ihtiyacı var. Araştırmacı jargonunda buna “gadget” deniyor. Saldırı kodu, dallanma öngörüsü sistemini bu gadget’ı spekülatif olarak yürütecek şekilde eğitiyor. Böylelikle gadget, bellekte saldırganın erişemediği bir bölgeye erişebiliyor. CPU önbelleğindeki gizli veriler, yan kanaldan okunarak son derece yavaş bir şekilde (saniyede onlarca bit hızında) sızdırılabiliyor.

Daha da basit anlatmaya çalışalım. İşlemcinin yerleşik dallanma öngörüsü sistemi farklı programlardan gelen talimatları ayırmaz ve işlemcinin yürütmemesi gereken bir talimatı spekülatif olarak yürütmesini sağlamak için tek bir program kullanılabilir. Yazılımlar hiçbir koşulda işlemcinin önbelleğindeki verilere doğrudan erişemediği için daha önceleri bu durum bir sorun gibi görünmüyordu. Ancak sonradan yan kanalların okunmasıyla veri sızdırılabileceği ortaya çıktı (bu, yalnızca okunan taleplere verilen yanıtların hızıyla ilgili bilgilere dayalı olarak verilerin yeniden inşa edildiği çok karmaşık bir mekanizma).

Bir dakika. Spectre 2018’de keşfedildi. Herhalde şimdiye kadar yamalamışlardır, değil mi?

Donanım güvenlik açıklarında bu o kadar kolay değil. Birincisi ve en önemlisi, bu çok basitleştirilmiş açıklamadan bile anlaşılabileceği gibi, güvenlik açığı donanım tabanlı da olsa kötüye kullanılabilmesi için yazılımda da belirli koşulların bulunması gerekiyor. Öyleyse neden sadece yazılım için yama yayınlamasın? Bu, donanımı yükseltmekten çok daha kolay bir yol. Ayrıca mikrokod güncellemeleriyle işlemcilerdeki güvenlik açığını da kısmen onarmak mümkün. Ancak kesin sonuç yalnızca değiştirilmiş donanıma sahip yeni işlemcilerin çıkarılmasında yatıyor. Bu sırada eski modeller tamamen veya kısmen tehdide açık halde kalıyor.

Retbleed araştırması bağlamında çok önemli başka bir soru daha var. Bir yazılım ya da donanım yamasının maliyeti ne olur? Spectre’yi “kapatmanın” her yolu performansı düşürüyor. Örneğin, çok açık olan Dolaylı Dal Kısıtlı Spekülasyon (IBRS) sistemi spekülatif kod yürütme sırasında ilave izin kontrolleri getirerek düşük ayrıcalıklı programların çok hassas verilere erişmesini önlüyor ve bir Spectre saldırısını imkansız hale getiriyor. Fakat bu kontrollerden yüz binlercesi veya milyonlarcası gerçekleştiğinde CPU performansı ister istemez düşüyor. Peki ne kadar düşüyor? Spectre’ye yönelik çeşitli bir dizi yamanın bir sistemde %25’e kadar performans düşüşüne yol açtığını gösteren araştırmalar var.

Bu noktada Spectre’ye karşı Google mühendisleri tarafından ortaya atılan ve yazılım derlemesi sırasında kullanılan görece basit bir koruma yöntemi olan Retpoline devreye giriyor. Yöntemin yazarları tarafından ileri sürüldüğü üzere, tipik dallanma durumlarında bazı talimatları başka talimatlarla değiştirmek yazılımın çalıştırılmasını etkilemese de bir Spectre saldırısını imkansız hale getiriyor. Retpoline’in IBRS’e ve diğer koruma yöntemlerine göre önemli bir avantajı, performansın %5’ten fazla düşmemesi.

Retbleed çalışması neyi gösterdi?

Temelde bu yeni araştırma Retpoline’in işe yaramadığını gösterdi! Retpoline yönteminin bel bağladığı geri dönen talimatlar da biraz değiştirilmiş bir şekilde dallanma öngörüsünü kandırmak (veya kötü amaçlı olarak eğitmek) için kötüye kullanılabiliyor. Yazarlar saldırıyı gösteren bir video bile kaydetmiş:

Linux tabanlı bir sistemdeki Retbleed saldırısı demosu.

Bu video, karma bir süper kullanıcı parolasının nasıl bu tür verilere erişimi olmayan bir program tarafından çalındığını gösteriyor. Videonun hızlandırılmış olduğunu unutmayın, Intel tabanlı bir sistemde parola hırsızlığı gerçek zamanlı olarak en az bir buçuk saat alır! Sonuçlar aşağıdaki tabloda özetlenmiş:

Retpoline koruması etkinleştirilmişken Retbleed saldırısı olasılığına karşı test edilen işlemcilerin özet listesi. Kaynak

Tabloda da görüldüğü gibi, tamamen yeni olmasa da güncel olan AMD Zen 1 ve Zen 2 (2017–2019) ile Intel’in Kaby Lake ve Coffee Lake (2016–2017) işlemcileri Retbleed saldırısına yatkın. Daha modern AMD Zen 3 işlemcilerde ve Intel Alder Lake ile daha eski 9. nesil işlemcilerde Retbleed saldırısı çalışmıyor. Bu da Intel işlemcilerde Arttırılmış IBRS donanım koruması uygulanmasıyla ilgili.

Koruma maliyeti

Bir Spectre saldırısını gerçekleştirmek bu kadar zorsa neden buna karşı savunma oluşturalım? Evet, gerçek dünyada (kurbana gerçekten zarar veren) bir Spectre saldırısı yürütmek için saldırılan sistemde kod yürütebilmek, saldırıya yatkın yazılımların yüklü olması ve verileri önbellekten güvenilir şekilde sızdırabilmek (hatalı okuma kesinlikle bir risk) gibi birçok koşulun bir arada bulunması gerekiyor. Daha önce en gerçekçi saldırının bir Chrome tarayıcıda simüle edildiğini yazmıştık. Burada potansiyel bir saldırgan, örneğin kayıtlı parolaları RAM’den sızdırabiliyordu. Fakat bu durum, tıpkı diğer küçük hatalarda olduğu gibi, tarayıcının kendisinde basit bir koruma yükseltmesi yapılarak çözüldü.

Spectre gibi güvenlik açıklarının araştırılmasında kaydedilen ilerlemenin günün birinde kullanıcı bilgisayarlarına ve sunucularına yönelik kitlesel bir saldırıya yol açma olasılığı var. Ancak gerçekten hassas veriler sözkonusuysa Spectre’nin hemen dikkate alınması gerekiyor.

En bariz senaryo, barındırma ve dağıtılmış bilgi işlem sağlayıcıları üzerinden gerçekleştirilecek bir saldırı. Makul fiyata herhangi bir sağlayıcıdan kiralayabileceğiniz tipik bir sanal sunucu, temelde aynı yüksek güçlü sunucuda, diğer müşterilerin sanal işletim sistemlerinin yanında çalışan bir programdır. Bir sanal sunucu abonesi, işin tanımı gereği burada programlar çalıştırabilir fakat komşularına ya da ana bilgisayara, yani kontrol eden işletim sistemine erişim ayrıcalığına sahip değildir. Sanal ortamların ayrılması ve kendi sanal alanınızdan çıkamamanız, bu tür servis sağlayıcılar için en önemli güvenlik gerekliliklerinden biridir.

Servis sağlayıcılar aynı zamanda aynı sunucuda birbirine problem yaratmadan mümkün olan en fazla sayıda sanal sistemin çalışmasını da isterler. Bu, pahalı donanımların kendini finanse edebilmesi için kilit önem taşır. Bununla birlikte, (gerçekten çalışan) tüm Spectre yamaları performansı, dolayısıyla ISP kazancını düşürür. Ancak sağlayıcılar problemi görmezden de gelemezler. Çünkü hassas verilerin başarıyla çalınması geride bir iz bile bırakmaz.

Bu yüzden Retpoline ortaya atıldığında herkes bu çözümü havada kaptı. Fakat 2018’in Ocak ayına gelindiğinde bu savunma yönteminin ne kadar güvenilir olduğuna dair şüpheler belirmeye başladı. Linux çekirdek geliştiricilerinin e-posta listesindeki bir tartışma, Retpoline hakkında çok sayıda şikayet olduğunu gösteriyor (yazar diğer yöntemlere de pek sıcak bakmamış). Aynı dönemde, Linux’un yaratıcısı ve baş sorumlusu Linus Torvalds ise (her zamanki keskin tavrıyla) Retpoline’in genel olarak yeterli olduğunu net şekilde ifade etti.

Retbleed’in yazarları, Torvalds’ın kategorik alıntısını makalenin başına yerleştirerek yargılayıcı tavrını vurguladı. Yazarlar ayrıca gerçek dünyada güvenlik açığı bulunan ve donanım düzeyinde onarılamayan işlemcilere yönelik bir korumanın “maliyetini” de hesapladı. Linux çekirdeğindeki yamalar, Intel işlemcilerde %39’a kadar, AMD işlemcilerde ise %14’e kadar performans düşüşüne yol açıyordu.

AMD işlemcilerin kendilerine özgü bir güvenlik açığı olduğu da ortaya çıktı; araştırmacılar “Phantom JMP” adını verdikleri yeni bir fenomen keşfetti. Belirli koşullarda, saldırı altındaki kodda bulunmasa bile, bir dallanma öngörüsü sistemine rastgele bir talimat yürüttürmenin mümkün olduğu anlaşıldı. Bu yüzden yazarlar çalışmaya bir sayfalık kısa bir ek yayınlamak zorunda kaldı. Bununla birlikte, bu güvenlik açığını kötüye kullanarak gerçek bir zarara yol açmanın geleneksel Spectre V2’den bile daha zor olduğunu da belirttiler.

Şimdi ne olacak?

Sıradan kullanıcılar için Spectre saldırıları tamamen sanal bir durum olarak kalmaya devam ediyor. İşletim sistemi geliştiricilerinin yayınladığı önleyici yamalar yeterli. Bu arada Windows’ta, etkili IBRS koruması varsayılan olarak etkin geliyor. Yeni Linux çekirdek yamaları büyük olasılıkla performans düşüşüne yol açacak. Bu en çok bilgisayar donanımlarının sonuna kadar zorlandığı iş çözümlerinde belirgin olabilir.

Birçok Spectre varyantının olması, sorunu daha da karmaşık hale getiriyor. Retbleed de farklı üreticilerin işlemcilerinde farklı şekilde çalışan ayrı bir varyant olarak ele alınabilir. AMD ve Intel, Retbleed’i ayrı bir güvenlik açığı olarak tanıdı ve büyük olasılıkla buna yönelik bir donanım çözümü bulacaklar. Şirketler, koruyucu önlemlerin uygulandığı yeni donanımlara geçerek performans ve güvenlik arasında bir denge kuracak. Ne yazık ki tüm yazılım yamaları en çok görece daha eski işlemcileri etkiliyor. Yazılım zamanla daha zorlayıcı hale gelmekle kalmıyor, aynı zamanda spekülatif yürütme de bahsettiğimiz türde bir “cezayla” karşılaşıyor.

Soruna kuş bakışı baktığımızda yeni bir şey olmadığını görüyoruz. Geliştiriciler, güvenliği düşünmeden performansı arttıracak bir çözüm sunuyor. Er ya da geç (bu durumda geç, çünkü spekülatif yürütme 1990’ların ortalarında başladı) bu durum herkesin başına bela oluyor. Güvenlik önlemleri bir takım şeylere mal oluyor, eninde sonunda yeni çözümler bulunuyor ve yüksek teknoloji endüstrisi yoluna devam ediyor.

Buradaki sürpriz, sorunun donanımda olduğunun keşfedilmesi oldu. Donanımdaki sorunları çözmek yazılımdakileri çözmek kadar kolay değil. Üstelik bu basit bir hata da değil; endüstri tarafından uzun yıllar önce benimsenmiş (güvenlik açısından) yetersiz bir yaklaşım. Umuyoruz ki işlemci geliştiriciler, herkesi tehdit eden, geniş kitlelerce bilinen ve yalnızca donanımı tamamen değiştirerek çözülebilen çok tehlikeli bir donanım saldırısı riski ortaya çıkmadan önce güvenli ve güçlü bilgi işleme yönelik yeni yöntemler bulabilir.