CERT veröffentlicht CVEs für sechs schwerwiegende Sicherheitslücken in dnsmasq

 (lists.thekelleys.org.uk)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • CERT veröffentlicht am 11. Mai 2026 ein Set von CVEs für sechs schwerwiegende Sicherheitslücken in dnsmasq
  • Bei den Schwachstellen handelt es sich durchweg um alte Bugs, und sie betreffen nahezu alle dnsmasq-Versionen mit Ausnahme sehr alter Releases
  • Die CVEs wurden den Herstellern vorab offengelegt, und jeder Hersteller muss rechtzeitig eine gepatchte Version seines dnsmasq-Pakets bereitstellen
  • Für das stabile Release dnsmasq 2.92 wurde die gepatchte Version 2.92rel2 erstellt, die über die bisherigen Download-Orte verfügbar ist
  • In Kürze soll das Tag dnsmasq-2.93rc1 erstellt werden; nach Tests wird eine Veröffentlichung von 2.93 in etwa einer Woche angestrebt

Offenlegung der dnsmasq-Schwachstellen und Patches

  • CERT veröffentlicht am 11. Mai 2026 ein Set von CVEs für sechs schwerwiegende Sicherheitslücken in dnsmasq
  • Die Schwachstellen sind allesamt alte Bugs und betreffen nahezu alle dnsmasq-Versionen mit Ausnahme sehr alter Releases
  • Die CVEs wurden den Herstellern vorab offengelegt, und jeder Hersteller muss rechtzeitig eine gepatchte Version des dnsmasq-Pakets ausliefern
  • Details und Patches sind unter https://thekelleys.org.uk/dnsmasq/CVE/ verfügbar
  • Für das stabile Release dnsmasq 2.92 wurde die gepatchte Version 2.92rel2 erstellt, die über die bisherigen Download-Orte verfügbar ist
  • Im Entwicklungszweig sollen zeitgleich ebenfalls Fix-Commits erscheinen; einige nutzen dieselben Patches wie die Backports, andere sind umfassendere Überarbeitungen, die die Ursache des Problems beheben

Zunahme von KI-basierten Reports und Plan für 2.93

  • In den vergangenen Monaten hat KI-basierte Sicherheitsforschung zu einem starken Anstieg von Bug-Reports geführt, und das Entduplizieren sowie Klassifizieren der Fehler kostet viel Zeit
  • Die Bugs wurden in solche aufgeteilt, die eine Vorab-Offenlegung an Hersteller erfordern, und solche, die besser sofort nach Veröffentlichung behoben werden; diese Unterscheidung ist zwangsläufig subjektiv
  • Da mehrere „good guys“ dieselben Bugs wiederholt gefunden haben, ist es wahrscheinlich, dass auch „bad guys“ sie hätten finden können; daher wird der Nutzen eines langen Embargos als begrenzt angesehen
  • Die Koordination eines Embargos und die Bereitstellung von Backports erfordern von allen Beteiligten viel Zeit und Aufwand
  • Die meisten Bugs sollen in kommenden Releases behoben werden; Vorrang hat, neue dnsmasq-Versionen möglichst fehlerfrei zu machen
  • Dass in den Wochen vor der Ankündigung viele Security-Fix-Commits ins git-Repository aufgenommen wurden, passt ebenfalls zu dieser Richtung
  • Das Tag dnsmasq-2.93rc1 soll in Kürze erstellt werden; Ziel ist es, die stabile Version 2.93 so schnell wie möglich zu veröffentlichen
  • Tests des Release Candidate sind wichtig, daher sollten alle, die können, ihn frühzeitig testen
  • Wenn alles reibungslos läuft, könnte 2.93 in etwa einer Woche erscheinen
  • Der „Tsunami“ an KI-generierten Bug-Reports zeigt keine Anzeichen eines Abflauens, sodass sich derselbe Prozess bald erneut wiederholen könnte
  • Zwischen dem Ziel, möglichst viele der aktuell eingehenden Bugs noch in 2.93 aufzunehmen, und einer rechtzeitigen Veröffentlichung besteht ein Spannungsverhältnis; Priorität hat eine zeitnahe Veröffentlichung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Es wirkt, als würden wir jetzt an einen Punkt kommen, an dem es dringend wird, in speichersichere Sprachen umzusteigen.
    Die meisten zuletzt gefundenen Schwachstellen hängen direkt mit nicht speichersicheren Sprachen zusammen, und es scheint sehr schwer zu rechtfertigen, warum man DNS-/DHCP-Server nicht in Rust oder Go schreiben kann, möglichst ohne unsafe.

    • https://news.ycombinator.com/item?id=47943499 — Es gab den Fall, dass man coreutils durch eine neue Rust-Implementierung ersetzen wollte und dabei 44 CVEs herauskamen. Ein kostenloses Mittagessen gibt es nicht.
    • Das Problem ist nicht die Sprache, sondern der Mangel an Fachkräften, die so etwas angehen.
      AI-Sicherheitsforscher tun immerhin irgendetwas. Wenn es so einfach wäre, alles in Rust neu zu schreiben, hätte es am Tag nach so einem Vorfall sofort eine robuste Rust-Alternative geben müssen.
      Warum das nicht passiert? Weil man für solche Arbeit kaum GitHub-Stars bekommt.
    • Vielleicht liegt das Problem an der Art, wie wir auf dynamischen Speicher blicken.
      Ich bezweifle, dass „wir kennen die Maximalgröße nicht, also muss alles dynamisch sein“ wirklich richtig ist. Es ist nicht das Ende der Welt, wenn ein Programm eine zulässige maximale Eingabegröße deklariert und darüber hinaus einen Fehler ausgibt oder einen Ringpuffer verwendet.
      Wenn man die Größe kennen kann, kann man entsprechend entwerfen. RAM ist endlich, und es ist seltsam, dass alle Schichten darin so gebaut werden, als wären sie unendlich.
      Auf Rust umzusteigen wirkt wie eine enorme Zeitverschwendung und löst nicht das grundlegende Problem, dass Programme nicht an die Realität endlicher Systemressourcen angepasst modelliert werden. Das betrifft nicht nur Speicher. Dass Chrome ein 4-GB-Modell auf das Gerät des Nutzers lädt, ist ein ähnlicher Fall.
    • Stimme ich nicht zu. Dank AI-Agenten, die potenzielle Schwachstellen finden, werden Schutzmechanismen eindeutig besser.

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

  • Ich habe mich gefragt, ob OpenWRT schon einen neuen Build veröffentlicht hat, aber die Antwort ist: noch nicht, es wird noch daran gearbeitet.
    https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • Mein MaraDNS wurde im Zeitalter AI-gestützter Sicherheitsaudits ziemlich umfassend geprüft.
    Seit 2023 wurde kein einziger schwerwiegender Sicherheitsfehler gefunden [1].
    Das Einzige, was die Auditoren fanden, waren Dinge wie „Deadwood braucht beim Freigeben von Ressourcen länger als üblich, wenn es im vollständig rekursiven Modus ein ungewöhnliches Paket bekommt“ [2] oder „ein mit MaraDNS geliefertes Hilfsprogramm kompiliert seit 2022 nicht einmal mehr, hat aber einen Buffer Overflow nur dann, wenn $HOME länger als 50 Zeichen ist“ [3].
    Ich bin persönlich sehr zufrieden damit, dass MaraDNS jetzt unter echter, tiefgehender Sicherheitsprüfung als ziemlich sicher dasteht.
    [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

    • Wenn Lua 5.1 als Bibliothek nicht dynamisch geladen, sondern als Lunacy eingebündelt wurde, und dann auch noch in einer Version von 2012, könnte es wahrscheinlich auch von CVE-2014-5461 und Ähnlichem betroffen sein.
      Auch Lua war nicht frei von Sicherheitsfixes.
    • Trotzdem ist MaraDNS deutlich weniger populär als dnsmasq.
      Ich habe selbst ein paar Bibliotheken geschrieben, in denen seit 1991 kein schwerwiegender Sicherheitsfehler gefunden wurde. Natürlich benutzt niemand meine Bibliotheken.
      Ich will die Leistung nicht kleinreden, aber es ist wichtig, solche Behauptungen im Kontext der Nutzerbasis einzuordnen.
    • Als ich früher einen DNS-Server einrichten musste, war ich froh, MaraDNS als Alternative zum „macht einfach alles“-Ansatz von dnsmasq gefunden zu haben, und noch wichtiger: Danach musste ich mich nicht mehr darum kümmern.
    • Ich bin neugierig, aber ich verstehe nicht, worauf du hier hinauswillst. Dass es Alternativen zu dnsmasq gibt, oder dass deine Software irgendwie „besser“ ist?
      Diese Eigenwerbung bringt der dnsmasq-Diskussion fast keinen Mehrwert.
      Je weiter verbreitet Software ist, desto mehr wird sie geprüft und desto mehr Bugs und Randfälle werden gefunden.
    • Gut gemacht. Aber dass wir selbst 2026 noch zentrale Netzwerk-Tools in einer anfälligen Sprache wie C schreiben, ist erstaunlich.

  • Zum Glück läuft diese Software ja sicher nicht auf Millionen Geräten, die praktisch nie Updates bekommen.

    • Wenn ein Vendor sagt: „Wir können dich nicht damit machen lassen, was du willst“, dann ist es gut, die eigene Hardware direkt kontrollieren zu können.
    • Immerhin läuft das in den meisten Fällen auf Geräten, die erst dann Pakete senden, wenn der Client sich zuvor im Wi-Fi authentifiziert oder physisch an den Ethernet-Port angeschlossen hat.
    • Y2K26?

  • Ziemlich ernst.
    „Ein entfernter Angreifer, der DNS-Anfragen stellen oder DNS-Antworten liefern kann, kann einen großen Out-of-Bounds-Write auf dem Heap auslösen.“
    Eine fehlerhafte DNS-Antwort kann „eine Endlosschleife auslösen, sodass dnsmasq auf keine Anfragen mehr antwortet“.
    Bösartige DHCP-Anfragen können einen Buffer Overflow verursachen.

  • Einen Tsunami aus AI-Bugreports gibt es nicht in allen Projekten. Wie oben gesagt, bei MaraDNS gab es das nicht.
    Ich vermute, bei djbdns und tinydns auch nicht. Wenn es das gegeben hätte, wäre das groß angekündigt worden.
    Ich habe nie ganz verstanden, warum manche Projekte extrem populär werden und andere nicht.
    Es wirkt fast so, als würden Tools, die „zu gefährlich zum Veröffentlichen“ seien, alle Projekte scannen, aber nur selektiv die mit Problemen kontaktieren. So muss man nicht zugeben, dass das eigene Tool nichts gefunden hat.

    • So etwas passiert bei populären Projekten.

  • Ich mochte dnsmasq nie besonders. Es fühlte sich an, als würde ein einzelnes Tool zu viele Dinge übernehmen.
    Einen lokalen Caching-Resolver, einen DHCP-Server und TFTP-/PXE-Boot-Konfiguration habe ich immer lieber getrennt eingerichtet.

    • Für manche gibt es ein paar dnsmasq-Features, die sich nur schwer ersetzen lassen.
      Zum Beispiel Anfragen für *.example.com an einen bestimmten Upstream-Server weiterzuleiten, für Phishing-Sites NXDOMAIN zurückzugeben oder alle zu *.example.org aufgelösten IPs für Policy Routing zu einem ipset hinzuzufügen.
      Die letzte Funktion arbeitet auf FreeBSD, obwohl es dort kein ipset gibt. Die Liste *.example_xyz.com kann sehr groß sein, und dnsmasq soll das in neueren Versionen effizient verarbeiten.
    • Genau wegen dieses Gedankens habe ich vor langer Zeit MaraDNS für DNS-Hosting verwendet.
      10 von 10, nichts bereut, empfehlenswert.
    • Stimme zu. Das fühlt sich auch gegen die Linux-„Art, Dinge zu tun“, an.
      Zum Beispiel verwendet Opnsense für DHCP nur den DHCP-Teil von dnsmasq und für DNS unbound, und das fühlt sich etwas „seltsam“ an.
    • Das ist bis zu einem gewissen Grad der Zweck. dnsmasq ist ein Paket mit Apps für „einen kleinen Router betreiben“.
      DHCP und DNS hängen zusammen, und PXE braucht DHCP-Einträge. Für eine einfache Konfiguration müsste man sonst mindestens drei Daemons mit jeweils anderer Konfigurationssyntax zusammenstöpseln.

  • Anfängerfrage an Leute mit mehr Erfahrung in diesem Bereich: Warum wird Software in diesem Feld nicht viel häufiger in einer Laufzeitumgebung wie Erlang geschrieben, die Garbage Collection und Nebenläufigkeit mitbringt?

    • Die erste Veröffentlichung von dnsmasq war 2001. Damals war die Liste realistischer Sprachen für performante Netzwerkserver nicht besonders lang, und Erlang gehörte nicht dazu.
      Der Performance-Verlust war zu groß, es gab eine undurchsichtige Laufzeitumgebung, bei der schwer zu sagen war, wie stabil sie damals war, es gab wenige Mitwirkende, und die Abhängigkeitslast war groß, weil sie auf den meisten Systemen nicht installiert war.
      Selbst als ich um 2015 Erlang in Produktionssystemen verwendet habe, gab es raue Kanten, sobald man sich etwas vom ursprünglich gedachten Einsatzbereich entfernte. Das ist keine Kritik nur an Erlang, viele Sprachen und Laufzeiten waren ähnlich.
      Viele der Systeme, die in den kommenden Wochen oder Monaten weiter Treffer einstecken werden, haben einen ähnlichen Hintergrund. Beim Linux-Kernel war die einzige potenzielle Alternative damals im Grunde C++. OpenSSL, ein Stammgast bei Sicherheitsproblemen, begann 1998.
      Ich stimme sehr stark der Aussage zu, dass man keine neuen Projekte mit Netzwerkzugang in C schreiben sollte, aber wenn man auf 1998 zurückgeht, ist es schwer zu sagen, welche andere Wahl realistisch gewesen wäre.
      Sicherere Sprachen gab es, aber ihre Communities waren viel kleiner als die von C, und ihre Stabilität ließ sich schwerer garantieren. Java war bereits da, aber ich weiß nicht genau, ab wann es ein ernsthafter Kandidat für Netzwerkserver wurde; ich würde grob auf die späten 2000er tippen. Das Java, das ich 1999 gesehen habe, war es jedenfalls noch nicht.
      Ich habe zum Beispiel 2011 einen Haskell-Netzwerkserver für einen eher unwichtigen Zweck betrieben, und er ist unter Bedingungen umgefallen, die für ein Produktionsnetzwerk nicht einmal besonders extrem gewesen wären. 2013 habe ich dieselbe Codebasis ohne Änderungen an der Haupt-Event-Loop wiederverwendet, und es war etwa 90 % besser, weshalb ich eher Haskell als meinen Code verantwortlich mache.
      Für echte Produktion war das aber immer noch nicht gut genug, doch immerhin zeigte es, dass nicht mein Code das Problem war. Das heißt auch: Selbst wenn Haskell in den 2000ern existierte, war es damals kaum eine realistische Option für Netzwerkserver.
      Heute gibt es viel mehr Auswahl als früher.
    • In C kann man struct normalerweise ziemlich direkt auf Netzwerkpakete abbilden, was recht einfach ist.
      In anderen Sprachen ist das oft nicht so unkompliziert.
      Dazu kommt natürlich, dass sie langsamer und größer sind.