Sertifikaları işlerken Mozilla NSS'de kod yürütme güvenlik açığı

Mozilla tarafından geliştirilen NSS (Ağ Güvenliği Hizmetleri) şifreleme kitaplıkları setinde, DSA veya RSA-PSS dijital imzaları kullanılarak belirtilen DSA veya RSA-PSS dijital imzalarını işlerken saldırgan kodunun yürütülmesine yol açabilecek kritik bir güvenlik açığı (CVE-2021-43527) belirlendi. DER kodlama yöntemi ( Ayırt Edici Kodlama Kuralları). BigSig kod adı verilen sorun, NSS 3.73 ve NSS ESR 3.68.1'de çözüldü. Dağıtımlardaki paket güncellemeleri Debian, RHEL, Ubuntu, SUSE, Arch Linux, Gentoo, FreeBSD için mevcuttur. Fedora için henüz bir güncelleme mevcut değil.

Sorun, CMS, S/MIME, PKCS #7 ve PKCS #12 dijital imzalarını işlemek için NSS kullanan uygulamalarda veya TLS, X.509, OCSP ve CRL uygulamalarında sertifikaları doğrularken ortaya çıkar. Güvenlik açığı, TLS, DTLS ve S/MIME'yi destekleyen çeşitli istemci ve sunucu uygulamalarında, e-posta istemcilerinde ve dijital imzaları doğrulamak için NSS CERT_VerifyCertificate() çağrısını kullanan PDF görüntüleyicilerinde ortaya çıkabilir.

LibreOffice, Evolution ve Evince, savunmasız uygulamalara örnek olarak gösteriliyor. Sorun potansiyel olarak Pidgin, Apache OpenOffice, Suricata, Curl, Chrony, Red Hat Directory Server, Red Hat Sertifika Sistemi, Apache http sunucusu için mod_nss, Oracle Communications Messaging Server, Oracle Directory Server Enterprise Edition gibi projeleri de etkileyebilir. Ancak güvenlik açığı, doğrulama için yine NSS'de bulunan ayrı bir mozilla::pkix kitaplığı kullanan Firefox, Thunderbird ve Tor Tarayıcı'da görünmüyor. 2015 yılına kadar NSS kullanan ancak daha sonra BoringSSL'ye geçen Chromium tabanlı tarayıcılar da (NSS ile özel olarak oluşturulmadıkları sürece) sorundan etkilenmemektedir.

Güvenlik açığı, secvfy.c dosyasındaki vfy_CreateContext işlevindeki sertifika doğrulama kodundaki bir hatadan kaynaklanmaktadır. Hata, hem istemci sunucudan bir sertifika okuduğunda hem de sunucu istemci sertifikalarını işlediğinde ortaya çıkar. DER kodlu bir dijital imza doğrulanırken NSS, imzanın kodunu sabit boyutlu bir ara belleğe çözer ve arabelleği PKCS #11 modülüne aktarır. Daha sonraki işlemler sırasında boyut, DSA ve RSA-PSS imzaları için yanlış bir şekilde kontrol edilir; bu, dijital imzanın boyutu 16384 bit'i aşarsa (arabellek için 2048 bayt ayrılmıştır, ancak VFYContextStr yapısı için ayrılan arabelleğin taşmasına neden olur, ancak imzanın daha büyük olabileceği kontrol edilmez) ).

Güvenlik açığını içeren kodun izi 2003 yılına kadar uzanabiliyor ancak 2012 yılında yeniden düzenleme yapılana kadar bir tehdit oluşturmuyordu. 2017 yılında RSA-PSS desteği uygulanırken aynı hata yapıldı. Bir saldırı gerçekleştirmek için, gerekli verileri elde etmek için kaynak yoğun belirli anahtarların oluşturulması gerekli değildir, çünkü taşma, dijital imzanın doğruluğunun kontrol edilmesinden önceki aşamada meydana gelir. Verilerin sınırların ötesine geçen kısmı, çalışan istismarların oluşturulmasını kolaylaştıran, işlevlere yönelik işaretçileri içeren bir bellek alanına yazılır.

Güvenlik açığı, Google Project Zero'daki araştırmacılar tarafından yeni fuzzing test yöntemleriyle denemeler sırasında keşfedildi ve yaygın olarak test edilen, iyi bilinen bir projede önemsiz güvenlik açıklarının uzun süre nasıl tespit edilemeyeceğinin iyi bir göstergesi:

  • NSS kodu, en son teknolojiye sahip test ve hata analizi teknikleri kullanılarak deneyimli bir güvenlik ekibi tarafından korunur. NSS'deki güvenlik açıklarını tespit etmek için önemli ödüller ödeyen çeşitli programlar bulunmaktadır.
  • NSS, Google'ın oss-fuzz girişimine katılan ilk projelerden biriydi ve aynı zamanda Mozilla'nın libFuzzer tabanlı fuzz test sisteminde de test edildi.
  • Kütüphane kodu, 2008'den bu yana Coverity hizmeti tarafından izlenmek de dahil olmak üzere çeşitli statik analizörlerde birçok kez kontrol edilmiştir.
  • 2015 yılına kadar NSS, Google Chrome'da kullanıldı ve Mozilla'dan bağımsız olarak Google ekibi tarafından bağımsız olarak doğrulandı (2015'ten beri Chrome BoringSSL'ye geçti, ancak NSS tabanlı bağlantı noktası desteği devam ediyor).

Sorunun uzun süre tespit edilememesinden kaynaklanan ana sorunlar:

  • NSS modüler kütüphanesi ve bulanıklaştırma testleri bir bütün olarak değil, bireysel bileşenler düzeyinde gerçekleştirildi. Örneğin, DER kodunu çözme ve sertifikaları işleme kodu ayrı ayrı kontrol edildi - fuzzing sırasında, söz konusu güvenlik açığının ortaya çıkmasına yol açacak bir sertifika elde edilmiş olabilir, ancak kontrolü doğrulama koduna ulaşmadı ve sorun ortaya çıkmadı. kendini açığa vur.
  • Bulanıklaştırma testi sırasında, NSS'de benzer kısıtlamaların yokluğunda çıktı boyutuna (10000 bayt) katı kısıtlamalar getirildi (normal moddaki birçok yapının boyutu 10000 bayttan fazla olabilir, bu nedenle sorunları tanımlamak için daha fazla giriş verisi gerekiyordu) . Tam doğrulama için sınırın 224-1 bayt (16 MB) olması gerekir; bu, TLS'de izin verilen maksimum sertifika boyutuna karşılık gelir.
  • Fuzz testi kod kapsamı hakkında yanlış kanı. Güvenlik açığı bulunan kod, gerekli giriş verilerini oluşturamayan fuzzer'lar kullanılarak aktif olarak test edildi. Örneğin, fuzzer tls_server_target, sertifika doğrulama kodu kontrolünü yalnızca TLS mesajları ve protokol durumu değişiklikleriyle sınırlayan, önceden tanımlanmış bir dizi hazır sertifika kullandı.

Kaynak: opennet.ru

Yorum ekle