Ich hatte mal versucht, mit den Autoren Kontakt aufzunehmen (etwas schwierig, weil die "embeeded form" auf der Webseite mit dem Report nicht funktioniert(e)) und zu erfahren, welche Modelle denn nun getestet wurden.
Wie ich mittlerweile per E-Mail erfuhr, war die Quelle für das getestete Portfolio tatsächlich im Dokument enthalten ... in der Fußnote 1 auf Seite 2. Das hatte ich irgendwie nicht so richtig verstanden ... sei's drum. Der Link dahin wäre also:
https://github.com/fkie-cad/embedded-evaluation-corpus/blob/master/2020/FKIE-HRS-2020.md und wie man sehen kann, waren damit 10 Modelle von AVM im Portfolio vertreten.
Wie es dabei zur Verteilung der gefundenen Linux-Versionen auf Seite 8 kommt, war damit auf den ersten Blick einigermaßen unklar ... denn bei 10 Geräten gibt es irgendwie keinen Weg, auf 7,7 % für einen Anteil an irgendetwas zu kommen, solange es tatsächlich eine 1:1-Zuordnung zwischen Firmware-Version und Modell gibt.
Aber hier hat das vom FKIE verwendete Verfahren dann so seine Schwächen (bei heise.de steht sogar:
Trotz der recht oberflächlichen Analyse der Fraunhofer-Forscher [...]
- von
https://www.heise.de/news/Keine-Ueb...-Test-Viele-Home-Router-unsicher-4798342.html)
und man sollte nicht verkennen, daß es sich um eine rein statistische Analyse der verwendeten Komponenten handelt und definitiv nicht um "echte" Schwachstellen, die da gefunden wurden und nunmehr von Angreifern ausgenutzt werden könnten.
Denn letztlich macht das FKIE hier nichts anderes, als die vorhandenen Firmware-Versionen (das gilt für alle Hersteller und nicht nur für AVM) so lange zu entpacken und zu analysieren, bis nichts mehr geht. Das m.E. bekannteste Tool dafür wäre "binwalk" (
https://github.com/ReFirmLabs/binwalk) und da das am Ende ein "swiss knife" für das Entpacken von Firmware-Images ist, weiß es von den Besonderheiten der verschiedenen Modelle und Hersteller rein gar nicht - es sucht einfach so lange in den Daten, die man ihm vorsetzt, nach Signaturen irgendwelcher "archive programs" oder nach anderen bekannten Signaturen (ein wenig so, wie es das "file"-Utility unter Linux auch macht), bis es keine mehr findet. Alles das, was es zuvor gefunden hat, wird dann aber auch "blind" entpackt bzw. passend "interpretiert", ohne jede Kenntnis über enthaltene Strukturen.
Wenn ich nichts übersehen/überlesen habe, verwendet auch das FKIE hier "binwalk" für viele Aktionen bei der Analyse, wobei man das um weitere "Kenntnisse" für zusätzliche Formate erweitert hat. Die eingesetzten Tools sind dabei praktisch alle Open-Source und stehen somit jedem zur Verfügung ... für das Entpacken der AVM-Firmware bedient man sich (wie es aus dem Text des Reports auch schon ersichtlich war), der Tools aus dem Freetz-Projekt:
https://github.com/fkie-cad/fact_extractor/blob/master/fact_extractor/install/unpacker.py#L214
Während aber bei Freetz dann eben nach dem Entpacken der AVM-Firmware auch schon Schluß ist und das gesamte OS für die WiSoCs nicht angefaßt wird (z.B. die "ath_tgt_fw2.fw" in der Firmware der 7490), sucht "FACT" (bzw. "fact_extractor") dann eben weiter und findet auch noch das Linux (Kernel 4.4.60 und ein passendes SquashFS-Image) in dieser Datei.
Das erklärt dann wieder, wo die zusätzlichen "Kernel-Versionen" herkommen (das dürften dann wohl doch drei Modelle sein, bei denen die WLAN-Firmware in dieser Form und mit einem Kernel 4.4 im AVM-Image enthalten ist) und auch die Unklarheiten, wie es bei 5 (FRITZ!Box-)Modellen mit Kernel 4.4 (für den "Hauptprozessor") in der gesamten AVM-Modellpalette überhaupt zu sechs Vorkommen eines Kernel 4.4 kommen konnte.
Die Modelle mit einem Kernel 4.4 für das Hauptsystem sind ja dann die 4020, die 4040 und die 7530 gewesen ... wobei die Schwierigkeiten, das System für die 4020 zu entpacken, es für mich etwas unklar machen, wie weit deren Resultate da jetzt in welcher Kategorie das Ergebnis beeinflußten. Theoretisch dürfte man beim FKIE nicht mal erkennen können, daß die 4020 einen Kernel 4.4.60 verwendet, solange man das Dateisystem nicht entpacken konnte - auch "binwalk" identifiziert jetzt einen Linux-Kernel nicht "aus dem Stand" gleich noch mit der passenden Versionsnummer.
Wobei ich fast wetten würde, daß die Images für die Scorpion-WiSoCs überall dieselben sind ... bei der 113.07.12 (also 07.12 für die 7490) hat die enthaltene WLAN-Firmware auch die Version (166.)07.08 und es handelt sich exakt um dasselbe Image, das auch in der 5490 benutzt wird. Da das FKIE hier die 5490 ebenso im Testfeld hatte, wie die 5491 und beide Modelle sogar dieselbe Datei für die WLAN-Hardware benutzen, sind zwei zusätzliche "Linux-Kernel" mit der Version 4.4.60 schon mal erklärt ... welches das dritte Modell ist, kann der interessierte Leser ja mal selbst ermitteln (ich weiß es nicht und habe gerade keine Lust, es zu recherchieren ... offenbar handelt es sich um eines der Modelle, die sonst bei mir eher nicht im Fokus stehen).
Da kein direkter Kontakt zustande kam, ist die Frage, wie man beim FKIE für die AVM-Firmware auf aktives "FORTIFY_SOURCE" kommt, leider immer noch ungeklärt - ich wage mal die Behauptung (eher die These, weil dann das Widerlegen zur "Systematik" zählt
), daß diese Aussage am Ende nur auf der Existenz einiger Namen, die üblicherweise auch bei den "fortified functions" verwendet werden, basiert. Ob dabei bereits die Verwendung der (teilweise optimierten) Builtin-Funktionen des GCC als "FORTIFY_SOURCE" angesehen wird (bei Verwendung dieser Builtins wird dann für manche Funktionen, die man eher in der C-Library suchen würde [z.B. memcmp()] bereits vom Compiler optimierter Code generiert und die Funktion der C-Library gar nicht erst genutzt) und ob man das so sehen muß/sollte, wäre auch noch eine "offene Frage" von meiner Seite.
Aber das basiert im Moment auch nur auf einer Annahme ... ich hatte noch keinen Bock, mich in die Quellen von "FACT" zu vertiefen (und ich hasse Python, das kommt noch dazu - dann schon lieber Fußpilz) und das selbst zu recherchieren, weil ich die Hoffnung hatte, das im Dialog mit den FKIE-Autoren klären zu können. Bisher sieht es nicht danach auch ... schade drum. Also werde ich wohl (bei Gelegenheit) doch mal genauer hinsehen müssen, worauf diese Einschätzung, daß 2/3 der AVM-Firmware FORTIFY_SOURCE verwenden würde (lt. Radar-Diagramm auf Seite 15), am Ende wohl beruhen mag.
Die Verwendung von "stack canaries" bei 2/3 der Firmware erscheint mir denk- und nachvollziehbar ... letztlich läuft das ja auf den SSP (Stack Smashing Protector) des GCC (m.W.
der Compiler, der bei AVM eingesetzt wird und seit Version 4.1 diese SSP-Option hat) hinaus und man muß nichts weiter als die passende Option (-fstack-protector, ggf. auch noch "strenger" mit anderer Option) beim Übersetzen verwenden.
Auf alle Fälle sind das alles nur "potentielle" Schwachstellen und keine tatsächlichen Möglichkeiten für einen Angriff in der Realität (erst recht nicht für die AVM-Modelle). Da muß sich also (derzeit) niemand wirklich Sorgen machen ... solange nicht wieder in irgendeinem Netzwerk-Protokoll (oder seiner Implementierung) eine Lücke gefunden wird (wie das z.B. bei der "SACK attack" (
https://lwn.net/Articles/791409/) der Fall war und das meint keinen "kick in the balls") und das am Ende "von außen" (wobei hier das Netzwerk an sich gemeint ist und es keinen Unterschied zwischen LAN und WAN gibt) ausgenutzt werden kann, sind das mehr "mahnende Worte", die da von den Autoren des Reports kommen - zumindest an die Adresse von AVM.
Denn gegen die Ausführung fremden Codes ist das FRITZ!OS schon einigermaßen "gehärtet" ... es gibt nicht mehr soo viele Stellen (und vor allem keine
allseits bekannten(!), die sich "aus der Ferne" nutzen ließen), wo man eigene Kommandos in der Box ausführen lassen könnte.
Die einzige Stelle für eine "command injection", die
mir derzeit bekannt ist, erfordert den Zugriff auf das Urlader-Environment und der ist üblicherweise nur über den FTP-Server in EVA bzw. über die serielle Schnittstelle möglich. Erst wenn sich irgendeine Möglichkeit findet, die (passend formatierte) Ausgabe eines Programms nach "/proc/sys/urlader/environment" umzuleiten (aus der Ferne, wie gesagt), wird das zu einer "relevanten Lücke".
Wobei ich die anstelle von AVM auch mittlerweile abgedichtet hätte ... immerhin besteht sie seit mehr als sechs Jahren (ich finde sie schon in der 113.06.05) und auch wenn die "Umstände", die für das Ausnutzen notwendig sind, etwas schwerer zu bewirken wären bzw. man dann auf anderen Wegen auch gleich mehr Schaden anrichten könnte (weil man beim Zugriff auf den FTP-Server ohnehin seine eigene Firmware installieren könnte - auch eine "offene Wunde" bei EVA, die aber wohl bei neueren Versionen schon dahingehend entschärft wurde, daß sie nur noch nach "PowerOn" Relevanz hat), muß man das ja nicht "offen lassen". Auch solche Argumentation habe ich allerdings schon gehört (in diesem Falle aber nicht von AVM) und das erinnert mich immer irgendwie daran, daß man das Loch im Dach eigentlich gar nicht reparieren muß, weil das Wasser ohnehin nur direkt in die Badewanne tropft und dann abläuft.
@AVM: Ich weiß nicht mal sicher, ob die damals mit auf dem "Zettel" mit den 13 Schwachstellen aus dem Telefonat im Sept. 2014 stand (ich habe diesen ja nie zu Gesicht bekommen und weiß nicht, was da genau "notiert" wurde); wenn nicht, sollten sich auch meine Kontaktdaten finden lassen in der Historie.
So lange warte ich halt auf eine neue Möglichkeit, etwas "aus der Ferne" (dazu zählt schon das GUI bei einer "command injection") in das "procfs" zu schreiben ... die ganzen neuen Schnittstellen, die AVM da in jüngster Zeit immer wieder einbaut (bis hin zu URLs für irgendwelche Live-Bilder oder Podcasts), wurden aber (zumindest bisher und nach dem, was ich so gefunden habe) immer mit der notwendigen Sorgfalt implementiert - aber "meine Stunde" kommt bestimmt irgendwann und wenn die Umleitung einer bestimmten Ausgabe in das Urlader-Environment über das "procfs" möglich ist, wird auch das wieder zur "relevanten Lücke" und ggf. zur "schnellen Lösung" für einen Shell-Zugriff auf eine FRITZ!Box. Die Zeichen sehen jedenfalls (bisher) gut aus ... insofern bin ich AVM auch "dankbar", daß man den "Hook" weiterhin präsentiert (wenn wohl auch unabsichtlich).
www.spiegel.de
