[Erledigt] Disclosure or no disclosure?

[ EDIT: Am 11.04.2017 wurden von mir dann zwei Dateien veröffentlicht, die das Prinzip eines solchen DoS-Angriffs auf eine FRITZ!Box mit einer Firmware-Version < 06.80 illustrieren. Damit ist das Thema hier dann (m.E.) auch erledigt - ob ich etwas daraus gelernt habe und was genau das sein könnte, kann ich noch nicht richtig einschätzen. Das hängt wohl auch davon ab, wie sich AVM bei künftigen Funden (ich gehe mal davon aus, daß es noch weitere geben wird ;-)) verhalten wird. ]

Soll/darf man etwas veröffentlichen, was als "proof of concept" einen DoS-Angriff auf verschiedene FRITZ!Box-Modelle mit Firmware < 06.80 illustriert? (Ab) Wann sollte man das machen?

Es geht um ein schon länger an AVM gemeldetes Problem und ich weiß recht genau, daß ich schon einmal einen entsprechenden Beitrag vorbereitet/geschrieben hatte, halt noch ohne konkreten Exploit und nur mit einer verbalen Beschreibung der Konsequenzen.

Den finde ich jetzt nicht mehr (es kann auch sein, daß ich den wirklich nur vorbereitet hatte und ihn dann doch noch nicht veröffentlicht habe, dann ist auch das "Manuskript" inzwischen irgendwie verloren gegangen oder ich brauche wohl doch einen Cloud-Speicher für diese Dinge, weil ich auf dem falschen Gerät danach suche) und daher hier noch einmal eine kurze (im Rahmen meiner eher bescheidenen Möglichkeiten in diesem Punkt) Zusammenfassung der Eckpunkte:

• ein externer HTTPS-Request mit einem bestimmten Aufbau triggert eine Komponente in der Firmware, die dann für 40 Minuten auf weitere Daten wartet und praktisch nichts anderes tut
• da diese Komponente - so sieht es zumindest aus - ein "singleton" ist (das ist ein Prozess, der nur einmal gestartet wird und wo die nächste Instanz erst nach dem Ende der vorherigen laufen kann - manchmal verarbeitet so ein Prozess dann auch mehrere serialisierte Anforderungen, aber hier ist es eben pro Request ein Prozess, der gestartet wird), werden die weiteren eintreffenden Requests für diesen Prozess in eine Warteschlange eingereiht und dann der Reihe nach abgearbeitet
• damit ist zunächst einmal die Bearbeitung weiterer (legitimer) Anforderungen, die die betroffene Komponente verwenden, behindert - je nach "Füllstand" der Warteschlange mit den anhängigen Requests für eine durchaus auch recht lange Zeit
• dieser Request erfordert keinerlei Authentifizierung und kann daher wirklich von jeder beliebigen Adresse im Internet gestartet werden, sofern die FRITZ!Box (das GUI, aka "Fernzugriff" oder wie das heute auch immer genannt werden mag) aus dem Internet erreichbar ist, das ist bereits für viele der AVM-Apps erforderlich
• sind erst einmal genug Requests für diesen einen Prozess eingetroffen, werden auch für andere (externe) Aufrufe keine zusätzlichen HTTPS-Verbindungen mehr angenommen, offenbar hat das FRITZ!OS irgendwo ein Limit (bei mir 15) für gleichzeitige (offene) TLS-Verbindungen
• das Ergebnis ist, daß die FRITZ!Box von außen nicht mehr erreichbar ist, alle externen Zugriffe laufen ja über TCP mit TLS, auch das externe TR-064 über das CGI-Interface für die AVM-Apps
• erst nach 40 Minuten wird dann der gestartete Prozess beendet und der nächste Request aus der Warteschlange verarbeitet (so dort ein weiterer steht), parallel dazu wird dann wieder eine einzelne TLS-Verbindung verfügbar (was nicht automatisch heißen muß, daß die Box nach extern wieder "normal" reagiert, denn einige Client verwenden auch mal mehr als eine TLS-Verbindung gleichzeitig), solange nicht erneut ein DoS-Request abgesetzt wird
• im LAN wirkt die Begrenzung durch die TLS-Verbindungen nicht, aber der Aufruf des Prozesses ist von dort ebenso möglich - für die Warteschlange an sich spielt es auch keine Rolle, ob der Request von innen oder von außen kommt
• im Ergebnis sind im LAN bis zu 170-180 Requests möglich, bevor die Box keine weiteren mehr akzeptiert ... die hier bis zum Anschlag belastete Ressource sind jetzt nicht die parallelen TLS-Verbindungen, sondern TCP-Verbindungen an sich
• im Klartext: werden von innen nur genug derartige Requests gesendet, nimmt die Box keine weiteren TCP-Verbindungen an, das gilt dann auch für SIP (was intern zumindest mit den FRITZ!Apps per TCP arbeitet, ggf. auch bei einigen Telefonen)
• das GUI reagiert dann logischerweise ebenfalls nicht mehr (das sind ja auch HTTP-, sprich TCP-Verbindungen) und die Folge dürfte der Griff des Besitzer zur Stromversorgung der FRITZ!Box sein
• da es für das Blockieren der Ressource auch vollkommen unerheblich ist, ob der Absender eines Requests das Ergebnis verarbeiten kann (der darf sich auch gleich nach dem Senden des Requests verabschieden, ohne daß es die Box stört - es muß also keine Verbindung "offengehalten" werden), spielt auch in einem Browser die Frage einer "same origin policy" (oder des "cross-origin resource sharing" - CORS) keine wirkliche Rolle, weil bei asynchronen HTTP-Requests (über XMLHttpRequest) in der Regel der Netzwerkzugriff trotzdem ausgeführt wird, der Javascript-Code erhält nur keinen Zugriff auf das Resultat dieses Zugriffs
• für diesen DoS-Angriff interessiert ja aber das Ergebnis auch gar nicht und in der Folge ist dieser Angriff eben auch von bzw. über jeden Browser im LAN einer FRITZ!Box auszuführen - dafür reicht bereits das Einbetten eines passenden Javascript-Blocks in irgendeine Werbung (solange man keinen Ad- bzw. Script-Blocker verwendet, aber das muß ich sicherlich nicht jedesmal neu betonen) - dank der "Notfall-IP" ist dafür nicht einmal die Kenntnis des tatsächlich verwendeten Subnetzes notwendig oder eine passende Namensauflösung für "fritz.box"

Eine "Besserung" von alleine ist nach einem erfolgten Angriff eher nicht zu erwarten, denn 180 Requests a 40 Minuten ergeben in der Summe praktisch 5 Tage, bis alle anstehenden Requests (das "Einliefern" dauert vielleicht drei Minuten) komplett abgearbeitet wurden und die angegriffene Komponente wieder für "normale" Aufgaben zur Verfügung steht. Allerdings funktioniert ab der Unterschreitung eines Limits von offenen Requests dann doch wieder die Annahme neuer TCP-Verbindungen - dazu war bei meinen Tests dann das "Abräumen" von ca. 130 dieser wartenden Requests notwendig, bis wieder TCP-Verbindungen angenommen wurden (genauer, bis sich die Login-Seite im Browser dann doch noch öffnete). Rechnet man diese 130 Requests a 40 Minuten in eine Dauer um, ist durch einen einzigen Aufruf einer "kontaminierten" Seite (das als "Angriffsmuster" zu erkennen, dürfte - zumindest derzeit - auch irgendwelche Security-Suites überfordern, sofern AVM das nicht an deren Hersteller gemeldet hat), die ca. 3 Minuten angesehen werden müßte für diese 180 Requests (die hintereinander zu senden, überfordert viele Browser und eine Pause ist in "gewöhnlichem" Javascript mit < 1 Sekunde schwer zu realisieren) ... die Blockade dauert dann 86 Stunden. Das fällt vermutlich nur in sehr wenigen Installationen nicht auf ... ich vergaß auch noch zu erwähnen, daß die eigentliche Router-Funktion dabei gar nicht beeinträchtigt wird - dabei werden ja keine TCP-Verbindungen zur FRITZ!Box aufgebaut (mal vom Gastnetz und der KiSi abgesehen, wo das auch mal passieren kann).

Auf der Basis der beschriebenen Eigenschaften habe ich für die Lücke folgenden CVSS-Wert ermittelt:

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:U/RC:U/CR:X/IR:X/AR:X/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:N/MI:N/MA:H

Das ergibt dann im Endergebnis einen Base-Score von 7.5 und einen Overall-Score von 6.7:

https://nvd.nist.gov/cvss/v3-calcul...X/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:N/MI:N/MA:H

, der sich bei einer Änderung der "Report Confidence" von "Unknown" in "Resonable" (also bei der Veröffentlichung der Details inkl. Exploit, für "Confirmed" müßte AVM reagieren) dann auf 7.0 erhöhen würde.

Ob AVM mit dieser Einschätzung einverstanden ist oder eine andere Bewertung vornehmen würde, war trotz mehrfacher Rückfragen nicht zu erfahren ... überhaupt ist die Reaktion hinsichtlich der Bestätigung dieses Fundes eher spärlich ausgefallen. Die neueste Entwicklung (abseits der bereits im Repository geschilderten Timeline) ist folgende:

---

-Ich habe am Mittwoch gegen Mittag (13 Uhr) von AVM eine E-Mail erhalten, daß nunmehr die nächste Release-Version für die 7490 erschienen ist. Das war mir zwar seit Montag bereits bekannt, aber AVM hatte damit die einzige Konzession, zu der sie sich bisher bereit erklärt haben, erfüllt - das war einmal eine E-Mail beim Erscheinen der ersten gefixten Labor-Version und nunmehr diese eine beim Erscheinen der Release-Version.

Darin enthalten war auch die folgende Bitte:

AVM Team Security schrieb:

Wir möchten Sie nochmals darum bitten von einer Veröffentlichung Ihrerseits abzusehen, bis eine Lösung für alle Produkte vorhanden ist und eine hinreichende Menge das Update angenommen hat.

Zum Vergrößern anklicken....

Auf die von mir um 17:14 Uhr desselben Tages gesendete Nachfrage, was man sich darunter genau vorstellen muß (welche Modelle überhaupt geplant sind und bis wann) bzw. wie die "Roadmap" an dieser Stelle aussehen würde (inkl. der Zusage, irgendwelche konkreten Termine für mich zu behalten, wenn die wirklich in so einer Roadmap stehen sollten und diese nicht auch nur "im Verlauf von Q2/2017" enthält), wurde bisher nicht beantwortet (waren aber auch erst zwei komplette Werktage seit meiner Antwort/Rückfrage).

Ich hatte die Veröffentlichung ja bereits zuvor angekündigt (irgendwann Anfang Dez. 2016), weil sich AVM so gar nicht rührte und das dann nur auf der Basis einer Benachrichtigung vom 08.12. (als Reaktion auf eine weitere E-Mail von mir vom 30.11. mit einer diesbezüglichen Nachfrage), daß die Veröffentlichung der Release-Version im Dezember 2016 "unwahrscheinlich erscheint", noch einmal verschoben.

Es gibt jetzt in meinen Augen gute Gründe für eine Veröffentlichung und ebenso gute (aber weniger und vielleicht doch sogar nicht ganz so gute) Gründe für das Zurückhalten des genauen Aufbaus so eines Requests - das ist (abseits irgendwelcher "fertigen Dateien" zum Download) ja das Veröffentlichen des Exploits.

Für das Veröffentlichen spräche:

• es ist gängige Praxis, nach dem Überschreiten einer angemessenen Frist derartige Probleme zu veröffentlichen - unabhängig davon, was AVM sich selbst als "Firmenstrategie" an dieser Stelle auferlegt
• mangels genauerer Angaben seitens AVM bzgl. der behobenen Probleme ist eine derartige Demonstration ein recht starkes Argument, um auch "Update-Skeptiker" von der Notwendigkeit einer neuen Firmware-Version zu überzeugen ... es ist ja auch nicht die einzige gefixte Lücke; auch eine "command injection" über das NAS (bei bestimmten Konstellationen und dann auch für "gewöhnliche Benutzer" mit entsprechender "privilege escalation", bei 1&1-Kunden theoretisch sogar von extern auszunutzen, für die ich aber leider keine Einzelheiten veröffentlichen kann) ist behoben und noch ein paar weitere mit geringerer (was nicht zwangläufig als "geringer" zu lesen ist) Relevanz - das gilt allerdings auch wieder nicht für alle im Repository angeführten Lücken seit dem Sommer 2016 -> AVM entscheidet, ob gefixt werden muß und andere Stellen (wie der Media-Server) interessieren AVM gar nicht wirklich
• das Bekanntwerden könnte dazu führen, daß die Versionen für weitere Modelle schneller erscheinen ... bei der Planung von Updates verläßt sich ja AVM sehr offensichtlich auf die Verschwiegenheit der Finder (auch wenn man gar nicht wirklich mit ihnen zu kommunizieren bereit ist) und sieht gar keinen Bedarf für das Erscheinen von "ungeplanten" Updates, solange man nicht durch die äußeren Umstände dazu gezwungen ist - das macht dann im Endergebnis ein Update pro Jahr für die Modelle, die nicht "die Führung" in den Labor-Reihen haben und das wird vielleicht in absehbarer Zeit dann auch die 7490 treffen (wobei einer 7580 als neuem Flaggschiff halt der externe "klassische" Telefonanschluß fehlt, insofern ist die 7490 irgendwo auch "kompletter") - das führt dann im Umkehrschluß dazu, daß die anderen Geräte länger als erforderlich mit ungepatchten Risiken in freier Wildbahn zurechtkommen müssen und eher das Motto "wird schon kein anderer (erst recht kein "bad guy") bemerken" Anwendung findet - wie man das als Kunde dann sieht, muß jeder selbst für sich entscheiden und das führt dann unmittelbar zum nächsten Punkt
• AVM hat fast 7 Monate gebraucht, bis für das erste Modell eine Release-Version mit einem Fix erschien (die 7580 und 7560 gab es zum Zeitpunkt des Fundes noch nicht wirklich) und wenn alles "normal" läuft (sofern man aus vergangenen Erfahrungen extrapoliert), wird vielleicht irgendwann zur nächsten IFA dann der Update-Reigen auch das letzte noch mit Updates zu versorgende Modell erreicht haben, jedoch am 02.07.2017 hätte es dann bereits ein Jahr von der Meldung bis zum Fix (für "alle Modelle") gebraucht (das ließe sich eben vielleicht auch für das nächste Problem beschleunigen, wenn AVM irgendwann mal erkennt, daß ein Update pro Jahr zwar unter dem Gesichtspunkt neuer Funktionen ein netter Gedanke seitens des Herstellers ist, daß aber Sicherheitsprobleme ein derartiges "Aussitzen" eigentlich nicht vertragen
• eine andere Lücke mit "command injection", die auch nur von einem administrativen Benutzer ausgenutzt werden konnte, wo also die Veröffentlichung niemanden wirklich gefährdete und die ich mal als Versuchsballon direkt publik gemacht habe (ansonsten habe ich tatsächlich immer brav auf "responsible disclosure" gesetzt, egal wie die Reaktionen von AVM auch ausfielen), war innerhalb nur einer Woche in der Labor-Version für die 7490 bereits gefixt - eine derart schnelle Reaktion hatte ich von AVM bis zu diesem Zeitpunkt nur ein einziges Mal erlebt, wo tatsächlich bereits am nächsten Werktag die Bestätigung für den Fund einging und am darauffolgenden Tag schon das Angebot für eine gefixte Testversion kam
• solange seitens AVM immer nur allgemein und nebulös von der Behebung irgendwelcher Sicherheitsprobleme schwadroniert wird, kann man es auch einem Kunden kaum übelnehmen, wenn er - auch auf der Basis einiger hier im IPPF diskutierter Probleme mit dem DSL-Treiber oder dem WLAN oder irgendwelchen DNS-Fehlern bei ausgelastetem Upload (und was da noch alles an Problemen gemeldet wurde) - für sich entscheidet, er werde das Update wohl eher nicht machen, weil es gerade zu seiner Zufriedenheit läuft
• das läuft aber der von AVM gehegten Hoffnung, das Update würde "angenommen", mehr oder weniger direkt entgegen und die Frage, was eine "hinreichende Menge" sein mag, ist auch noch offen (selbst das Erscheinen einer gefixten Version führt ja nicht schlagartig zur allgemeinen Verwendung dieses Updates auf allen Geräten, solange AVM das nicht auch noch als "notwendig" kennzeichnet - dann erhalten nur die (NAND-)Geräte mit "einfach alles installieren, was da so kommt" das Update direkt und ich weiß gar nicht, was die Standardeinstellung bei Neueinrichtung an dieser Stelle ist) - geht man von anderen Anzeichen aus (z.B. vom Zeitpunkt des "Nachreichens" der gefixten Punkte zur 06.50 in der AVM-"Problem"-Seite (https://avm.de/service/sicherheitsinfos-zu-updates/ - auch das waren mehr, als da jeweils "veröffentlicht" wurden), ist das die zweite Stelle, wo es wohl mind. ein Jahr dauert, bis man bei AVM "zufrieden" ist mit der "Durchdringung" der Kundenboxen
• es gibt noch diverse andere Probleme, die AVM offensichtlich gar nicht als relevant ansieht - das (ebenfalls schon mangels AVM-Resonanz) irgendwo hier beschriebene Problem der "BPjM-Liste" gehört da ebenso dazu, wie die Möglichkeit, den Verkehr im LAN für bestimmte Clients über einen anderen Computer als die FRITZ!Box als "gateway" zu leiten, womit der Angreifer in die Position des MITM gelangt für jeglichen unverschlüsselten Verkehr ... irgendwann verliert man dann auch die Glaubwürdigkeit, wenn man Veröffentlichungen immer nur ankündigt und sie nie wirklich "durchzieht" - die bisher (immer mal wieder irgendwo eingestreuten) Beiträge zu bereits gemeldeten Problemen (z.B. auch zu diesem, auf dessen Behebung man nun wohl doch verzichtet hat bei AVM, trotz anderslautender E-Mail vom 24.06.2016 - sofern ich mich nicht "vertestet" habe, was aber eher unwahrscheinlich ist) waren eben noch unterhalb einer "Schmerzschwelle" und taten nicht wirklich weh - das wäre sicherlich mit einem "schlüsselfertigen Exploit" zum Kapern einer Admin-Verbindung (von bestimmten (W)LAN-Clients) zur FRITZ!Box deutlich etwas anderes (wenn dann der Filius auf diesem Weg die KiSi und/oder Limits überwindet) und dagegen nimmt sich so ein DoS-Exploit dann eher wie ein Kasperle-Theater aus, insofern ist der sogar besser geeignet - nur halt blöd, daß der auch wieder von extern funktioniert (ich kann mir aber keine passende Lücke backen und muß nehmen, was ich so finde)

Dagegen spricht:

• AVM hat um "Stillhalten" gebeten, wie wichtig man das nimmt (besonders im Lichte anderer Reaktionen), ist schwer zu beurteilen - außerdem bin ich an anderer Stelle gerade erst wieder um "die Früchte meiner Arbeit" gekommen (und sei es der "Ruhm" des Entdeckers, der eben oft genug der einzige "Lohn" ist), weil ich zulange stillgehalten habe und AVM mich sogar noch kurz vor dem Erscheinen eines Heise-Artikels "zurückgepfiffen" hat
• es bestünde die theoretische Chance, daß wirklich ein Konkurrent von AVM die Geräte "madig" machen will, indem er einen Angriff startet (oder über ein gemietetes Botnet starten läßt), bei dem dann FRITZ!Box-Besitzer in Mitleidenschaft gezogen werden, weil sie auf ihre FRITZ!Box nicht mehr zugreifen können

So sehr viel mehr fällt mir gar nicht ein, was dagegen spricht ... vermutlich kann man auch anhand der Aufzählungen (die ja auch nicht so ganz "sortenrein" trennen, das gebe ich gerne zu) meine eigene Meinung "durchscheinen" sehen.

---

-Nun bin ich zwar auch kein allzu großer Freund einer "Schwarmintelligenz", aber hier im IPPF sind ja vermutlich dann doch die "interessierten" AVM-Benutzer zu finden, die dazu ihre eigene Meinung haben. Die kann mir zwar jeder hier in diesem Thread auch gerne in Worten mitteilen (auch wenn ich gleich darauf aufmerksam machen will, daß ich nicht auf langwierige Diskussionen eingehen werde (ist tatsächlich so) und irgendwelche Beschimpfungen einfach über die "Ignorieren"-Liste ausblenden lasse), aber - auch wenn ich es noch nie gemacht habe - das Forum hat ja eine Funktion für "Umfragen".

Ich würde also (mal schauen, wie das überhaupt funktioniert) einige "einfache" Antworten vorgeben und wer mit den verschiedenen "disclosure strategies" nichts anfangen kann, findet hier beim BSI einen Überblick:

Lebenszyklus einer Schwachstelle (BSI-A-CS 002) - 2012-03_Lebenszyklus_einer_Schwachstelle.pdf

und wer sich noch nie der Frage gestellt hat, was man als Hersteller in diesen Punkten eigentlich tun sollte, kann auch diese Datei einmal ansehen:

Handhabung von Schwachstellen - Empfehlungen für Hersteller - BSI-CS_019.pdf

Bleibt die Aufzählung der "Wahlmöglichkeiten" (bitte "aber jeder nur ein Kreuz", auch wenn das im Originalwerk ein anderes "Kreuz" war und bei der "Wahl" gibt es nur die Texte vor dem "Pfeil", der Rest ist nur "Begründung"):

1. Sollte schon längst veröffentlicht sein -> "full disclosure" ist ohnehin das Einzige, was den Kunden wirklich schützen kann, weil nur so der Hersteller zu schnellen Reaktionen gezwungen wird und solche Sachen können eben auch jederzeit von jemandem gefunden werden, der sie dann auch ausnutzt (s. "webcm"-Lücke), was dann auch bei den Kunden entsprechenden Ärger/Aufwand nach sich zieht, den man mit sofortigem (oder zumindest zeitnahem) Update hätte vermeiden können.
2. Zeit für die Veröffentlichung -> "responsible disclosure" ist bereits erfolgt, angesichts der vergangenen Zeit kann man das nun auch tatsächlich komplett veröffentlichen, zumal weitergehende Aktivitäten in Richtung "coordinated disclosure" seitens AVM nicht zu erwarten ist (geht beim Advisory des Herstellers schon los), denn (fast) alle Nachfragen (angefangen beim CVSS-Wert bis zur Planung oder belastbaren Zusagen über weitere Benachrichtigungen) verhallen ungehört (vielleicht auch ungelesen, das ist nicht zu beurteilen von außen)
3. Nicht veröffentlichen -> einfach so lange warten, wie AVM das für richtig hält (die machen das dann schon selbst?) ... das ist dann irgendwas zwischen "coordinated" (lolwut) und "no disclosure", weil ich doch schon jenseits der 50 bin, aber das Problem ist schon so brisant, daß ein wirklicher Schaden für FRITZ!Box-Besitzer zu erwarten ist (auch wenn es "nur" eine nicht funktionierende Box ist, die neu gestartet werden muß), wenn sich irgendein "Spaßvogel" zur Verwendung der Lücke veranlaßt sieht und das hier Geschriebene sollte als "Warnung" bereits ausreichen, um Update-Muffel aus ihrer Wohlfühlzone zu holen (das ist ja schon deutlich mehr, als AVM "preisgibt")

Wie gesagt, ich muß erst einmal schauen, wie ich die Wahlmöglichkeiten dann eingebe ... bisher habe ich nur die Checkbox und das Feld für die Anzahl der Optionen gefunden.

@MuP:
Das mag sein, ein solcher bin ich aber nicht und ich habe weder einen schriftlichen Vertrag noch habe ich ein NDA unterschrieben. Das war mir dann - im AVM-Entwurf vom Dez. 2014 - doch zu "gummiartig" (ja, ich interessiere mich tatsächlich auch für AGBs, Verträge, Gesetze, usw. und lese so etwas sehr gründlich, erst recht dann, wenn ich es unterschreiben soll), da hätte ich hier vermutlich nie mehr etwas schreiben können, ohne selbst im Zweifel zu sein, ob ich das nun darf oder nicht und auf den Vorschlag der "Hinterlegung" von Listen bereits vor der Unterzeichnung bekannter Probleme (auf beiden Seiten, weil eben auch ein Abrechnungsmodell auf der Basis von Anzahl und Schwere gefundener Lücken in Betracht gekommen wäre) bei einem unabhängigen Dritten wollte man nicht eingehen. In die Klauseln des NDA hätte man fast jeden IPPF-Beitrag von mir quetschen können - die mündliche Versicherung, man würde das aber niemals in dieser Weise anwenden, erschien mir irgendwie nicht ausreichend. Da ist also kein "Vertrag" vorhanden und ich hatte auch niemals einen - und habe auch keinen - Einblick in irgendwelche AVM-Interna, das waren alles nur "Blackbox-Tests" mit denselben Mitteln, die jedem "Hacker" auch zur Verfügung stehen würden - die zwei Vorabversionen einer Firmware, die auf Geräten für Pentests installiert waren, sehe ich ausdrücklich nicht als "intern" in diesem Kontext (wenn es um "interne Kenntnisse" geht, nicht bei der Weitergabe o.ä., die logischerweise nie erfolgte).

Was (bzw. dass) ich für AVM als Auftrag abgearbeitet habe (2x 80h Pentest), habe ich irgendwo schon mal geschrieben und die 2 "buy-outs" (für Probleme, die durchaus auch Schadenspotential hatten unter geeigneten Umständen) erläutere ich genauso wenig im Detail, wie die bei den Pentests (die explizit auf die 6490 bezogen waren) gefundenen Möglichkeiten. Wenn die dann unabhängig gefunden werden, gebe ich trotzdem meinen Senf dazu - es ist selbstverständlich, daß ich Verschwiegenheit wahre und nicht aktiv darüber berichte, wenn das im Rahmen eines Auftrags gefunden wurde ... aber ich habe eben auch keinen "Maulkorb" und werde keinen solchen akzeptieren; das war aber bereits von Beginn an klargestellt (und eben ein heftiger Punkt der Diskussion in teils stundenlangen Telefonaten und - zumindest meinerseits - eher ausführlichen E-Mails) und hat zumindest die Anfrage für einen zweiten Pentest nicht verhindert.

Bei deutlich außerhalb eines Auftrags gefundenen Problemen sehe ich mich genauso als "Finder" einer Lücke, wie das jeder andere auch tut (und beanspruche dann zumindest die "credits" für mich, warum steht auch irgendwo) ... vielleicht habe ich andere Erwartungen an einen Hersteller, die sich aber durchaus mit den Punkten in den oben von mir verlinkten "Handlungsempfehlungen" des BSI in Übereinstimmung bringen lassen (auch wenn dieses Dokument jünger ist als meine ausführliche, telefonische und schriftliche Diskussion zu genau diesen Punkten mit jemandem bei AVM) und insofern sehe ich das nicht als "unbillig" an, wenn ich solche Erwartungen auch äußere (ich verheimliche auch nichts, auch mein anfängliches Begehren nach einem "bug-bounty reward" für diese DoS-Lücke ist genauso im GitHub beschrieben wie meine Ablehnung einer angebotenen Aufwandsentschädigung und die Gründe für diese Ablehnung, selbst wenn ich eher kein Freund langer Texte bin) und mir dann nicht einfach widerspruchslos eine Haltung eines Herstellers "auf's Auge drücken" lasse, wenn ich das für eine generell falsche Vorgehensweise (bzw. eher für "nicht mehr zeitgemäß", denn die "Stellung" von SOHO-Routern hat sich grundlegend verändert und in den letzten zwei, drei Jahren setzt sich diese Erkenntnis nun auch in der Öffentlichkeit durch) halte.

Vielleicht (bzw. eher "sicherlich") wird es keine weiteren Aufträge geben, nachdem ich nun meinerseits die Konsequenz auch mal aufbringe (und nicht nur davon schreibe, daß ich es ja könnte), aber ich habe eben nach mehreren Anläufen in irgendetwas zwischen zwei und vier Jahren (je nachdem, wie man zählt - der erste direkte "Kontakt" kam dann erst Anfang Sept. 2014 zustande) absolut keine Lust mehr, mich beim "Nachhaken" immer wieder aufs Neue zu ärgern, wenn keine oder (zumindest nach meiner Ansicht) unzureichende (teils auch unpassende) Reaktionen kommen und habe das ebenfalls schon vor recht langer Zeit (in einer E-Mail vom 04.07.2016, als ich nach drei Wochen wieder einmal für ein Problem nachfragen mußte, für das es bis auf eine (standardisierte) Eingangsbestätigung der E-Mail keinerlei Reaktion bis zu diesem Zeitpunkt gab) ggü. AVM ganz unmißverständlich zum Ausdruck gebracht, bevor ich dann auf die Strategie "AVM macht's nach eigenem Gusto, warum dann nicht auch ich?" gewechselt bin.

Solange mein Verhalten "branchenüblich" ist (und ich versichere bzw. denke, daß ich keine "Forderungen" erhoben habe, die nicht ohnehin "empfohlen" werden vom BSI), kann man mir da auch keinen Vorwurf machen - man kann mir gerne seine (logischerweise auch abweichende) Meinung mitteilen und mit mir darüber dann diskutieren ... aber "nach Ansage" einer Seite i.V.m. "Totstellen" bei Rückfragen geht es (zumindest bei und mit mir) definitiv nicht (mehr). Eine Orientierung an Google's "Project Zero" ist sicherlich nicht vollkommen falsch und 90 Tage sind in der heutigen Zeit eine Frist, innerhalb der man sich einiges an Gedanken machen kann.

Wenn das dann mit AVM's Update-Strategie kollidiert, kann man ja vielleicht auch einfach einmal die Frage stellen, ob nicht doch diese Strategie dann die falsche sein könnte. Stellt man dann darauf ab, daß die Struktur des FRITZ!OS (also die Umsetzung als Monolith ohne jede Möglichkeit der Änderung/Überlagerung des R/O-Dateisystems) eben keine partiellen oder inkrementellen Veränderungen zuläßt und somit für "quick fixes" nicht geeignet ist, dann muß man den nächsten Schritt auch noch wagen und vielleicht mal die Struktur überdenken oder man setzt dann eben auf andere Mechanismen (mit dem "PluginV2" beim WLAN der 7390 zeigt AVM ja, daß man auch weiß, wie das geht - notfalls kann man (zumindest bei einigen Modellen) auch das yaffs2-Dateisystem in der FS-Partition noch verwenden, wie ich das beim "modfs-Starter" mal gezeigt habe und selbst regelmäßig einsetze, auch im "modfs" gibt es dafür Unterstützung) mit höherem Aufwand.

Im Moment ist jedenfalls AVM denkbar schlecht aufgestellt, wenn es um die Möglichkeiten zur Reaktion auf Security-Probleme geht ... was z.B. bei einem plötzlich auftauchenden Problem in "OpenSSL" passieren müßte (das letzte Advisory von dort kam diese Woche, wenn ich mich nicht irre; die von AVM verwendete 1.0.1t ist vom 03.05.2016 und war schon zum Zeitpunkt des Erscheinens der 06.80 beim "end of support" angelangt - das war für den 31.12.2016 bereits seit langer Zeit angekündigt), habe ich irgendwo schon einmal geschrieben. Irgendwelche Ansätze für grundlegende Veränderungen sind nicht zu erkennen oder dringen zumindest nicht bis an die Öffentlichkeit durch ... es wird einfach "weitergewurstelt" wie in den seligen Zeiten, wo die Leute es noch als sehr angenehm empfanden, wenn sie neue Funktionen mit der Firmware in schöner Regelmäßigkeit erhielten.

Heute werden aber eben auch die Rufe nach sicherer Firmware lauter, weil auch die Kunden zunehmend erkennen, daß diese immer größere Bedeutung erlangt - sogar bis in "die Politik" (aka BSI) hat sich das herumgesprochen, daß ein (wachsender) Bedarf an sicheren Routern besteht und dort gibt es Bestrebungen, die "Bevölkerung" dabei zu unterstützen (ich verlinke die "Testkriterien" jetzt nicht noch einmal). Hier mag AVM sogar "primus inter pares" sein (oder "prima", nicht mit dem gleichlautenden deutschen Wort zu verwechseln), aber nur weil alle anderen grottiger sind (jetzt kommt bestimmt wieder irgendjemand mit "OpenWRT" oder gar "pfSense" um die Ecke, aber die meine ich ausdrücklich nicht, weil die eben nichts für den "Heimgebrauch" sind und auch, weil sie eben lange nicht denselben Funktionsumfang besitzen, was für viele Konkurrenz-Router auch gilt), muß man sich ja nicht auf den Lorbeeren ausruhen - das war erst die erste Runde und noch nicht der Schlußgong.

Solange das eine aber das andere ausschließt (also diese schöne Regelmäßigkeit sich auf die (umgehende) Wiederherstellung der Sicherheit negativ auswirkt, weil der einzige Updatepfad das Warten auf das nächste "major release" ist, solange eine Lücke noch(?) nicht aktiv auf breiter Front ausgenutzt wird und damit für ein "Notupdate" die Voraussetzungen vorliegen), gehöre ich zu der Fraktion, die lieber auf die Unterstützung irgendwelcher netter "Smart Home"-Gimmicks verzichtet (und das für die Aufgabe eines "Smart Home Hubs" hält) und stattdessen einen funktionsfähigen Router (meinetwegen mit NAS und Mediaserver für den "kleinen Haushalt", dann aber eben auch sicher und nicht "hingerotzt" oder nach dem Motto "ist halt ein Consumer-Gerät, das muß nicht sicher sein"), der auch bei der Umsetzung von Sicherheitsfunktionen gut durchdacht ist. Hier bestreite ich auch nicht, daß es bei AVM tatsächlich entsprechende Bestrebungen und Fortschritte gibt und gute Ansätze vorhanden sind, aber es gibt eben auch andere Stellen, wo man sich - zumindest nach meiner Ansicht und die habe ich anderswo auch begründet - deutlich zu wenige Gedanken über die "Lebenswirklichkeit" bei den Kunden gemacht hat (Stichwort "vorgegebenes GUI-Kennwort") und wo dann aus "gut gemeint" im Handumdrehen ein "schlecht gemacht" resultiert.

Am Ende ist dann auch die "Wartbarkeit" des FRITZ!OS und die Austauschbarkeit einzelner Komponenten (modulares Design) ein Sicherheitsmerkmal ... nur dann kann man auf plötzlich auftauchende Probleme auch souverän reagieren, weil ein derartiges Design bereits bei der Entwicklung verlangt, daß man nur definierte Schnittstellen zwischen den Komponenten verwendet (dafür gibt es ja Interfaces) und dann kann man auch eine Version einer Komponente einzeln gegen eine fehlerbereinigte Version austauschen (mit wesentlich geringerem Aufwand und Risiko als bei einem "monolithischen Update"), solange diese neue Komponente den "Vertrag" nach wie vor einhält. Das bringt AVM ja auch an anderen Stellen vorwärts, wenn man dann bei unterschiedlicher Ausstattung zweier Modelle leichter die Komponenten für die vorhandene Hardware kombinieren kann und das alles als getrennte "units" sich viel besser isoliert testen läßt. Das könnte vielleicht sogar an einigen Stellen schon umgesetzt sein, schaut man sich dann aber einige binäre AVM-Komponenten an (einfach nur die enthaltenen Zeichenketten mittels "string"), dann gibt es in einer DSL-Box auch (ungenutzte) LTE- und DOCSIS-Teile - hier kann also nicht wirklich ein modulares Design umgesetzt sein.

Es gibt so viele Möglichkeiten für solche "quick fixes" inzwischen (sogar das Patchen des laufenden Kernels wird bei echten Servern praktiziert, da braucht so etwas nicht einmal einen Neustart - auch wenn das bei der FRITZ!Box kein Thema ist), da muß man sich nur mal eine aussuchen. Das geht bei der Verwendung von "overlays" in Zusammenarbeit mit einem SquashFS-Dateisystem schon los (viele der Linux-Systeme "vom Stick" arbeiten auf diese Weise und ermöglichen mit einem OverlayFS die Speicherung von eigenen Einstellungen und von Updates für Pakete aus dem SquashFS) und endet dann bei "geschützten Bereichen" im NAND-Flash (selbst die neueren Boxen ohne NAS haben irgendwo Speicher für den AB und die "FRITZ"-Verzeichnisse, zumindest kleinere Updates kriegt man da auch unter), die man dann aber eben auch wirklich schützen muß, damit man nicht wieder ein neues Loch aufreißt (da käme ich dann wieder auf den Media-Server und die "bpjm.data" zurück) und die dann in der Suchreihenfolge nach Programmen eben vor dem SquashFS rangieren müssen. Wie gesagt ... in Abhängigkeit vom Ziel gibt es immer mehrere Wege mit entsprechenden Vor- und Nachteilen, die muß man dann eben gegeneinander abwägen.

So, das war wieder mal (zumindest am Ende) ein "Grundsatzstatement" und die Pferde sind wieder etwas mit mir durchgegangen ... aber ich wollte hier ja gar keine wirklichen Diskussionen entfachen bzw. nicht daran teilnehmen. Das Fleisch war willig ... aber der Geist war schwach.

H'Sishi schrieb:

Wie ist das eigentlich mit Sicherheitslücken, die z.B. im Rahmen eines CCC-Workshops demonstriert werden? Werden die auch der breiten Öffentlichkeit dokumentiert und zur Ausnutzung zugänglich gemacht?

Zum Vergrößern anklicken....

Das kommt sicherlich darauf an, wie man das interpretiert und eben auch, wie weit die "Vorkenntnisse" desjenigen gehen, der so eine Demonstration dann verfolgt ... schau Dir einfach die Slides zum Vortrag von A. Graf vor etwas mehr als einem Jahr an (es ging um Probleme bei der Provisionierung von DOCSIS-Geräten im VF/KDG-Netz) und urteile selbst, inwieweit man anhand der Beschreibungen (das geht bis zur "Erklärung", wie das Kennwort per Hash ermittelt wird, wenn ich mich richtig erinnere) selbst in der Lage ist, das Problem nachzuvollziehen.