Bellek güvenliği yol haritası, sahipleri ve tarihleri olan bir plandır ve C ile C++ kodunuzun büyük bölümüne dokunmadan bu çeyrekte yazabilirsiniz. Yeniden yazım daha sonra gelir ve yalnızca bunu hak eden parçaları kapsar. Şu an ihtiyacınız olan şey, güvensiz kodun nerede durduğuna dair net bir tablo, bu kodu sınırlamanın bir yolu ve ne karar verdiğinizin kaydıdır.
CISA'nın The Case for Memory Safe Roadmaps belgesi, yazılım üreticilerinin bellek güvenliği zafiyetlerini ortadan kaldırmak için bellek güvenli dillere (MSL) nasıl geçebileceğini anlatır. Belge, müşterilerin üreticilerin güvenlik sonuçlarını nasıl sahiplendiğini görebilmesi, radikal şeffaflığı uygulamaları ve yukarıdan aşağıya bir yaklaşım benimsemeleri için üreticilerden yol haritalarını yayımlamalarını ister. Bunlar Secure by Design ilkeleridir ve belge mühendislerin yanı sıra yöneticilere de hitap eder. İkinci kitle önemlidir: sponsorsuz bir yol haritası wiki'de kalır.
Kaynaklar neyi kapsıyor, neyi kapsamıyor
CISA özet sayfası yalnızca MSL'lere geçişten ve bir yol haritasının oluşturulup yayımlanmasından söz eder. Belgenin tam içeriğini göstermez, bu yüzden belgenin fuzzing veya süreç izolasyonu hakkında ne söylediğine dair bir iddiada bulunmuyoruz. Aşağıdaki bu iki adım, "bugün elimizde C++ var" ile "önemli parçalarda daha güvenli bir dilimiz var" arasındaki yıllar için kendi uygulamamızdır. Bunları geçici kontroller olarak ele alın, yol haritasının yerine koymayın.
Kaynaklar ayrıca hiçbir adımın ne kadar risk azalttığına dair rakam vermiyor. Biz de rakam uydurmayacağız. Bunu kendi çökme ve zafiyet geçmişinizden yola çıkarak kendiniz ölçün.
Adım 1: Güvensiz kodun envanterini çıkarın
Listelemediğiniz şeye öncelik veremezsiniz. Tabloyu repository bazında değil bileşen bazında hazırlayın, çünkü bir repository çoğu zaman dokunulmasa da olur bir yardımcı araçla bir ağ parser'ını bir arada barındırır.
| Alan | Neden önemli |
|---|---|
| Dil ve standart | Nelerin taşınıp nelerin taşınamayacağını gösterir |
| Dışarıdan erişilebilir mi? | Ağ, dosya, USB, seri port, güncelleme kanalı |
| Güvenilmeyen girdiyi işliyor mu? | Fuzzing ve yeniden yazım önceliğini belirler |
| Hangi yetkilerle çalışıyor? | İzolasyonun ne kadar fayda sağlayacağını belirler |
| Üçüncü taraf mı, bizim mi? | Kimin düzeltebileceğini belirler |
| Sahibi ve son esaslı değişiklik | Ölü kod çoğu zaman kaldırılabilir |
Vendored kütüphaneleri ve firmware bileşenlerini de ekleyin. Özellikle donanım ekiplerinde bootloader'larda, sürücülerde ve güncelleme işleyicilerinde yıllardır kimsenin açmadığı eski C kodu bulunur. Bu bileşenler tabloda yer almayı hak eder.
Adım 2: Henüz değiştiremediklerinizi izole edin
Dışarıdan erişilebilir olarak işaretlenen ve güvenilmeyen girdiyi işleyen her bileşen için, tamamen ele geçirilirse ne olacağını sorun. Cevap "her şey" ise, ilk tasarım değişikliğiniz budur. Parser'ı kendi sürecine taşıyın, yetkilerini düşürün ve ihtiyaç duymadığı dosyalara, soketlere ve anahtarlara erişimini kaldırın.
Bu, hatayı düzeltmez. Hatanın saldırgan için değerini sınırlar. Bu yaklaşım, NIST'in Secure Software Development Framework (SP 800-218) belgesindeki, henüz bulmadığınız zafiyetlerin istismar edilmesinin olası etkisini azaltma hedefiyle uyumludur.
Adım 3: Giriş noktalarına fuzzing uygulayın
Envanterinizde güvenilmeyen girdiyi işleyen bileşenleri alın ve her biri için bir fuzz harness yazın. Harness'ları CI içinde bir zaman bütçesiyle çalıştırın ve çökme corpus'unu saklayın. Önce dosya formatlarını, protokol mesajlarını ve güncelleme paketlerini seçin, çünkü dışarıdaki biri bu yollara erişebilir.
Fuzzing binary'lerini derleyicinin bellek hatası tespitini açarak derleyin, böylece sessiz bir overread görünür bir hataya dönüşür. Triyaj ettiğiniz her çökme, yol haritasının ihtiyaç duyduğu bir şeyi verir: hangi bileşenlerin yeniden yazımı hak ettiğine dair kanıt. Bir harness uzun süreli çalıştırmalardan sonra hiçbir şey bulamazsa, bu da işe yarar bilgidir ve o bileşeni listede daha aşağıya yerleştirmenizi sağlar.
Adım 4: Kısa bir yeniden yazım listesi seçin
Aday seçmek için ilk üç adımı kullanın. İyi bir ilk yeniden yazım adayının şu özellikleri vardır:
- Güvenilmeyen girdiyi işler.
- Arayüzü dardır, dolayısıyla aynı API'nin arkasında değiştirilebilir.
- Fuzzing sırasında çökme üretmiştir veya bir hata geçmişi vardır.
- Tek bir ekibin bir iki sürüm döngüsünde bitirebileceği kadar küçüktür.
Kararlı, dahili ve dışarıya açık olmayan kodu C veya C++ içinde bırakın ve bunu yol haritasında belirtin. Bir bileşenin yanına "planlanmadı, izole edildi, fuzzing uygulandı" yazmak dürüst bir tutumdur ve müşteriler bununla çalışabilir. Radikal şeffaflığa dair yorumumuz budur: duruşunuzu açıkça ifade edersiniz, her satırın yeniden yazımla bitmesi gerekmez. CISA özeti bu ilkeyi adlandırıyor ancak C veya C++ içinde kalan bileşenler için ne anlama geldiğini söylemiyor.
Yeni bileşenler başlamak için en ucuz yerdir. Ağa bakan yeni kodun hangi dili kullanacağına şimdi karar verin ve bunu mühendislik standartlarınıza yazın.
Adım 5: Yazıya dökün ve sürecinize bağlayın
NIST, SSDF'yi, zaten işlettiğiniz yazılım geliştirme yaşam döngüsüne entegre ettiğiniz, zafiyetlerin tekrarlanmaması için kök nedenleri ele almayı amaçlayan temel bir üst düzey uygulamalar kümesi olarak tanımlar. Bellek güvenliği kurallarınızı bu mevcut sürecin içine yerleştirin: yeni kod için dil seçimi, CI içinde fuzzing, güvensiz yapılar için bir inceleme kapısı. SSDF ayrıca satın alanlara ve tedarikçilere ortak bir söz dağarcığı sunar. Bu, bir müşterinin güvenlik anketi bellek güvenliğini sorduğunda işinize yarar.
Kodlama kontrol listeleri için OWASP Secure Coding Practices Quick Reference Guide projesi arşivlenmiştir. Kontrol listeleri OWASP Developer Guide içine taşınmıştır, bu yüzden eskimiş bir PDF yerine bu sürümü kullanın.
Nereden başlamalı
- Vendored ve firmware kodu dahil her C ve C++ bileşeninin listesini çıkarın ve yukarıdaki envanter tablosunu doldurun. Bunu iki haftayla sınırlayın.
- Güvenilmeyen girdi okuyan bileşenleri işaretleyin ve her birinin ele geçirilmesi durumunda nelere erişebildiğini listeleyin.
- Dışarıya en açık ilk üç bileşeni ayrı, düşük yetkili süreçlere taşıyın veya bu değişikliği adı belli bir sahiple planlayın.
- Aynı bileşenler için fuzz harness'ları yazın ve CI içinde çalıştırın. Çökmeleri haftalık olarak inceleyin.
- Bellek güvenli bir dilde yeniden yazım için bir bileşen seçin ve ağa bakan tüm yeni kod için bir dil kuralı belirleyin.
- Sahipleri ve tarihleri olan tek sayfalık bir dahili yol haritası yayımlayın, ardından müşterilerle nelerin paylaşılacağına karar verin. Dışarıdan bir doğrulama isterseniz, güvenli yazılım geliştirme hizmetimiz ve sızma testi envanteri inceleyebilir ve izole edilmiş bileşenleri test edebilir.
