CERT, dnsmasq'taki 6 kritik güvenlik açığı için CVE'leri yayımlıyor

 (lists.thekelleys.org.uk)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • CERT, 11 Mayıs 2026'da dnsmasq'taki 6 kritik güvenlik açığına ilişkin CVE setini yayımlıyor
  • Açıkların tamamı eski hatalar ve çok eski sürümler hariç neredeyse tüm dnsmasq sürümlerini etkiliyor
  • CVE'ler üreticilere önceden bildirildi ve her üreticinin dnsmasq paketinin yamalı sürümünü zamanında dağıtması gerekiyor
  • Kararlı sürüm dnsmasq 2.92'ye yamaların uygulandığı 2.92rel2 oluşturuldu ve mevcut indirme konumundan alınabiliyor
  • Yakında dnsmasq-2.93rc1 etiketi oluşturulacak; testlerin ardından yaklaşık bir hafta içinde 2.93 sürümü hedefleniyor

dnsmasq açıklarının duyurulması ve yamalar

  • CERT, 11 Mayıs 2026'da dnsmasq'taki 6 kritik güvenlik açığı için bir CVE seti yayımlıyor
  • Açıkların tamamı eski hatalar ve çok eski sürümler hariç neredeyse tüm dnsmasq sürümleri için geçerli
  • CVE'ler üreticilere önceden bildirildi ve her üreticinin dnsmasq paketinin yamalı sürümünü zamanında dağıtması gerekiyor
  • Ayrıntılar ve yamalar https://thekelleys.org.uk/dnsmasq/CVE/ adresinde görülebilir
  • Kararlı sürüm dnsmasq 2.92'ye yamaların uygulandığı 2.92rel2 oluşturuldu ve mevcut indirme konumundan alınabiliyor
  • Aynı zamanda geliştirme ağacına da düzeltme commit'leri eklenecek; bunların bir kısmı backport ile aynı yamayı kullanırken, bir kısmı kök nedeni ele alan daha kapsamlı bir yeniden yazım niteliğinde

Yapay zeka tabanlı rapor artışı ve 2.93 planı

  • Son birkaç ayda yapay zeka tabanlı güvenlik araştırmaları nedeniyle hata raporları büyük ölçüde arttı ve yinelenen kayıtların ayıklanmasıyla hataların sınıflandırılmasına çok zaman harcandı
  • Hatalar, üreticilere önceden bildirim gerektirenler ile yayımlandıktan hemen sonra düzeltilmesi daha iyi olanlar olarak ayrıldı; bu ayrım kaçınılmaz olarak öznel
  • Aynı hataları birden fazla “good guy” tekrar tekrar bulduğuna göre, “bad guy”ların da bunları bulmuş olma ihtimali var; bu yüzden uzun embargonun etkisinin çok yüksek olmadığı düşünülüyor
  • Ambargo koordinasyonu ve backport sağlanması, tüm katılımcılar için çok zaman ve emek gerektiriyor
  • Hataların çoğunu gelecek sürümlerde düzeltip yeni dnsmasq sürümünü mümkün olduğunca hatasız hale getirmek öncelikli
  • Duyurudan önceki birkaç hafta boyunca git deposuna çok sayıda güvenlik düzeltme commit'i eklenmiş olması da bu yaklaşımla uyumlu
  • Yakında dnsmasq-2.93rc1 etiketi oluşturulacak ve amaç, kararlı 2.93 sürümünü mümkün olan en kısa sürede yayımlamak
  • Sürüm adayı testleri önemli olduğundan, imkânı olan kullanıcılar erken test etmeli
  • Her şey yolunda giderse 2.93 yaklaşık bir hafta içinde çıkabilir
  • Yapay zeka tarafından üretilen hata raporlarının “tsunami”si duracak gibi görünmüyor; bu yüzden aynı sürecin yakında yeniden yaşanması mümkün
  • 2.93'e devam eden hata akışından olabildiğince fazlasını dahil etmekle zamanında sürüm yayımlamak arasında bir gerilim var ve öncelik zamanında sürüm yayımlamakta

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • C ile yazılmış kodu bellek güvenli bir dile taşımanın artık acil hale geldiği bir dönüm noktasındayız gibi görünüyor
    Son dönemde bulunan açıkların çoğu bellek güvenli olmayan dillerle doğrudan ilişkili ve DNS/DHCP sunucularının Rust ya da Go ile, mümkünse unsafe olmadan yazılamayacağını savunmak giderek daha zor görünüyor

    • https://news.ycombinator.com/item?id=47943499 — coreutils'i yeni bir Rust uygulamasıyla değiştirmeye çalışırken 44 CVE çıkan bir örnek var. Bedava öğle yemeği yok
    • Sorun dil değil, bu işi yapacak yetenek eksikliği
      Yapay zeka güvenlik araştırmacıları en azından bir şeyler yapıyor. Her şeyi Rust ile yeniden yazmak bu kadar kolay olsaydı, böyle bir olayın ertesi günü sağlam bir Rust alternatifi ortaya çıkmış olurdu
      Ortaya çıkmamasının nedeni, böyle işler yapınca GitHub yıldızı kazanmanın zor olması
    • Belki de sorun dinamik bellek konusuna bakış biçimimizdir
      “Maksimum boyutu bilmiyoruz, o halde her şey dinamik olmalı” yaklaşımının gerçekten doğru olup olmadığı şüpheli. Bir programın girdinin kabul edilebilir en büyük boyutunu ilan etmesi ve aşılırsa hata vermesi ya da halka tampon kullanması dünyanın sonu değil
      Boyutu biliyorsanız ona göre tasarlayabilirsiniz. RAM sonlu ama onun üzerindeki tüm katmanların sonsuzmuş gibi tasarlanması tuhaf
      Rust'a geçmek büyük bir zaman kaybı gibi görünüyor ve programları sonlu sistem kaynakları gerçeğine göre modelleyememe gibi temel sorunu çözmüyor. Bu yalnızca bellekle ilgili de değil. Chrome'un kullanıcı cihazına 4GB model indirmesi de benzer bir durum
    • Katılmıyorum. Olası açıkları bulan AI ajanları sayesinde koruma mekanizmaları belirgin biçimde iyileşiyor

  • https://xchglabs.com/blog/dnsmasq-five-cves.html

  • OpenWRT yeni bir derleme çıkardı mı diye merak ettim; cevap henüz hayır, üzerinde çalışılıyor
    https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • Benim MaraDNS yazılımım, AI destekli güvenlik denetimi çağına girilirken oldukça kapsamlı biçimde denetlendi
    2023'ten bu yana tek bir ciddi güvenlik hatası bile bulunmadı [1]
    Denetçilerin bulduğu şeyler yalnızca “Deadwood tam özyinelemeli moddayken alışılmadık bir paket alırsa kaynakları serbest bırakması normalden uzun sürüyor” [2] ya da “MaraDNS ile gelen yardımcı bir araç 2022'den beri derlenmiyor ama yalnızca $HOME 50 karakteri aşarsa tampon taşması var” [3] gibi şeylerdi
    Gerçek ve derinlemesine güvenlik denetimlerinden geçerken MaraDNS'in oldukça güvenli çıkması kişisel olarak beni çok memnun ediyor
    [1] https://samboy.github.io/MaraDNS/webpage/security.html
    [2] https://github.com/samboy/MaraDNS/discussions/136
    [3] https://github.com/samboy/MaraDNS/pull/137

    • Lua 5.1'i bir kütüphane olarak yüklemek yerine Lunacy içine gömdüyseniz ve bu da 2012 sürümüyse, muhtemelen CVE-2014-5461 gibi açıklar bundan etkilenebilir
      Lua da güvenlik düzeltmelerinden muaf değildi
    • Yine de MaraDNS, dnsmasq'a göre çok daha az popüler
      Benim de yazdığım birkaç kütüphane var ve 1991'den beri içlerinde tek bir ciddi güvenlik hatası bulunmadı. Tabii kimse kütüphanelerimi kullanmıyor
      Başarıyı küçümsemeye çalışmıyorum ama böyle iddiaları kullanıcı tabanının ne olduğuyla birlikte bağlama oturtmak önemli
    • Eskiden bir DNS sunucusu kurarken, dnsmasq'ın “her şeyi yapan” yaklaşımı yerine MaraDNS'i bulduğuma sevinmiştim ve daha da önemlisi sonrasında onunla ilgilenmem gerekmedi
    • Merak ediyorum, burada söylenmek istenen şey tam olarak ne? dnsmasq için bir alternatif olduğu mu, yoksa kendi yazılımınızın bir şekilde “daha iyi” olduğu mu?
      Bu tanıtımın dnsmasq tartışmasına neredeyse hiç katkısı yok
      Daha yaygın kullanılan yazılımlar daha çok incelenir ve daha fazla hata ile sınır durum bulunur
    • İyi iş. Ama 2026'da bile temel ağ araçlarını hâlâ C gibi kırılgan bir dille yazıyor olmamız şaşırtıcı

  • Neyse ki bu yazılım neredeyse hiç güncelleme almayan milyonlarca cihazda kullanılmıyordur herhalde

    • Bir üretici “onu istediğin gibi kullanmana izin veremeyiz” dediğinde, kendi donanımın üzerinde doğrudan denetime sahip olmak iyi bir şeydir
    • En azından çoğu durumda bunlar, istemci önce Wi‑Fi'da kimlik doğrulaması yapmadan veya Ethernet portuna fiziksel olarak bağlanmadan paket gönderemeyen cihazlarda çalışıyor
    • Y2K26?

  • Oldukça ciddi
    “DNS sorgusu gönderebilen veya DNS yanıtı döndürebilen uzaktaki bir saldırgan, yığında büyük bir sınır dışı yazma tetikleyebilir”
    Hatalı DNS yanıtları “sonsuz döngüye neden olup dnsmasq'ın tüm sorgulara yanıt veremez hale gelmesine” yol açabilir
    Kötü niyetli DHCP istekleri tampon taşmasına neden olabilir

  • AI hata raporu tsunamisi her projede yok. Yukarıda dendiği gibi MaraDNS'te olmadı
    djbdns ve tinydns için de olmadığını tahmin ediyorum. Olsaydı bunu yüksek sesle duyururlardı
    Neden bazı projelerin aşırı popüler olup bazılarının olmadığını hiç tam anlayamadım
    “Açıklanamayacak kadar tehlikeli” araçlar tüm projeleri tarayıp yalnızca sorun bulduklarına seçici olarak ulaşıyor da olabilir. Böylece araçlarının hiçbir şey bulamadığını kabul etmek zorunda kalmazlar

    • Böyle şeyler popüler projelerde olur

  • dnsmasq kullanmayı hiç sevmedim. Tek bir araca fazla şey yüklenmiş gibi geliyordu
    Yerel önbellekli resolver, DHCP sunucusu ve TFTP/PXE önyükleme yapılandırmasını hep ayrı ayrı kurmayı tercih ettim

    • Bazıları için yerine koyması zor birkaç dnsmasq özelliği var
      Örneğin *.example.com sorgularını belirli bir üst sunucuya yönlendirmek, oltalama sitelerine NXDOMAIN döndürmek ya da *.example.org için çözümlenen tüm IP'leri ilke tabanlı yönlendirme amacıyla ipset içine eklemek
      Son özellik, BSD'de ipset olmamasına rağmen FreeBSD'de çalışıyor. *.example_xyz.com listesi çok büyük olabiliyor ve son dnsmasq sürümlerinin bunu verimli biçimde işlediği söyleniyor
    • Bu düşünce yüzünden yıllar önce DNS barındırma için MaraDNS kullanmaya başladım
      10 üzerinden 10, hiç pişman değilim, tavsiye ederim
    • Katılıyorum. Bu, Linux'un “iş yapma biçimine” de biraz aykırı hissettiriyor
      Mesela Opnsense, dnsmasq'ın yalnızca DHCP kısmını kullanıp DNS için unbound kullanıyor ve bu biraz “garip” hissettiriyor
    • Zaten amaç bir ölçüde bu. dnsmasq, “küçük bir yönlendirici çalıştırma” uygulamasını tek kutuda topluyor
      DHCP ve DNS bağlantılıdır, PXE de DHCP girdileri ister. Basit bir kurulum yapmak istiyorsanız, aksi halde farklı yapılandırma söz dizimleri olan en az 3 daemon'ı birbirine bağlamanız gerekir

  • Bu alanda daha deneyimli birine sormak istediğim acemi bir soru var: Neden bu alandaki yazılımlar, Erlang gibi çöp toplayıcılı ve eşzamanlılık destekli dil çalışma zamanlarıyla daha fazla yazılmıyor?

    • dnsmasq'ın ilk sürümü 2001'de yayımlandı. O zamanlar yüksek performanslı ağ sunucuları için gerçekçi biçimde kullanılabilecek dil listesi pek uzun değildi ve Erlang bu listede yoktu
      Performans kaybı fazla büyüktü, o dönemde ne kadar kararlı olduğu belirsiz daha opak bir çalışma zamanı vardı, katkı sağlayan kişi sayısı azdı ve çoğu sistemde kurulu olmayan bağımlılık ayak izi de büyüktü
      2015 civarında üretim sistemlerinde Erlang kullandığımda bile, ilk tasarlandığı kullanımın biraz dışına çıktığınızda pürüzlü yanları oluyordu. Bu yalnızca Erlang'a özgü bir eleştiri değil; birçok dil ve çalışma zamanı benzerdi
      Önümüzdeki haftalar ve aylarda etkilenmeye devam edecek bu tür sistemlerin önemli bir kısmı da benzer geçmişe sahip. Linux çekirdeğinin o dönemde seçebileceği olası alternatifler aşağı yukarı C++ ile sınırlıydı. Güvenlik sorunlarının gediklisi OpenSSL ise 1998'de başladı
      “Ağ erişimi olan yeni projeleri C ile yazmayın” sözüne ben de çok güçlü biçimde katılıyorum ama 1998'e dönüp hangi başka seçeneklerin gerçekten uygulanabilir olduğunu söylemek zor
      Daha güvenli diller vardı ama C topluluğuna kıyasla çok daha küçüktüler ve istikrar vaat etmek zordu. Java çıkmıştı ama ağ sunucuları için ciddi bir aday haline tam olarak ne zaman geldiğini bilmiyorum; kabaca 2000'lerin sonları derdim. 1999'da gördüğüm Java henüz orada değildi
      Örneğin 2011'de nispeten önemsiz bir amaç için Haskell tabanlı bir ağ sunucusu çalıştırdım ve üretim ağı için o kadar da uç sayılmayacak koşullarda çöktü. 2013'te aynı kod tabanını ana yürütme döngüsünü değiştirmeden yeniden kullandığımda yaklaşık %90 daha iyi hale geldi; bu yüzden sorunun benim kodumdan çok Haskell tarafında olduğunu düşünüyorum
      Yine de gerçek üretime koyacak kadar iyi değildi ama en azından başarısız olanın benim kodum olmadığını gösterdi. Bu da, Haskell 2000'lerde mevcut olsa bile o dönemde ağ sunucuları için gerçekçi bir seçenek sayılmasının zor olduğunu gösteriyor
      Bugün eskisine kıyasla çok daha fazla seçenek var
    • C'de genellikle struct'ları doğrudan ağ paketlerine eşleyebilmek işleri oldukça kolaylaştırır
      Diğer dillerde bu çoğu zaman o kadar basit değildir
      Elbette daha yavaş ve daha büyük olması da cabası