Es ist Zeit Firmware zu bauen 
Ich sehe nirgends wo uns das betreffen sollte, da auf den Routern der DNSMasq nur Lokal lauscht und nicht im Netzwerk.
Kann also getroßt ignoriert werden, außer man benutzt es auf den Supernodes.
Das ist natürlich eine Frage des „uns“.
Wenn man z.B. den DNS-Cache (aus Gluon 2017) aktiviert hat, dann lauscht der DNS-Masq auf die NextnodeV4 und NextnodeV6.
http://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html
Aber wenn Ihr das nicht benutzt, dann betrifft es Euch natürlich nicht.
Was zumindest für DHCP das Default-Setup auf vielen (allen?) Ruhrgebiets-Supernodes war noch vor 2 Jahren.
Aber das hat sich dann wohl geändert.
Du hast da sicher den besseren Einblick.
Ok einigen wir uns drauf, das man evt. bei Apokalyptischen CVE Meldungen dazu schreibt WER WANN betroffen ist. Weil solche Meldungen lösen immer direkt ein Frage und Antwort Spielchen aus womit sich dann die Betreuenden Personen rumschlagen können.
Zur Ruhrgebiet kann ich nur zu meinem teil was sagen, und da läuft seid Ewigkeiten ISC, wie bei euch sicherlich auch 
Ok einigen wir uns drauf, das man evt. bei Apokalyptischen CVE Meldungen dazu schreibt WER WANN betroffen ist
Lieber @Comacho,
ich (als OP) weiss nicht ob sowie wer oder was betroffen ist. Kann die Node sein oder irgendwelche Server. Woher soll ich das wissen was welche Community da am Start hat?
Mir ging im übrigen nicht um die Server - die ihr bestimmt mit einem geeignetem Verfahren mit Sicherheitsupdates versorgt - sondern um die Router.
Darüberhinaus finde ich die Erwartung, die Analyse direkt frei haus geliefert zu bekommen, ziemlich befremdlich.
3 „Gefällt mir“
Der reißerische Aufmacher läßt durchaus Differenzierung vermissen; wenn Gluon per Default nicht angreifbar ist, gibt es auch keine dringende Notwendigkeit, FW neu zu bauen. Insofern bitte ich darum, daß Du als OP auch das Ergebnis Deines Tests des PoC (vgl. MS-Forum) hier kundtust, danke.
1 „Gefällt mir“
wenn Gluon per Default nicht angreifbar ist, gibt es auch keine dringende Notwendigkeit, FW neu zu bauen.
Ob die gefundenen Schwachstellen für eine „Stock“ Gluon-Konfiguration relevant sind habe ich vor dem Posten des Hinweises nicht geprüft.
Ich weiss nicht was du da reisserisch findest.
Das ein RCE in DNSMASQ kritisch ist?
Ganz im Gegenteil ich bin überzeugt das es keine Community gibt die systematisch die Security der Firmware zumindest in Bezug auf CVEs überwacht (das kann man auch automatisch machen). Auf wen verlasst ihr euch da? Habt ihr keine Verantwortung für das was ihr verteilt?
Wenn’s doch jemand tut: Würde gerne lernen wie ihr das macht.
Ironische Wendung: Ich folge @internetofshit und amüsiere mich da regelmässig
„Gluon ist per Default nicht angreifbar?“ Dem Thread im MS-Forum nach (https://forum.freifunk-muensterland.de/t/security-kritisch-dnsmasq-vor-2-78-remote-code-execution/3132/2) nach nicht.
Daher ist auch eben auch nicht „Zeit[,] Firmware zu bauen “. (Wobei ich nichts gegen einen Patch gegen Gluon 2016.2.7 hätte; auch ein latent vorhandener Bug darf behoben werden. Übersteigt leider mein OpenWRT-KnoffHoff.)
1 „Gefällt mir“
Der Absatz ist schnucklig, demnach tut ihr es also auch nicht, dann spiegele ich Deine Frage doch einfach mal:
Und warum hast Du »Ich werden den PoC mal ausprobieren« aus Deinem Beitrag rauseditiert?
Zum Thema zurück: Bei uns wurde „Di., 3. Okt. 2017 15:44:03“ intern das entsprechende Ticket mit Verweis auf [1] eröffnet. Da ich keine Zeit habe zu erlernen (und, da OpenWRT CC tot ist, auch keine Lust, da Energie drauf zu verschwenden), wie man externe Pakete korrekt in OpenWRT (pre-LEDE) aktualisiert, bin ich auf entsprechende Patches angewiesen. Und die interne Meldung klang ähnlich düster wie Dein »[Security][Kritisch]«. Insofern bin ich für den Beitrag von @MPW drüben dankbar:
Damit löst sich das Thema RCE in Wohlgefallen auf. Und damit die Dringlichkeit.
Lt. [1] ist der DNS-Teil »nur« anfällig für DoS; und zumindest bis 2016.2.7 gehen Clientanfragen (normalerweise) nicht über den Knoten.
Was also bleibt ist (in Standard-Gluon-Umgebungen) eine DoS-Anfälligkeit, die nur die Knoten-lokale Auflösung tangiert, und hier dann die Verbindung zu den Gateways torpedieren könnte.
Dagegen haben wir eh’ einen Wachhund am Start, ich werde also auch heute Nacht sehr unaufgeregt schlafen.
Was nicht heißt, daß ich nicht patchen wollen würde; alleine kann ich’s nur schlicht nicht (zu in Relation zum Angriffsvektor vertretbarem Aufwand).
[1] Google Online Security Blog: Behind the Masq: Yet more DNS, and DHCP, vulnerabilities
Nützt nur nichts den Communities, die aus $Gründen z. Zt. auf 2016.2.x aufbauen. Aber die sind ja auch zum Glück nur am Rande betroffen. Gnade der späten Geburt reloaded.
noch ein Grund mehr endlich das Update anzugehen
1 „Gefällt mir“