Rust'in Güvenli Bellek Yönetiminin Sızıntıları: 11 Yıllık Bir Hata

0:00

/0

1×

Rust'in Güvenli Bellek Yönetiminin Sızıntıları: 11 Yıllık Bir Hata

Rust, güvenli bellek yönetimi konusunda dünyaca tanınan bir dildir. Derleyici, sahip olduğu borrow checker ile programlarda bellek tutuculuk hatası (memory safety) oluşmasını önler. Ancak bu güvenli dünyada, 11 yıl boyunca fark edilmeyen, kritik bir tip sistem sızıntısı (unsoundness) ortaya çıkmıştır. Bu hata, Rust'ın "saf" tip sistemini bozan ve geliştiricilerin bu tür zayıf noktalara dikkat etmesi gerektiğini gösteren bir olaydır.

Rust'ın Temel Vizyonu: Güvenli ve Hızlı Kod

Rust'ın amacı, C ve C++ gibi dillerde yaygın olan bellek hatasını (örneğin, "use-after-free", "dangling pointer") derleme aşamasında kalkan bir sistemle ortadan kaldırmaktır. Bunun için borrow checker adı verilen bir sistem kullanır. Bu sistem, bir değişkenin hangi süre boyunca sahip olabileceği ve hangi şekillerde erişilebileceği hakkında derleyiciye bilgi verir. Böylece, bellek yönetimi sorunsuzca yönetilir.

Ancak bir sorun var: Her sistem bile hata yapabilir. Rust'ın da bu güvenli sistem içinde bir sızıntı olduğunu gösteren bu 11 yıllık hata, bu fikri sorgulamamıza neden oluyor.

Hata Nedir? Nasıl Çalışıyor?

Bu hata, covariant field assignment (kavşak alan ataması) adı verilen bir yapıdan kaynaklanmaktadır. Kısaca, bir struct'ın alanına bir değer atandığında, derleyici bu atamayı düzgünce değerlendirmediği için, tip güvenliği bozuluyor.

Aşağıdaki örneği inceleyelim:

use std::sync::Mutex;

static KEPT: Mutex<Vec<Box<dyn std::any::Any + Send>>> = Mutex::new(Vec::new());

struct Q<T: 'static + Send>(Option<T>);

impl<T: 'static + Send> Drop for Q<T> {
    fn drop(&mut self) {
        if let Some(t) = self.0.take() {
            KEPT.lock().unwrap().push(Box::new(t));
        }
    }
}

fn main() {
    {
        let l = String::from("hello world, this is long enough");
        let mut q = Q(None);
        q.0 = Some(&l);  // ❌ Bu atama hatalı!
    }
    let _z = String::from("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX");
    let k = KEPT.lock().unwrap();
    println!("{}", k[0].downcast_ref::<&'static String>().unwrap());
}

Kod, derlenir ve çalışır. Ancak çıktı, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX olarak görünür. Bu, l değişkeninin geçerli bir bellek konumuyla değil, çöp değerlerle doldurulduğunu gösterir.

Neden Bu Kadar Uzun Süre Fark Edilmedi?

Bu hata, 1.18.0 sürümünden beri (2017) var. Ancak 11 yıl boyunca fark edilmedi. Bunun nedeni, bu sızıntının sadece bilinçli bir şekilde exploited (kullanıldığında) aktif olmasıdır. Yani, doğrudan bir bellek hatası yoktur. Ancak, Drop implementedan (Drop uygulamasından) bilinçli bir şekilde bir kötü amaçlı kod yazıldığında, sistem güvenliğini tamamen bozabilir.

Örneğin, bir struct'ın Drop fonksiyonu içinde, geçici bir referansı (&l) kalıcı hale getirip bir yere kaydetmek istenirse, sistem bu durumu doğru bir şekilde algılayamaz. Çünkü derleyici bu atamayı güvenli olarak kabul eder, oysa bu, tip güvenliğinin ihlalidir.

Geliştiriciler Ne Öğrenmeli?

Bu olay, geliştiricilerin Rust’ın tip sistemini kesinlikle tamamen güvenilir kabul etmemeleri gerektiğini gösterir. Rust, güvenli olmak için tasarlanmıştır, ancak geliştiricilerin bilinçli olması hâlâ kritik önem taşır.

Dikkat Edilmesi Gerekenler:

• Drop implementasyonları dikkatle yazılmalı: Özellikle Drop içinde bellek yönetimine müdahale eden kodlar, her zaman güvenli olmalıdır.
• Referansların yaşam süresi (lifetimes) sadece derleyici tarafından kontrol edilmez; geliştirici de bu süreçte bilinçli olmalıdır.
• 'static ve Send gibi sınırlamalar, sadece derleyici tarafından kabul edilir. Ancak, bu sınırlamaları kendi kodunuzda bilinçli bir şekilde kullanmalısınız.
• Dışarıdan gelen veriler ve güvenlik açıkları: Eğer bir yapı, dışarıdan gelen veri ile çalışıyorsa, bu verinin güvenli olup olmadığını kontrol etmek önemlidir.

Sonuç: Güvenlik, Sürekli Bir Süreç

Bu 11 yıllık hata, Rust’ın tip sistemine karşı bir sorun değil, aynı zamanda bir uyarıdır. Diller, programcılar tarafından yazılır. Geliştiriciler, dillerin sınırlarını bilmekle birlikte, bu sınırların kendileri tarafından zorlanabileceğini unutmamalıdır.

Rust’ın güvenliği, sadece derleyici ile değil, aynı zamanda geliştiricilerin bilinçli ve dikkatli olmasıyla sağlanır. Bu hata, hem Rust’ın gücünü hem de sınırlarını gösterir. Ve en önemlisi: sorunların fark edilmesi, bir sistem için en büyük başarıdır.

Bu olay, Rust’ın güvenli olduğu iddiasını çürütmüyor; aksine, bu güvenliğin sürekli bir geliştirme süreci olduğunu gösteriyor. Ve bu süreç, her geliştiricinin dikkatli olmasıyla devam ediyor.