4.15.3 yükseltmesi gelmeden önce dört stack üzerine yazma CVE'sine karşı NSD riskinin azaltılması

Ortak bir tetikleyiciye sahip dört stack taşması

NLnet Labs, 4.10.0'dan 4.15.2'ye kadar olan sürümleri etkileyen dört stack üzerine yazma açığını kapatmak için NSD 4.15.3'ü yayınladı. Hatalar CVE-2026-101338 (SVCB ve HTTPS kayıtları), CVE-2026-101339 (HIP kayıtları), CVE-2026-101341 (metin içeren kayıtlar) ve CVE-2026-101337 (base64 gösterim alanları) olarak takip ediliyor. SecurityOnline, CVSS v4 puanlarının 8.7 olduğunu ve yayın anında herkese açık bir exploit bulunmadığını bildiriyor.

Düzeltmeli sürümü hemen dağıtamayan operatörlere yönelik bir dev.to yazısı, dört NLnet Labs duyurusunun tamamında ortak olan bir ayrıntıya dikkat çekiyor: sömürü, NSD'ye doğrudan ulaştırılan hazırlanmış bir zone dosyası gerektiriyor ve daemon'un kendisinin yazdığı dosyalar gerekli biçimi almayacak. Bu kısıtlama ara dönem oyun planını çerçeveliyor — böyle bir dosyanın ulaşabileceği yolları daraltmak, ulaşırsa etki alanını yumuşatmak ve bir girişimin sinyallerini izlemek.

Zone dosyalarını kimlerin yazabileceği sınırlandıralım

Yazının ilk önerisi, zone dizinine yazma erişimi olan her şeyin denetlenmesi: yönetici hesapları, provisioning araçları, konfigürasyon yönetim sistemleri ve bazı dağıtımlarda web uygulamaları. Bunların tümü gerçekten buna ihtiyaç duymuyor. Bir provisioning hattı meşru olarak dosya yazıyor ve bir yeniden yükleme tetikliyor; bir web önyüzü ise bunun yerine kayıtları doğrulayan bir API'ye devretmeli ve zone dosyasını kendisi oluşturmalı.

Somut adımlar arasında geniş grup yazma izinlerinin kaldırılması, pipeline hesapları tarafından kullanılan kimlik bilgilerinin döndürülmesi ve zone dizinindeki değişikliklerin etkileşimli bir oturumdan değil, adı belirli bir dağıtım işinden gelmesinin zorunlu kılınması yer alıyor. Gerekçe çok net: hangi hesap zone dosyası yazabiliyorsa, bu CVE'lerin bağımlı olduğu bozuk kayıt düzenlerinden birini de teslim edebilir.

Bozuk kayıt düzenlerini yukarı akışta engelleyin

Her hata belirli bir kayıt düzenine ihtiyaç duyuyor — wire-format sınırının hemen ötesinde fazladan bir ECH parametresi taşıyan bir SVCB veya HTTPS kaydı, eklenmiş bir rendezvous sunucusu içeren bir HIP kaydı, arka arkaya 32 bayttan küçük metin belirteçleri veya çok küçük parçalara bölünmüş base64 alanları. İki doğrulama mekanizması, dosya daemon'a ulaşmadan önce bu biçimleri yakalayabilir.

İlki, 4.15.3'ten alınan nsd-checkzone aracını tek kullanımlık bir container içinde gelen her zone dosyasına karşı çalıştırmaktır; düzeltimli parser doğru sınır denetimlerini içerdiğinden, CVE biçimlerine benzeyen dosyaların orada reddedilme olasılığı 4.15.2 koduna göre daha yüksektir. İkincisi, zone dosyalarını üreten hangi araçta olursa olsun bir ön ayrıştırma boyut denetimi yapmaktır; bu denetim, RDATA'sı sınıra birkaç bayt kala olan SVCB veya HTTPS kayıtlarını reddeder ve base64 parça boyutlarını sınırlar. Yazı, ikisinin de her varyasyonu yakalamadığını ve ikisinin de yamanın yerine geçmediğini açıkça belirtiyor.

Daemon'un erişebileceğini azaltın

Duyurular NSD süreci içinde komut çalıştırılmasını tanımladığı için üçüncü yön, bu sürecin neye dokunabileceğini sınırlamaktır. Daemon'u ayrıcalıksız özel bir kullanıcı olarak çalıştırmak ve zone dizinini geniş yazma izni olmadan okunabilir tutmak, bir taşmanın hemen başka verilerin kontrolüne dönüşmesini engeller. Linux'ta yazı, olağan servis birimi sağlamlaştırmasını öneriyor: kısıtlı dosya sistemi erişimi ve kimlik bilgisi tutan yönetim yazılımıyla birlikte aynı yerde barındırma yapılmaması.

Çökmeleri ve yeniden yükleme çağıranları izleyin

İzlenmeye değer iki izleme sinyali var. Başarısız bir parser taşması daemon'u öldürür, dolayısıyla süpervizörler çıkışı günlüğe kaydeder; yeniden yükleme olaylarıyla ilişkilendirilen beklenmeyen çıkışlar, hızlıca inceleme yapabilecek birine ulaşmalıdır. Ayrıca, normalde hiçbir zaman DNS değişikliği yapmayan bir hesap tarafından tetiklenen bir yeniden yükleme, bir saldırgan zone teslimatının dosyayı yükleyen bir yeniden yüklemeyle sonuçlanması nedeniyle tırmandırılmayı hak eder.

Kaç sunucu maruz kalıyor

Yazı, bağlam olarak ZoomEye rakamlarını içeriyor: yazım anında bir NSD uygulama parmak izine uyan 116.266 varlık ve NSD bannera uyan 628.831 varlık varken, CVE-2026-101338 için yapılan bir sorgu ifşadan kısa süre sonra sıfır döndürdü. Yazar bu sayıların sürüm hakkında veya belirli bir sunucunun dışarıdan üretilen zone dosyalarını kabul edip etmediği hakkında hiçbir şey söylemediği konusunda uyarıyor — sayılar nüfusun büyüklüğünü ölçüyor, açıklığı değil.

Düzeltmeli sürüme ulaşmak

NSD 4.15.3, NLnet Labs tarafından yayımlandı. Tam sürüm bir anda benimsenemiyorsa, üretici, kaynak dizinde patch -p1 ile uygulanabilen, ardından make install ve yeniden başlatma yapılan 4.15.2'ye karşı CVE başına diff'ler sağlıyor. Yazı, ara dönem denetimlerini isteğe bağlı saymadan önce, yeniden başlatılan sürecin düzeltimli yapıyı bildirdiğinin doğrulanmasını öneriyor.

Neden önemli

Bu CVE'ler uzaktan tehditlerden çok güçlendiriciler olarak önem taşıyor: zaten zone dosyaları yazan bir pipeline, provisioning aracı veya web uygulamasını kontrol eden bir saldırgan, DNS daemon'u içinde komut çalıştırma yetkisi kazanır. Gerçek filoların güncellemeleri yeniden paketleyip dağıtması günler veya haftalar sürüyor, dolayısıyla ara dönem önlemleri gerçek bir boşluğu dolduruyor. Önerilen somut denetimler — en az ayrıcalıklı yazma yolları, ön ayrıştırma doğrulaması ve çökme-yeniden yükleme ilişkilendirmesi — bu yama döngüsünden sonra da geçerli kalacak kalıcı hijyen uygulamalarıdır. Ayrıca internet taramalarına görünen yüz binlerce NSD sunucusu varken, çoğu operatör kendi örneğinin sadece bilinmediğini varsayamaz.