Chrome'da Bellek Güvenliği Ile Ilgili Bir Güncelleme (Google Security Blog Çevirisi)
Güvenlik, bir kedi-fare oyunu gibidir. Saldırganlar yenilikler yaptıkça, tarayıcıların bir adım önde olması için her zaman yeni savunmalar oluşturmaları gerekir. Chrome her zamankinden daha güçlü koruma alanlı ve site izolasyonu üzerine kurulu çok işlemli mimariye yatırım yaptı. Fuzzing(bulandırma) ile birleştirildiğinde, bunlar hala birincil savunma çizgilerimizdir, ama sınırlarına ulaşıyorlar ve vahşi saldırıları yenmek için artık yalnızca bu stratejiye güvenemeyiz.
Geçtiğimiz yıl ciddi güvenlik hatalarımızın %70’inden fazlasının bellek güvenliği problemleri olduğunu gösterdik. Bu hatalar C veya C++ dillerinde belleğin yanlış yorumlanmasına neden olan pointer(işaretçi) hatalarından kaynaklanıyordu.
Bu bir problem gibiydi! Ve kesinlikle bellek güvenliği, küresel yazılım mühendisliği topluluğu tarafından ciddiye alınması gereken bir konudur. Bu ayrıca bir fırsattır çünkü birçok hatanın aynı kökten gelen nedenleri vardır, yani hatalarımızın büyük bir kısmını tek adımda çözebiliriz.
Chrome, bu fırsatı değerlendirmek için üç geniş yolu araştırıyor:
1. Pointer’ların doğru olduğunu gösteren derleme-zamanı denetimleriyle C++’ı daha güvenli hale getirmek. 2. Pointer’ların doğru olduğunu gösteren çalışma zamanı denetimleriyle C++’ı daha güvenli hale getirmek. 3. Kodumuzun bölümleri için bellek güvenliği olan bir dil kullanımını araştırmak.
“Derleme zamanı kontrolleri” Chrome daha cihazınıza ulaşmadan önce, Chrome’un inşası sırasında güvenliğin garanti edildiği anlamına gelir. “Çalışma zamanı”, Chrome cihazınızda çalışırken kontroller yaptığımız anlamına gelir.
Çalışma zamanı denetimlerinin bir performans maliyeti vardır. Bir pointer’ın doğruluğunu kontrol etmek, bellek ve CPU zamanında sonsuz küçük bir maliyettir. Ancak milyonlarca pointer anlamına gelir. Ve Chrome performansı, birçoğu çok fazla belleğe sahip olmayan düşük güçlü mobil cihazlar kullanan milyarlarca kullanıcı için önemli olduğundan, bu kontrollerin artması web’in daha yavaş çalışmasına neden olur.
Ideal olarak, 1. seçeneği seçeriz - derleme zamanında C++’ı daha güvenli hale getiririz. Ne yazık ki dil bu şekilde tasarlanmamıştır. Bu alanda yaptığımız araştırma hakkında daha fazla bilgiyi Borrowing Trouble: The Difficulties Of A C++ Borrow-Checker‘da bulabilirsiniz.
Bu nedenle, çoğunlukla 2. ve 3. seçeneklerle baş başa kalıyoruz - C++’ı daha güvenli (ama daha yavaş!) hale getiren veya farklı bir dil kullanımına başlatan. Chrome Güvenliği, bu yaklaşımların her ikisini de deniyor.
MiraclePtr ve ABSL/STL modlarındaki gibi C++ güvenlik çözümlerinde büyük yatırımlar göreceksiniz. Her durumda, sömürülebilir güvenlik hatalarımızın önemli bir bölümünü ortadan kaldırmayı umuyoruz, ancak aynı zamanda bazı performans cezaları da bekliyoruz. Örneğin, MiraclePtr hala refere edilebilecek belleği karantinaya alarak kullanım sonrası kullanım hatalarını önler. Birçok mobil cihazda bellek çok değerlidir ve bir kısmını karantinaya almak zordur. Bununla birlikte, MiraclePtr tarayıcı sürecindeki kullan-ardından-bırak hatalarının %50’den fazlasını ortadan kaldırma şansına sahiptir - bu şu anda Chrome için muazzam bir kazanç.
Buna paralel olarak, gelecekte Chrome’un bazı bölümleri için bir güvenli bellek dili kullanıp kullanamayacağımızı araştıracağız. Bu diller arasında önde gelen rakip, Mozilla’daki arkadaşlarımız tarafından icat edilen Rust. Bu(büyük ölçüde) derleme zamanı için güvenlidir; yani, Rust derleyicisi, kod, cihazınıza ulaşmadan önce pointer’lardaki hataları tespit eder ve bu nedenle performans cezası olmaz. C++ ve Rust’ı birlikte yeterince iyi çalıştırıp çalıştıramayacağımıza dair açık sorular var. Rust’ta yarın yeni büyük bileşenler yazmaya başlasak bile, güvenlik açıklarının önemli bir bölümünü uzun yıllar ortadan kaldırmamız pek olası değildir. Ve mevcut bileşenlerin parçalarını Rust’ta yazabilmemiz için dil sınırını yeterince “temiz” yapabilir miyiz? Henüz bilmiyoruz. Chromium kaynak kod ağacına sınırlı, kullanıcıya yönelik olmayan Rust deneyleri eklemeye başladık, ancak bunu henüz Chrome’un üretim sürümlerinde kullanmıyoruz - deneysel bir aşamadayız.
Bu yüzden her iki stratejiyi de paralel olarak takip ediyoruz. C++’ı daha güvenli hale getirme maceralarımız ve Chrome’da yeni bir dil deneme çabalarımız hakkında güncellemeler için bu alanı izleyin.
Adresindeki metinden çevrilmiştir.