[Info] Fraunhofer-Test 127 Router haben teils erhebliche Sicherheitsprobleme

avm_7170

Aktives Mitglied
Mitglied seit
4 Jun 2015
Beiträge
1,420
Punkte für Reaktionen
117
Punkte
63
 
Blöd für AVM, dass die 4020 untersucht wurde, die in Sachen Firmwaresupport nicht das Glanzstück ist.

Die aktuelle FIrmware ist bei der 4020 FRITZ!OS 7.01
vom 19.12.2018.
 
Zuletzt bearbeitet:
The AVM Fritz!Box 4020 was partly extracted. FACT failed on the file system, which seems to be proprietary squashfs format that even the FREETZ project cannot handle.
aus: https://www.fkie.fraunhofer.de/cont...omeRouter/HomeRouterSecurity_2020_Bericht.pdf

Hat irgendjemand eine Idee, was hier gemeint sein könnte? Welches SquashFS-Format "versteht" denn Freetz nicht? Ich bin etwas ratlos - das ist ja nicht der Stand vor 5 Jahren, sondern irgendwo aus dem März 2020.

Klingt jedenfalls schon mal komisch für mich - ich kann das Image einer 4020 problemlos entpacken (lassen):
Rich (BBCode):
peh@vidar:~> wget http://ftp.avm.de/fritzbox/fritzbox-4020/deutschland/fritz.os/FRITZ.Box_4020.de-en-es-it-fr-pl.147.07.01.image -q -O - | tar -x -O ./var/tmp/kernel.image > /tmp/4020.kernel.image
peh@vidar:~> /home/GitHub/YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -s -k /tmp/4020.kernel.image
Found a valid superblock at offset 0x001C5F00 while scanning /tmp/4020.kernel.image.
NMI vector found at 0x00BE0000, size=4096
Found TI checksum (0xD5030BF4) at the end of the image.
Found a valid big endian SQUASHFS 4:0 superblock on /tmp/4020.kernel.image.
Creation or last append time is not available because of modified AVM-format (mkfs_time == bytes_used)
Filesystem size 13360.20 Kbytes (13.05 Mbytes)
Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 254
Number of inodes 2691
Number of ids 1
peh@vidar:~> sudo /home/GitHub/YourFritz/bin/squashfs/$(uname -m)/unsquashfs4-be -k -no-progress /tmp/4020.kernel.image
Found a valid superblock at offset 0x001C5F00 while scanning /tmp/4020.kernel.image.
NMI vector found at 0x00BE0000, size=4096
Found TI checksum (0xD5030BF4) at the end of the image.
Filesystem on /tmp/4020.kernel.image is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
2508 inodes (2971 blocks) to write

created 2042 files
created 183 directories
created 454 symlinks
created 12 devices
created 0 fifos
peh@vidar:~> ls -l squashfs-root/lib/modules/4.4.60/
total 132
drwxr-xr-x 5 root root  4096 Dec 18  2018 kernel
-rw-r--r-- 1 root root    45 Dec 18  2018 modules.alias
-rw-r--r-- 1 root root    12 Dec 18  2018 modules.alias.bin
-rw-r--r-- 1 root root     0 Dec 18  2018 modules.builtin.bin
-rw-r--r-- 1 root root  2002 Dec 18  2018 modules.dep
-rw-r--r-- 1 root root  3112 Dec 18  2018 modules.dep.bin
-rw-r--r-- 1 root root    52 Dec 18  2018 modules.devname
-rw-r--r-- 1 root root   872 Dec 18  2018 modules.order
-rw-r--r-- 1 root root    55 Dec 18  2018 modules.softdep
-rw-r--r-- 1 root root 41034 Dec 18  2018 modules.symbols
-rw-r--r-- 1 root root 50468 Dec 18  2018 modules.symbols.bin
drwxr-xr-x 2 root root  4096 Dec 18  2018 net
peh@vidar:~>
Das Entpacken klappt also klaglos - die Dateien sind auch alle da. Keine Ahnung, warum man da beim FKIE solche Probleme hatte. Letztlich ist das "unsquashfs" aus Freetz und aus meinem Repo identisch, was den Funktionsumfang angeht.

As you can see AVM is the only vendor not publishing any private key in its firmware images.
Das stimmt bei AVM auch nur zum Teil ... aber im Prinzip ist es richtig. Nur für TR-069 bei der Telekom, wird ein Client-Zertifikat für die Boxen benötigt: https://www.ip-phone-forum.de/threads/ist-easysupport-auch-mit-z-b-der-fb7580-möglich.307129/ ... und dessen privater Schlüssel muß nun mal (prinzipbedingt) auch in der Firmware vorliegen. Allerdings macht AVM hier vieles richtig und verschlüsselt diesen privaten Key mit mindestens AES-128 und einem starken Kennwort (die Länge ist ausreichend, der Zeichenvorrat auch und es steht garantiert in keinem Wörterbuch, ist aber auch nicht das gerne genommene Laufen mit den Fingern über die Tastatur, was bei manchem Programmierer wohl schon als "random selection" gilt) - offensichtlich so gut, daß er den Autoren der Studie nicht mal aufgefallen ist.

Blöd für AVM, dass die 4020 untersucht wurde, die in Sachen Firmwaresupport nicht das Glanzstück ist.
Hier gehört ggf. ein "auch" hin ... wie man schon daran sehen kann, welche Linux-Kernel-Versionen im März 2020 (das ist der Zeitpunkt der Stichprobe) in den Geräten vorlagen (Seite 8), hatten sie wohl 13 Geräte von AVM insgesamt im Portfolio (eines macht dann ca. 7,7%, wobei wohl 4 mit ARM- und 9 mit MIPS-Architektur dabei waren, siehe Seite 4) und lange nicht nur die 4020. Allerdings gilt eben für fast alle AVM-Modelle im Moment, daß die letzte offizielle Release-Version irgendwann zwischen August und Oktober 2019 veröffentlicht wurde und nur Release-Versionen wurden berücksichtigt lt. Text.

Bei der Feststellung:
46% of AVMs devices are powered by 4.4 Linux Kernel, which is maintained until today.
kam ich auch erst mal ins Grübeln, weil das immerhin 6 der 13 betrachteten Geräte von AVM wären. Selbst wenn die 6820 auch den Kernel 4.4 erhalten hat (die hatte ich zuerst nicht auf dem Schirm), gibt es m. E. im Moment noch gar nicht genug Modelle mit einem solchen Kernel:
Rich (BBCode):
Product="FRITZ!Box 4020"
KernelVersion="4.4.60"
>>>>> ================================== <<<<<
Product="FRITZ!Box 4040"
KernelVersion="4.4.60"
>>>>> ================================== <<<<<
Product="FRITZ!Box 6820 LTE"
KernelVersion="4.4.60"
>>>>> ================================== <<<<<
Product="FRITZ!Box 7520"
KernelVersion="4.4.60"
>>>>> ================================== <<<<<
Product="FRITZ!Box 7530"
KernelVersion="4.4.60"
>>>>> ================================== <<<<<
Da frage ich mich, welches wohl das sechste Modell war, was hier vom FKIE betrachtet wurde. Denn eigentlich sollte es dem Titel nach ja um Router gehen ... da sollten dann auch keine Repeater mit Kernel 4.4 in Betracht kommen (siehe Anhang mit der Liste der FRITZ!Box-Images, wobei manche Boxen mehrfach vertreten sind, da es sich um die Dateien von ftp.avm.de/fritzbox handelt).

Ansonsten zeigt das Ergebnis für AVM halt, daß es an aktuellen Kernel-Versionen mangelt (ein hinreichend bekanntes Problem) und daß noch nicht alles bei AVM die Mechanismen nutzt, mit denen man die Folgen eines erfolgreichen Angriffs abmildern könnte (von ASLR/PIE bis NX-Bits beim Memory-Management für Daten-Segmente).

Woher am Ende die Einschätzung kommt, daß die AVM-Firmware zu 2/3 tatsächlich FORTIFY_SOURCE (also das Ersetzen "alter" C-Funktionen durch modernere, die besser auf Limitierungen bei den Parametern - insb. bei deren Längenangaben - achten) verwenden würde bzw. mit diesen zusätzlichen Prüfungen erzeugt wurde, muß ich erst mal selbst ermitteln (das Tool-Set der Studien-Autoren gibt's ja bei GitHub).

Eigentlich unterstützt die uClibc-ng (die m.W. bei den meisten aktuellen Release-Versionen immer noch genutzt wird) von sich aus kein FORTIFY_SOURCE und setzt event. übergebene Compiler-Options dazu auch wieder außer Kraft: https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/include/features.h#n214

Was allerdings tatsächlich "blöd" ist, ist die Tatsache, daß die Autoren der Studie zwar von 127 Routern schreiben, aber sich nirgendwo ein Verweis auf die Liste der Modelle findet (zumindest habe ich keinen gesehen) - auch nicht im GitHub-Repo für "FACT_core". Das macht die Ergebnisse schwer nachvollziehbar - zumindest kann man anhand der Prozentangaben bei AVM halbwegs schlußfolgern, was da wohl im Pool war.
 

Anhänge

  • kernel_versions_by_avm.txt
    6.3 KB · Aufrufe: 11
Zuletzt bearbeitet:
"Dabei kam heraus, dass rund ein Drittel der Geräte in den vergangenen zwölf Monaten kein einziges Update
erhalten haben - da dann auf dem neuesten Stand der Sicherheit zu bleiben erscheint aussichtslos."

Sogar Top Modelle wie die 7590 haben seit knapp einem Jahr (letztes Update vom 25.07.2019) keine Sicherheitsupdates erhalten.
Die FRITZ!Box 4020 ist mit 18 Monaten ohne jedes Sicherheitsupdate die rote Laterne. Das eine oder andere Wartungsupdate, neben
Bugfixes nach neuen Versionen, dürfte es zwischen den Hauptversionen schon geben.

"Insbesondere AVM leistet bei den meisten Sicherheitsaspekten eine bessere Arbeit als die anderen Anbieter. Allerdings sind
auch AVM-Router nicht fehlerfrei" Und das ist löblich, und soll hier keinesfalls untergehen. Für einige ehemalige Spitzenmodelle
(wie die 7390) habt Ihr länger als alle anderen Hersteller Sicherheitsupdates angeboten.

Liege ich völlig falsch, wenn ich dem Fraunhofer Institut recht gebe?

"Zitate" aus: https://winfuture.de/news,116741.html

Passend einsortiert by stoney
 
Zuletzt bearbeitet von einem Moderator:
Vielleicht verstehe ich das falsch, aber um eine kernel-Securitylücke auszunutzen, muss ich doch einen von mir geschriebenen Code auf dem Router ausführen. Ist das bei einem geschlossenen System wie FritzOS überhaupt möglich?
 
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 :cool:), 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).
 
Moinsen


Sicherheit...
Wenn die BHs die STXNT erschuffen sich auf FRITZ!Boxen stürzen wars das.
...ist ein Gefühl.
:cool: Also immer schön die "Sonnenfinsternis" Sonnenbrille aufgesetzt

@PeterPawn - Bestimmt "prompt" :p , weil, mit PS1 gehen doch auch so tolle "Injections"
 
Bei AVM und der BusyBox m.W. nicht ... da ist nicht mal "Farbe" möglich, weil die Option "FANCY_irgendwas" bei der Übersetzung nicht ausgewählt wurde.
 
vaxinf, inzwischen werden Schwachstellen kombiniert. Also die eine Schwachstelle um zu der anderen zu gelangen. Diese Router sind kleine Computer mit Laufzeitumgebungen (Python, Lua, …). Wenn man also weit genug kommt, kann man den Computer für sich rechnen lassen. Aber die Veröffentlichung hat für uns Endanwender direkt kaum Relevanz, weil …
[…] 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.
Was für ein Satz. Mit „echt“ meinst Du „durch-analysierte“.

Das Verfahren nennt sich „statische Analyse“, weil nicht während der Laufzeit (dynamisch) sondern allein der Programm-Code (statisch) angeschaut wird. Eine solche Analyse dient als Start-Punkt für weitere Untersuchungen. Kann also gut sein, dass Schwachstellen gefunden wurden; aber das war gar nicht Teil der Untersuchung. Solch ein Start-Punkt – ein automatisiertes Verfahren – dient danach Pen-Testern weiter zu bohren und sich auf gewisse Stellen zu konzentrieren. Ein solches Verfahren ist in der Security-Community anerkannt und der von Dir zitierte Satz heißt vollständig: „Trotz der recht oberflächlichen Analyse der Fraunhofer-Forscher deuten viele der Ergebnisse auf zum Teil gravierende Sicherheitsmängel bei den getesteten Home-Routern hin. Obwohl sich bei genauerem Hinsehen einige Lücken als nicht angreifbar herausstellen könnten, kann man wohl getrost davon ausgehen, dass andere Hinweise auf handfeste Sicherheitsmängel hindeuten.“

Wenn Du so willst, war das eine rein akademische Finger-Übung, wie weit man mit statischer Analyse kommt. Also etwas so basales, dass es auch die Hersteller inzwischen mindestens machen müssten. Das Problem ist nämlich, dass die Hersteller eine eigene Linux-Distribution zusammenschustern – und noch nicht verstanden haben, was dafür alles nötig ist (organisatorisch und fachlich). Dabei können den Herstellern bereits einige Fraunhofer-Institute strategisch helfen. Hier das Fraunhofer-Institut FKIE – es hat also Werbung für sich gemacht. Aber es hat auch einmal mehr die Finger in die Wunde gelegt, warum „unsere“ Hersteller in den Kernels einfach Sicherheits-Features auslassen. Das sind Features, die „kostenlos“ und bis zu 25 Jahren in den Kernels vorhanden sind.
 
Nein, ich meinte tatsächlich Statistik bzw das passende Adjektiv ... weil der Report nichts anderes als das Zählen von "Merkmalen" für das Vorhandensein oder Fehlen bestimmter Eigenschaften ist.

Eine statische (Code-)Analyse kann hier schon deshalb gar nicht stattgefunden haben, weil man dafür den Programm-Code gar nicht hatte (zumindest nicht bei den Geräten von AVM und auf die veröffentlichten OpenSource-Pakete nimmt der ganze Report keinerlei Bezug) bzw. ihn erst mal durch Disassemblieren oder andere Techniken des Reverse-Engineering hätte erlangen müssen. Von all dem ist im Report überhaupt keine Rede.

Und mit "echt" meine ich Schwachstellen, die sich auch in der Realität ausnutzen lassen und wo - wenn nicht sogar ein passender "proof of concept" - wenigstens eine valide Idee, wie erkannte Sicherheitslücken zu einem erfolgreichen Angriff zu kombinieren wären, vorhanden ist.

Wenn Du so willst, war das eine rein akademische Finger-Übung, wie weit man mit statischer Analyse kommt.
Was hat man denn hier nach Deiner Ansicht "statisch" analysiert? Schau Dir das Framework vom FKIE an ... dann kannst Du auch erkennen, was das wirklich macht und das hat mit "statischer Code-Analyse" (so, wie Du mir das in #10 dankenswerterweise erklärst - aber ich hoffe mal, es war mehr für die "audience") überhaupt nichts zu tun.

Das befaßt sich weder mit dem Quelltext noch mit dem Kompilat irgendeines konkreten Stücks Software - es werden lediglich die verwendeten Komponenten (Linux-Kernel-Versionen) "gezählt" und anhand bestimmter Merkmale "geraten", ob eine Technik (bei der "exploit mitigation") nun vom Hersteller verwendet wird oder nicht.

Auch die Frage, wie lange es kein Update der Firmware (als Release) mehr gab und ob da private Schlüssel und/oder fest hinterlegte Credentials existieren, ist reines Zählen, was hier dann obendrein noch bei der Genauigkeit der Ergebnisse davon abhängig ist, wie gut/genau die jeweils untersuchten Merkmale auch tatsächlich erkannt werden. Was davon hat auch nur im entferntesten etwas mit einer statischen Code-Analyse zu tun?

Und ich habe den Satz von heise.de zwar nur teilweise zitiert, aber trotzdem nicht "sinnentstellend" ... denn die Schwäche des Verfahrens des FKIE besteht - neben der Betrachtung von nur fünf Kriterien - ja tatsächlich darin, daß ausschließlich Statistik mit den gewonnenen "Meßwerten" betrieben wurde/wird und das "Verständnis" für die inneren Zusammenhänge der jeweilgen Firmware-Versionen (das gilt für alle anderen ebenso, wie für die AVM-Firmware) gar nicht gegeben war. Das war meine These und darauf bezieht sich auch der Teil mit der "recht oberflächlichen Analyse" im Satz bei heise.de - nur zur Bekräftigung/Unterstützung dieses Teils meiner Behauptung habe ich den auch herangezogen.

EDIT: Aus der Methodik und dem verwendeten Verfahren zur Untersuchung dann die (zusammengefaßte) Aussage abzuleiten, daß 127 untersuchte Router-Modelle erhebliche Sicherheitsmängel haben (die "normale Benutzer" auch als "Sicherheitslücken" verstehen würden und nicht nur als "potentielle Schwachstellen"), ist schon ziemlich heftig - und hier wohl tatsächlich eher PR (des BSI als Auftraggeber oder des FKIE selbst).

Ich frage mich tatsächlich, wie bzw. warum man so einen Zusammenhang (EDIT: bei meinem Zitat) irgendwie "mißverstehen" könnte oder sollte oder wollte.
 
Zuletzt bearbeitet:
Die Untersuchung ist valide (und "gefällt mir" ist hier nicht mal im Ansatz eine Kategorie der Bewertung) ... die daraus generierten Überschriften (hier, im Spiegel iirc, bei anderen "Computer-Nachrichten") sind zu reißerisch und ob das an den Autoren, dem FKIE, dem BSI oder wem auch immer liegt, weiß ich gar nicht genau.

Jedenfalls lassen sich einige Überschriften (auch die dieses Threads hier im IPPF) aus dem Inhalt des Reports nur mit sehr viel Phantasie ableiten ... das Minimum, was da dann erforderlich wäre, ist der Konjunktiv - auch schon in den Überschriften.

Aber wie wäre es denn, wenn Du auch auf meine Frage an Dich noch eingehen würdest, was den Unterschied zwischen "statisch" und "statistisch" anbelangt? Das nahm ja nun viel mehr Raum in meiner Reaktion ein, als die (ohnehin nur unterstellte) Aussage, daß mir die Untersuchung nicht gefiele.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.