Rust Borrow Checker'ında 11 Yıllık Bellek Güvenliği Açığı Bulundu

Rust programlama dilinin en temel güvenlik vaatlerinden biri, derleme zamanında bellek hatalarını önleyen güçlü tip sistemidir. Ancak derleyicinin merkezinde yer alan borrow checker (ödünç alma denetleyicisi) mekanizmasında, 11 yıldır fark edilmeden varlığını sürdüren kritik bir tip güvenliği açığı (unsoundness) keşfedildi. GitHub üzerinde #164250 numarasıyla açılan hata kaydında, bir veri yapısının (struct) yaşam süresi gereksinimlerinin kovaryant alan ataması yoluyla atlatılabildiği ve kapsam dışına çıkmış geçersiz belleğe güvenli kod içinden erişilebildiği ortaya kondu.

Hata Etiketleri ve Kapsamı#

GitHub üzerindeki hata kaydı, sorunun mimari boyutunu ortaya koyan 8 etiketle sınıflandırıldı:

• A-borrow-checker: Ödünç alma denetleyicisi alanı.
• A-destructors: Yıkıcı metotlar (Drop, vb.) alanı.
• A-lifetimes: Yaşam süreleri ve bellek bölgeleri alanı.
• A-variance: Alt tipleme ve varyans kuralları alanı.
• C-bug: Hata kategorisi.
• I-unsound: Dilin bellek ve tip güvenliğini bozan en kritik zafiyet türü.
• P-high: Yüksek öncelik seviyesi.
• T-types: İnceleme ve çözümden sorumlu Types ekibi.

Rust Ekibinin Açıklaması ve Arka Plan#

Types ekibinden @lcnr, toplulukta yankı uyandıran bu açığa dair şu önemli teknik bağlamı paylaştı:

• Bellek Güvenliği Taahhüdü: Rust tip sistemi bellek güvensizliğini önlemeyi taahhüt eder. Ekip; yeni nesil trait çözücü (next-generation trait solver), bölge kısıtlaması revizyonu (region constraint rework) ve Project Zero gibi temel projelerle bu temelleri güçlendirmektedir.
• Ekibin Önceliği: Tip sistemindeki tüm güvenlik açıklarını kapatmak ve bilinmeyen açıkları en aza indirecek sağlam bir temel kurmak ekibin en büyük önceliğidir.
• Öncelik Derecesi: Bu açık normal koşullarda "P-critical" sayılabilecekken, 11 yıldır fark edilmemiş olması ve günlük kullanımda tetiklenmesinin zorluğu nedeniyle "P-high" olarak derecelendirilmiştir.
• İstismar Şartı: Açığın kazara bellek hatasına yol açma olasılığı neredeyse yoktur; istismar edilebilmesi için kasıtlı olarak kötü niyetle yazılmış bir Drop implementasyonu gerekmektedir.

Kod Analizi ve Davranış#

Paylaşılan minimal örnekte, statik bir Mutex vektörü ve 'static kısıtına sahip jenerik bir Q<T> yapısı tanımlanmıştır. Yerel bir referans kovaryant alan atamasıyla yapıya geçirilmiş ve kapsam dışına çıkarılmıştır:

• Beklenen Davranış: Derleyicinin yaşam süresi ihlalini tespit edip kodu derlemeyi reddetmesi.
• Gerçekleşen Davranış: Kod sorunsuz derlenmekte, nesne yok edilirken geçersiz adres statik alana sızdırılmakta ve AddressSanitizer stack-use-after-scope çökmesi vermektedir.
• Meta Bilgisi: Sorun hem güncel nightly hem de mevcut kararlı (stable) sürümleri etkilemektedir.

Öğrenme ve Yazılım Geliştirme Açısından Çıkarımlar#

• Derleyici Garantileri ve Dinamik Testler: En katı tip sistemlerinde dahi varyans ve yaşam sürelerinin kesişiminde teorik açıklar kalabilir; bu yüzden AddressSanitizer gibi araçlar test süreçlerinde aktif tutulmalıdır.
• Drop Tasarımında Güvenlik: Yıkıcı fonksiyonlar içinde referansları kaçıran veya küresel durumlara aktaran yan etkilerden kesinlikle kaçınılmalıdır.