Ja, der Gedanke war vermutlich auch vorhanden - wobei das hier wegen der Möglichkeit von externer Auslösung schon noch etwas anderes ist und bei
einer anderen Lücke habe ich 114 Tage nach der Meldung (und mehrfachen Erinnerungen, daß da noch eine Reaktion aussteht) das ja bereits einmal praktiziert. Aber das war vielleicht schon zu spät, um wirklich als deutliches Signal meinerseits wahrgenommen zu werden.
Ich habe mich aber in der Antwort an AVM auf die letzte Mail (hoffentlich) deutlich genug geäußert und unmißverständlich klargestellt, daß ich das künftig nicht mehr unnötig hinauszögere. Wenn AVM einer Lücke eine "mittlere Dringlichkeit" attestiert und daraus resultiert eine Verschiebung auf das nächste Major-Release (wobei mich beim Base-Score von 7.5 für #515119 schon die Frage plagt, wo AVM die Grenze für eine "hohe Dringlichkeit" zieht) und dieses liegt außerhalb der 90 Tage + "Gnadenfrist" bei Zusage der zeitnahen Veröffentlichung, dann kommt das "auf den Tisch".
Wenn AVM sich bei der Einschätzung irrt, ist das nicht mein Problem und wenn es wieder mal zu lange dauert bis zum nächsten "major release", dann gibt es ja vielleicht wirklich irgendwann mal auch von AVM so etwas wie ein monatliches (wie bei MS, Adobe, usw.) oder zumindest vierteljährliches Update (wie bei Oracle), in dem die Erkenntnisse der letzten drei Monate (das macht dann sogar noch die bewußte "Verlängerung" möglich für Meldungen, die innerhalb der letzten Woche vor Redaktionsschluß eingehen) in Form einer "noch besseren Firmware" (da lasse ich das dann auch gelten) gipfeln.
Den neuen Termin für den Exploit (so langsam klingt das sogar viel zu hochtrabend, wenn man erst einmal weiß, wie banal das am Ende ist) wird jedenfalls auch kein weiterer Appell von AVM an mein Gewissen verschieben, abgesehen davon gibt es gar nicht genug Modelle, die man noch in der gleichen Frequenz mit einem Update versorgen könnte, damit das nicht nach 14 Tagen dann ebenfalls als Argument entfällt.
Mir wurde ja aufgetragen, in dieser Richtung einfach einmal selbst zu recherchieren und so bin ich eben ganz naiv den leichten Weg gegangen und habe abgezählt, wieviele FRITZ!Boxen es der AVM-Seite nach gibt (bei Produkte), das kommt - inkl. DOCSIS, LTE und "Glasfaser" - auf 16 Modelle.
Wobei ich das bei der 5490 zu lesende
Exklusiv vom Provider
Die FRITZ!Box 5490 ist für Glasfaseranschlüsse optimiert und wird von vielen Netzbetreibern angeboten.
auf der deutschen Version der Seite auch schon wieder für Wunschdenken halte ... vielleicht kennt ja tatsächlich jemand wenigstens einen deutschen Glasfaser-Provider, der auch die 5490 im Angebot hat? Ansonsten muß man die vielleicht wieder abziehen. Vielleicht in der Schweiz (da kenne ich tatsächlich einen Provider, der einen Feldtest gemacht hat) oder in den Niederlanden, wie mal angekündigt? Wobei die sich dann auch alle sehr zurückhalten müssen beim Bewerben dieses Angebotes, die Suche bei Google bringt da nicht wirklich Ergebnisse (oder ich stelle mich nur zu dumm an).
Läßt man dann mal eine Suche auf die Dateien auf dem AVM-FTP-Server los (einfach per "find -ls" über "ftpfs" erstellt), sieht das im Moment so aus:
Code:
# grep -r "[A-Za-z]\{3\}[ \t]*[0-9]\{1,2\}[ \t]*[0-9]\{1,2\}:[0-9]\{1,2\}" /tmp/avm.ftp.files | grep "\(Jan\|Feb\)" | grep ".*\.image\$"
397 23812 -rw-r--r-- 1 root root 24381440 Feb 2 13:13 /ftp/avm/fritzbox.3490/firmware/deutsch/FRITZ.Box_3490.140.06.80.image
545 23272 -rw-r--r-- 1 root root 23828480 Feb 2 17:43 /ftp/avm/fritzbox.7362_sl/firmware/deutsch/FRITZ.Box_7362_SL.131.06.80.image
565 20412 -rw-r--r-- 1 root root 20899840 Feb 9 19:20 /ftp/avm/fritzbox.7412/firmware/deutsch/FRITZ.Box_7412.137.06.80.image
574 23252 -rw-r--r-- 1 root root 23808000 Feb 13 15:07 /ftp/avm/fritzbox.7430/firmware/deutsch/FRITZ.Box_7430.146.06.80.image
592 26420 -rw-r--r-- 1 root root 27054080 Jan 23 14:03 /ftp/avm/fritzbox.7490/firmware/deutsch/FRITZ.Box_7490.113.06.80.image
595 26872 -rw-r--r-- 1 root root 27514880 Feb 3 13:55 /ftp/avm/fritzbox.7490/firmware/deutsch_a-ch/FRITZ.Box_7490.en-de-es-it-fr-pl.113.06.80.image
598 26872 -rw-r--r-- 1 root root 27514880 Feb 3 13:54 /ftp/avm/fritzbox.7490/firmware/english/FRITZ.Box_7490.en-de-es-it-fr-pl.113.06.80.image
634 23012 -rw-r--r-- 1 root root 23562240 Jan 30 10:03 /ftp/avm/fritzbox.7560/firmware/deutsch/FRITZ.Box_7560.149.06.81.image
640 22992 -rw-r--r-- 1 root root 23541760 Jan 31 13:44 /ftp/avm/fritzbox.7560/x_misc/deutsch/firmware_alt/FRITZ.Box_7560.149.06.80.image
647 23592 -rw-r--r-- 1 root root 24156160 Jan 25 18:03 /ftp/avm/fritzbox.7580/firmware/deutsch/FRITZ.Box_7580.153.06.81.image
653 23592 -rw-r--r-- 1 root root 24156160 Jan 31 13:18 /ftp/avm/fritzbox.7580/x_misc/deutsch/firmware_alt/FRITZ.Box_7580.153.06.80.image
1160 20052 -rw-r--r-- 1 root root 20531200 Feb 6 15:22 /ftp/avm/fritzbox.fon_wlan_7360_v2/firmware/deutsch/FRITZ.Box_Fon_WLAN_7360.124.06.80.image
1187 17220 -rw-r--r-- 1 root root 17633280 Feb 8 15:05 /ftp/avm/fritzbox.fon_wlan_7390/firmware/deutsch/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.80.image
Das sind also schon mal 9 verschiedene Modelle in dieser Liste (auf der "Produkte"-Seite sind es 16 oder 15), die bereits das Update erhalten haben und wenn AVM das in dieser Frequenz fortsetzt, sollten die Updates für die verbleibenden 7 oder 6 Modelle in (inzwischen) 12 Tagen sicherlich existieren. Daraus sollte sich also kein Grund für eine weitere Verschiebung ergeben.
Ob AVM dann generell so "angepisst" ist, daß man mir überhaupt nicht mehr auf Meldungen von Schwachstellen antwortet, werde ich auch in Kürze wissen, da ich in der Mail vom 10.02.2017 03:49 Uhr
diese Lücke detaillierter beschrieben habe, da ja nunmehr die nächste Version erschienen ist und die (m.E. schon im Dez. 2014 mitgeteilte) Schwachstelle nach wie vor vorhanden ist.
Damals war das mehr eine Randnotiz, weil es noch ganz andere Möglichkeiten der Ausführung eigener Kommandos auf einer FRITZ!Box gab (wir erinnern uns alle an den Telnet-Zugang), heute ist es eben eine RCE-Lücke, weil "remote" zur FRITZ!Box eben auch das LAN ist und nicht nur die WAN-Seite (wobei das sogar hier funktionieren würde, aber eben nicht ohne entsprechende Rechte - hoffentlich jedenfalls).
Jedenfalls werde ich es ja merken, ob AVM es für notwendig erachtet, mir für diese Schwachstelle eine Incident-Nummer zuzuweisen - bisher sind zwei Werktage vergangen, ohne daß ich entsprechende Nachricht von AVM erhalten hätte. Mein "Gang an die Öffentlichkeit" nach der letzten Mail trägt sicherlich auch ein Übriges zum Verdruß bei ... ich lasse mich einfach überraschen und die größte Überraschung wäre es dann, wenn sich AVM tatsächlich öffentlich (hier oder anderswo) äußert oder "Schritte macht".
[ Ich falle jedesmal fast vom Stuhl vor Schreck, wenn ich bei der "Durchsicht" von "social media activities" (der Gedanke kam mir jetzt bei der Überlegung, wo AVM so etwas machen könnte, ohne daß es nur als "Proklamation" daherkommt, auf die niemand reagieren kann) die immer gleichen Texte bei Facebook lese, mit denen z.B. die "interessanten Vorschläge an die Entwicklungsabteilung weitergegeben" wurden, denn da habe ich immer ein déjà-vu - bis ich dann in alte E-Mails schaue und wieder weiß, daß das gar keine Sinnestäuschung, sondern tatsächlich eine Wiederholung von Geschichte(n) ist - halt in einem anderen Medium.
So ist jedenfalls mein (auch ab und an mal unvoreingenommener) Eindruck, wenn ich mir das aus reinem Spaß mal antue, wobei die AVM-Facebook-Seite vom "redaktionellen Inhalt" her ja mehr ein Billboard für Links auf Artikel auf avm.de ist und somit die "verschiedenen Kundenströme" dann doch nur wieder irgendwo "abgeholt" werden, um am Ende an derselben Stelle zu landen mit genau derselben "Ansprache" und denselben Inhalten, was irgendwie auch nicht in mein (Marketing-)Weltbild passen will - aber wenigsten muß sich keine Kundengruppe diskriminiert fühlen, da kriegen alle nur dasselbe. ]
Ich diskutiere da jedenfalls auch in der Zukunft nicht mehr lange - wenn ich nach 28 KT keine zweite Reaktion erhalten habe (das habe ich AVM schon am 04.07.2016 per E-Mail verdeutlicht), sehe ich die Meldung als "abgehakt" an und die Policy mit den 90 (+ 15) Tagen ist dann ebenfalls hinfällig; die gilt nämlich nur für den Fall, daß der Hersteller auch reagiert - das ist genauso Teil von "responsible disclosure" und die "Empfehlungen" zur Reaktionszeit kann jeder wieder in den BSI-Dokumenten nachlesen.
Da sind 4 Wochen schon wieder sehr langmütig - wenn in dieser Zeit keine Beschäftigung mit der Meldung erfolgte und keine Einschätzung zur Relevanz vorliegt (die darf auch gerne einen CVSS-Wert beinhalten, dann kann man das besser nachempfinden), dann
kann das Problem nicht groß genug sein, als daß es weiterer Kommunikation bedarf und kann unter "Randnotizen" in der Grube mit den anderen "Sünden" landen und als (gutes oder schlechtes) Beispiel öffentlich verwurstet werden, wenn es daraus etwas zu lernen geben könnte. Für eine reine "Eingangsbestätigung" halte ich schon eine Woche für sehr lang (und das erlaubte Maximum) ... das geht auch wieder nicht nur mir so, das habe ich irgendwo auch in einer PDF-Datei gelesen.
-Vielleicht OT, aber vielleicht doch nicht so ganz ...
Ich habe parallel noch einmal nachgesehen, was wirklich jeweils zu behobenen Problemen "verlautbart" wurde ... und siehe da, das waren am Ende alles "Sicherheits
verbesserungen". (EDIT: bei der 06.80, nicht in der gesamten AVM-History.)
Nun macht es ja einen gewaltigen Unterschied, ob man etwas Gutes noch weiter verbessert oder ob man etwas Kaputtes dadurch "verbessert", daß man es erst einmal repariert.
Das ist eben ein weiteres Beispiel dafür, wie AVM in Bezug auf Sicherheitsprobleme der Firmware permanent mauert (solche Probleme sind nun mal keine Schande und wer einer Firma wirklich glaubt, ihre Software wäre rundum sicher, dem ist ohnehin nicht zu helfen bzw. der hat halt keine Ahnung) und das nicht nur beim konkreten Benennen von Problemen, sondern schon beim Vermeiden jedes Eindrucks, etwas könnte "schlecht" sein bei AVM ... dort ist alles nur "gut" und alles das, was mit "gut" nicht ausreichend gewürdigt ist, ist dann besser. Das hatten wir letzens erst bei der Gegenüberstellung der Eigenschaften der beiden WLAN-Bänder auch schon.
Aber bei der Beurteilung des vorhergehenden Zustands ergibt es eben einen erheblichen Unterschied, ob man ein Sicherheits
problem behoben hat oder etwas zuvor "nicht Problembehaftetes" tatsächlich nur besser machte und schon bei solchen Kleinigkeiten geht es eben bei AVM los. Ich behaupte ja schon seit langer Zeit, daß man sich bei AVM (häufig jedenfalls) sehr genau überlegt, was man da schreibt und das am Ende so lange hin und her schiebt, bis es nie vollkommen falsch ist, aber beim Leser dann doch der falsche Eindruck fast unvermeidlich ist.
-Insofern hast Du vermutlich sogar Recht ... ich hatte bisher immer zuviel Geduld. Jetzt brauche ich halt nur noch einen Mechanismus, wie man sowohl die (vertrauliche) Meldung an den Hersteller als auch die rechtzeitige Veröffentlichung nicht behobener Schwachstellen auf einen Schlag erledigen kann, ohne sich dann erneut mit einer gefundenen Lücke befassen zu müssen (und das ggf. zu vergessen) und für das "responsible" und die eingeräumte Zeit zur Behebung zusätzlichen
eigenen Aufwand zu generieren.
Bei solchen Angeboten wie
HackerOne macht AVM ja nicht mit und
Open Bug Bounty hat ein
Imageproblem und kümmert sich auch in erster Linie um Webseiten, was hier ja nicht der Fall ist. Da gehen mir dann die Ideen auch etwas aus ... vielleicht wäre es ja tatsächlich auch für AVM mal eine Überlegung wert, sich eine "disclosure policy" zuzulegen und diese dann auch so zu veröffentlichen, daß man sie finden kann.
Aber dazu bräuchte es auf der anderen Seite ja auch wieder das "Eingeständnis", daß man tatsächlich nicht perfekt ist und daß es so viele Probleme geben
könnte, daß man diese einer "geordneten Bearbeitung" zuführen muß.
Im Moment klappt vermutlich nicht einmal die Zuordnung von Incidents zu Findern vernünftig ... bei der Nachfrage von AVM, wie ich denn gerne genannt werden möchte, wenn man derartige Danksagungen dann veröffentlicht, waren von 7 gemeldeten und von AVM schriftlich bestätigten Incidents aus der Zeit seit Juni 2016 gerade einmal 4 als potentielle "Kandidaten" aufgeführt. Einer von diesen sieben wurde zwar bestätigt und seine Behebung angekündigt, das führte aber noch nicht dazu, daß das auch wirklich Eingang in die Firmware fand - den könnte man also noch als "unklar" bei der Zuordnung einstufen.
Auch die (öffentlich gemachten) Gedanken und Vorkehrungen in so einer "disclosure policy" gehören eben dazu (auch wirklich Große wie Microsoft oder Apple haben das inzwischen begriffen und sogar von Netgear gibt es inzwischen etwas in dieser Richtung) ... genauso wie das Einhalten von Terminen für Wiedervorlage und die (herstellerseitige) Information der Finder, wenn sich zuvor gemachte Zusagen aus irgendwelchen Gründen verschieben. Es kann ja nicht so schwer sein, anhand einer Datenbank mit den zu behebenden Schwachstellen und auf der Basis der E-Mail-Adressen von deren Findern beim Verschieben irgendwelcher Termine entsprechende E-Mails zu generieren ... das machen Spam-Versender jeden Tag millionenfach.
Wobei die gemachten Angaben bisher ohnehin meist so vage sind, daß man sie in der Pfeife rauchen kann, denn was sagt ein Satz wie "Wir planen das Release ca. Q3/2016." in einer Mail vom 05.07.2016 eigentlich genau aus ... er bringt nur einen (vermutlich unverwüstlichen) Optimismus zum Ausdruck, denn mir kann niemand ernsthaft einreden, daß man in den verbleibenden drei Monaten (davon gehen vermutlich noch die Sommerferien in Berlin ab, wenn ein Großteil der Mitarbeiter Kinder im passenden Alter hat) tatsächlich davon ausging, innerhalb des Q3 eine neue Version an den Start zu kriegen - den "Ist-Stand" am Beginn von Q3 sollte man da ja schon gekannt haben.
-Egal ... ich gerate schon wieder ins Träumen; aber ich wage mal die Hypothese, daß sich AVM in den nächsten zwei bis drei Jahren einiges überlegen muß, denn die "security domain" einer FRITZ!Box ist eben nicht mehr (wie das früher der Fall war) die Box selbst und das LAN, sondern nur noch die Box. Alles andere ist (in Zukunft mit jedem weiteren IoT-Gadget) sogar Feindesland und im Prinzip nicht anders zu behandeln (wenn es um den Zugriff auf die Box selbst geht und nicht um "transit"), als jeder Zugriff auf der WAN-Seite.
Das beginnt zwar als Erkenntnis um sich zu greifen (einige Verbesserungen wie die 2FA zeigen eben, daß man sich nicht mehr nur auf Benutzername/Kennwort bzw. SID verlassen will, wenn es um den Zugriff auf die Box geht), aber es geht (nicht nur für mich, sondern objektiv) einfach zu langsam (nochmal, andere Hersteller sind noch schlechter, das schützt aber die FRITZ!Boxen noch lange nicht davor, auch angegriffen zu werden und da interessiert es im Erfolgsfall "keine Sau" mehr, daß der Router beim Nachbarn aber viel schlechter abgesichert gewesen wäre) und so wird man von der Entwicklung einfach überrollt.
Dann kommen eben auch noch "handwerkliche Fehler" dazu, denn mir kann niemand wirklich einreden, daß irgendjemand die Entscheidungen bei der 2FA noch einmal in einem größeren Kreis von Leuten, die sich mit dem FRITZ!OS auskennen, diskutiert hat. Wenn in so einem Kreis tatsächlich nicht aufgefallen wäre, daß zwar der Export der Einstellungen über die 2FA abgesichert ist, aber weder das Setzen des Flags für die "erweiterten Supportdaten" noch das Ausgeben der eigentlichen Support-Datei und daß damit die kompletten Einstellungen genauso gut zu entwenden wären, dann stimmt etwas an der Zusammensetzung dieses Kreises oder an der Intensität der Beschäftigung mit dem Thema nicht. Ich konnte jedenfalls bei meiner 7490 ohne jedes Problem die Einstellungen auf der Support-Seite ändern und die Datei abrufen, obwohl die Sitzung "frisch" war und die Box die 2FA aktiviert hatte. Und so etwas zähle ich dann tatsächlich zu "handwerklichen Fehlern", wenn das weder in der Entwicklung noch in der QS auffällt - auf die (plausible) Erklärung dafür wäre ich einfach auch mal gespannt. Das ist zwar keine "neue" Lücke, aber eine, die neu eingeführte Maßnahmen zu einem guten Teil ad absurdum führt ... außer man war "noch nicht fertig"; dann stellt sich halt die Frage, warum man dann nicht erst "fertig gemacht hat".
Wenn der Kunde bei sich jedenfalls daheim eine "security cam" installiert (die Dinger gibt es beim Discounter) und die bohrt sich erst einmal einen Tunnel durch die FRITZ!Box zu irgendeinem Server des Herstellers (möglichst noch durch eine eigene Portfreigabe und nicht nur durch die selbst aufgebaute TCP-Verbindung), damit der Kunde die "von überall" per App steuern kann, dann ist zumindest schon mal die Frage nach dem "relay" im LAN für einen Angriff auf die FRITZ!Box beantwortet, wenn man sich einige dieser Gerätschaften so ansieht (und wieviel Ahnung hat der durchschnittliche Benutzer davon, warum das eben nicht nur eine Komfortfrage ist).
Und so wird das weitergehen ... die (schlecht konfigurierte) Set-Top-Box mit Enigma2 und ins Internet freigegebenem HTTP-Interface ist genauso ein potentielles Ziel wie irgendein FireTV-Stick oder irgendein anderer HDMI-Stick mit entsprechenden Fähigkeiten ... bis hin zum Smart-TV mit Android-System und Zugang zu irgendwelchen "verseuchten" App-Stores. Wenn die Ransomware nicht mehr den
Fernseher ins Visier nimmt, sondern eine Schadsoftware den Router angreift, dann muß der sich eben "wehren" können bzw. bereits zu diesem Zeitpunkt so "gehärtet" sein, daß er der Malware keine (bekannte) Angriffsfläche bietet.
Die "normalen Leute" haben doch heute gar keine Ahnung mehr von den Risiken, die mit neuen Geräten einhergehen (müssen sie auch nicht haben) und so muß man eben auch auf der LAN-Seite eines so zentralen Gerätes, wie es ein Internet-Router im Haushalt nun einmal ist, dafür sorgen, daß da entsprechende Sicherheit vorhanden ist. Das sehe ich eben bei der FRITZ!Box noch lange nicht erreicht ... und das angesichts der Tatsache, daß man ja - immer unter der Annahme, daß die kolportierten Zahlen stimmen - in Deutschland bei den privaten Internetzugängen schon so etwas wie eine "Monokultur" bei den Consumer-Routern hat.
Wenn ich das richtig in Erinnerung habe, waren das bei der Telekom bei der Speedport-Geschichte weniger als 1 Mio. betroffene Geräte ... man stelle sich jetzt einfach einmal vor, über eine Sicherheitslücke im FRITZ!OS könnten unbemerkt 25% der (als Hausnummer) 20 Mio. FRITZ!Boxen in Deutschland übernommen werden durch die Installation einer eigenen Firmware des Angreifers. Das wären dann 5 Mio. Bots, die auf Zuruf an ihrem Anschlüssen (die im Upstream irgendwas zwischen 1 MBit/s und 40 MBit/s schaffen) Datenverkehr erzeugen könnten, der nicht nur jedes Providernetz hoffnungslos überlastet (da muß man dann noch fast "zum Glück" schreiben, weil so ein Engpass im Providernetz natürlich die weiteren Auswirkungen begrenzt), sondern wohl auch so ziemlich jede öffentliche oder gesellschaftlich relevante Webpräsenz ohne jede Diskussion aus dem Netz wirft. Der (m.W.) bisher heftigste
DDoS-Angriff im vergangenen Jahr soll es auf 1,5 TB/s gebracht haben bei ca. 1 bis 1,5 Mio. gekaperten Geräten. Das ist also auch eine richtige "Macht", die so einem Angreifer damit in die Hände geraten kann und ...
da trägt dann in der heutigen Zeit eben auch ein Router-Hersteller (denn das sind genau die Geräte, die 24/7 in den Privathaushalten ununterbrochen laufen) eine gehörige Portion Verantwortung, der er auch gerecht werden muß. Dazu gehört für mich auch der offene Umgang mit diesem Thema und nicht das "Einschläfern" der Kunden durch ein "Eiapopeia, wir machen das schon alles für Euch und verbessern das auch ständig nur, Probleme gab es erst einmal (oder zweimal, wenn man den UPnP-Bug zuvor dazurechnet) in der Firmengeschichte." - insofern spielt eben sogar das "wording" beim Formulieren einer Pressemitteilung oder einer Ankündigung einer neuen OS-Version auf der eigenen Webseite eine Rolle, ob die Botschaft klar und deutlich ins Bewußtsein der Adressaten gelangt oder nur das übliche Gesäusel ist.
Wie gesagt ... bisher ist das alles noch Spaß, weil sich niemand wirklich die Mühe macht. Mit einem kabelgebundenen Computer an einer FRITZ!Box (das kann auch der RasPi sein, wenn man es nur demonstrieren will) ist aber die Übernahme einer FRITZ!Box (bei jedem Start dieser FRITZ!Box) kein wirkliches Problem (bei einer DOCSIS-FRITZ!Box vielleicht noch) und auch bei einem WLAN-Angreifer lassen sich noch genug Mittel und Wege finden, Schwachstellen der FRITZ!Box auszunutzen (hier halt nicht so einfach wie beim Start mit dem LAN-Kabel).
Auch unter diesem Aspekt ist es eben in meinen Augen falsch, wenn AVM den Boxen immer mehr Funktionen aufhalst mit jedem neuen Update und der Kunde muß die "schlucken" (ggf. sogar mit neuen Lücken), anstatt daß man mindestens denselben Aufwand in die Behebung erkannter Schwachstellen investiert und neue Funktionen erst von einer wirklich sicheren Basis aus in Angriff nimmt.
Es gäbe noch so vieles in puncto Sicherheit auf der LAN-Seite zu tun ... das geht beim nicht mehr optionalen HTTPS-Zugriff auf das GUI los (damit eben niemand eine SID einfach beim "Sniffen" erbeuten kann), zieht sich über die (m)DNS-Implementierung bis zu den APIs und einer ordentlichen Trennung zwischen "System" und "Benutzer" bei den Dateien im NAS-Speicher (womit dann meine aktuellen Lieblingsthemen mal kurz und knackig angerissen wären), da könnte man AVM vermutlich mind. zwei Monate alleine mit den offensichtlichen Problemen beschäftigen und braucht dazu gar keine neuen Funktionen, die auch erst einmal neue Probleme mit sich bringen und dann bei einigen Kunden durch Fehlfunktionen sogar das Update auf eine sichere Version verhindern. Das soll jetzt auch nicht heißen, daß ich genug Schwachstellen für 2 Monate Arbeit kenne, aber für 2 Wochen (bei AVM vermutlich auf mehrere "Zuständigkeiten" verteilt) reicht es vermutlich schon und dann muß man ja nicht immer warten, bis neue Schwachstellen "von außen" gemeldet werden, man kann die ja auch selbst aktiv mit "code reviews" (oder auch dem Überdenken alter Design-Entscheidungen) versuchen zu bekämpfen. Sollte das tatsächlich (auch mit den notwendigen Nachdruck) bereits passieren, stellt sich die Frage, warum man von außen immer wieder so viele (teils auch banale) Probleme finden kann - wenn die "internen" Tester dann (mit dem Vorteil der Kenntnis von vorhandenem Code ausgestattet) auch in entsprechender Frequenz Lücken aufzeigen und schließen lassen, dann ist es um das FRITZ!OS aber noch schlechter bestellt, als ich es als "Schwarzseher" (ich meine meinen Pessimismus, nicht meinen Fernsehkonsum) für wahrscheinlich halte.
Gibt es irgendwann mal die Sicherheitsupdates gesondert, stellt sich das Problem ungewollter Änderungen auch nicht mehr und vor allem können solche Updates dann auch schon ausgeliefert werden, wenn die neuen Funktionen (ganz unerwartet, das konnte ja niemand ahnen) doch wieder länger brauchen als vorgesehen. So ganz ideal funktioniert ein "agiles" Vorgehen bei einer Firmware ja vielleicht doch nicht ... da, wo bei einem Werksvertrag dann halt der einzelne Kunde mit dem Ergebnis leben kann und muß, wenn Zeit und Budget aufgebraucht sind, da ist ein einzelner "product owner" (auch wenn das vielleicht der Produkt-Manager sein mag, wobei ich da schon wieder "Konflikte" sehen würde, wenn sich der für die 7490 und die 7580 zuständige PM in die Haare kriegen, wessen Produkt denn nun "attraktiver" sein soll, weil ggf. die eigenen Boni davon abhängen) stellvertretend für ca. 20 Mio. Kunden (oder meinetwegen auch nur 10 Mio., wenn der Rest noch ältere Modelle (die dann auch gleich wieder angreifbarer sind) verwenden sollte) dann vielleicht doch etwas überfordert ... wobei natürlich für Security-Fixes sich die Frage "Schaffen wir das bis zum Release noch oder nicht?" gar nicht erst stellen dürfte - nicht mal für "niedrige Dringlichkeit" (entweder es ist ein Problem, dann muß es auch behoben werden oder es ist keines, aber "ja, eigentlich schon, machen wir dann ..." ist in diesem Fragen einfach keine klare Haltung), weil die in Kombination mit der nächsten (weniger wichtigen) Lücke ganz schnell wieder zum Bumerang werden kann und deren genauen Zeitpunkt kann niemand vorhersagen.
Kein Problem kann ohne passende, eigene Untersuchung als zu klein und irrelevant eingeschätzt werden ... daß sich daraus auch (selbst wenn es nur aus dem LAN und vom berechtigten Admin (vordergründig) ausgenutzt werden kann) ein richtiges Problem ergeben kann (bis hin zur "command injection", die der normale Kunde gar nicht selbst beseitigen könnte), hat ja
diese Lücke bereits gezeigt und das könnte schon der Provider bei einen Leihgerät für den Kunden durchziehen oder eben eine Malware, die einfach auf die vorhandenen Einstellungen pfeift und die Box zurücksetzt beim TFFS-Schreiben (gut, das fällt bei massenhafter Verbreitung dann auch wieder auf, wenn jede Menge Boxen genau einmal die Einstellungen total vergessen und dann nicht mehr "auffällig" werden).