Hallo Peter,dafür hat doch AVM dich.
Das meinte ich gar nicht ... ich kenne das bloß von mir selbst, daß ich bei jeder neuen Version meine eigenen Tests erst einmal abspulen muß. Ich habe es nun wieder (teilweise) schriftlich und fernmündlich von AVM (für früher gemeldete Bugs), daß man gar nicht daran denkt, dem Meldenden für solche Bugs seinerseits eine Information zukommen zu lassen, ob man solche Bugs überhaupt fixen will und wenn ja, wann das sein wird oder ob man das überhaupt als Fehler wahrnimmt. Das hat sich zwar im Sommer etwas verschoben in der Reaktion, aber für früher gemeldete Probleme kann ich selbst zumindest weiterhin nur bei jeder neuen Ausgabe testen, ob sich etwas getan hat und meine Liste Punkt für Punkt durchgehen.
Ich weiß zum Beispiel bis heute nicht, ob AVM irgendwann mal etwas an der Initialisierung des PRNG in der Firmware gemacht hat oder jemals etwas an dieser Stelle unternehmen wird oder ob das tatsächlich nicht notwendig ist (das
Problem habe ich nicht nur im IPPF beschrieben, sondern auch AVM "gemeldet") ... die Zeichenkette "string to make the random number generator think it has entropy" aus den
OpenSSL-Beispielen/-Tests ist jedenfalls in der libikeossl.so bei der 06.50 der 7490 immer noch so vorhanden ... sie hat also den Sprung auf eine neue Kernel-Version schadlos überstanden. Jetzt müßte man natürlich für den validen Nachweis, daß diese Zeichenkette nach wie vor verwendet wird als "Entropie-Quelle", zwar hingehen und die Library in einen eigenen Wrapper verpacken und die Aufrufe der Funktionen
Code:
InitOsslCrypto()
DH_GenerateSharedSecret(st_DHValues*, unsigned short, int)
DH_GeneratePrivatAndPublicValue(st_DHValues*, int, int)
ASN1DN_2_String(unsigned char*, int, char*, int) (die sicherlich eher keinen PRNG braucht)
mitloggen ... aber zumindest zur 06.20 hin hat AVM diese Library auch definitiv noch einmal angefaßt, denn es finden sich neue Symbole (primeX) für die hinzugefügten DH-Groups. Ich habe jedenfalls nirgendwo den Hinweis gelesen, daß die Entropie des PRNG jetzt sichergestellt wird in neuen Firmware-Versionen ... und genau solche Fälle mein(t)e ich mit dem "Raten". Es ist vollkommen unklar, ob AVM das überhaupt als Problem sieht, es anhand der Quelltexte ausschließen kann oder ob es behoben wurde und nur noch diese dämliche Zeichenkette als Überbleibsel existiert (das wäre ein merkwürdig optimierender Compiler, der eine ungenutzte Zeichenkette in die erzeugte Objektdatei schreibt).
Andererseits könnte durchaus auch mein Sarkasmus-Detektor defekt sein und Du meintest das am Ende anders ... dann wäre mir das aber auch egal, selbst wenn ich nur der "Rufer in der Wüste" wäre.
Insofern erstaunt mich die Timeline für den Update-Bug eben besonders, weil einige der mir vorliegenden E-Mails genau auch aus diesem Zeitraum (September 2014 bis Dezember 2015) stammen - offenbar hat AVM aber der RedTeam GmbH entsprechend geantwortet - ja, wenn ich die Timeline richtig interpretiere, haben die Leute dort sogar innerhalb von einem Monat eine fehlerbereinigte Version für weitere Tests erhalten. Nun mag ich ja auch besonders ungeduldig sein, aber wenn zwischen der Meldung von RedTeam (16.10.2014) und der ersten Reaktion von AVM (11.11.2014) auch schon fast vier Wochen liegen (so liest sich die Timeline für mich jedenfalls), dann finde ich persönlich das einfach zu viel Zeit, die da vergeht. Das sind dieselben Zeiträume, die andere Hersteller aus China oder Taiwan (die Diskussion, ob das eins ist, spare ich mir) oder Malaysia oder Korea usw. auch an den Tag legen.
Wenn man sich jetzt aber vor Augen hält, seit wann der Bug mit konkreter Fehlerbeschreibung durch RedTeam vorlag (16.10.2014) und wann dann die gefixte Version erschien (16.07.2015), dann gab es zwischendrin noch weitere Release-Versionen (für mehrere Modelle, aber die konkreten Termine habt ihr beim ruKernelTool vermutlich viel genauer, als ich die jetzt ermitteln könnte), die wohl nach wie vor angreifbar waren.
Egal, wie man die Schwere des Fehlers einschätzen mag, relativiert das doch die von AVM bei "webcm-Gate" gezeigte Geschwindigkeit bei der Fehlerbehebung erheblich. Man kann/muß sicherlich nicht jeden kleinen Bug sofort mit einer "Sonderausgabe" fixen, aber gerade dieser offensichtliche Bug mit dem Auspacken nach /var war lange bekannt und hätte schon für so viele andere Angriffe mißbraucht werden können (auch die /var/assume_all_access_from_homenetwork, mit der man die Prüfung externer Zugriffe auf dieselben Voraussetzungen beschränken konnte, wie sie für internen Zugriffe gelten, im Extremfall eben auf gar keine Prüfung -> keine Anmeldung im Heimnetz) landete nach einem solchen mißglückten Auspacken ja dort, die wurde aber irgendwann nach der 06.30 erst "abgeschafft" (endlich) - jedenfalls taucht sie im ctlmgr der 06.50 nicht mehr auf), so daß das Schließen an dieser Stelle lange überfällig war. Die Bemühungen zum "Flicken" dieser fundamentalen Lücke durch das nachträgliche Ersetzen der /var/post_install:
Code:
rm -rf /var/post_install ; ( cd / ; tar xf /var.tar ./var/post_install )
in firmwarecfg stehen ja auch klar dafür, daß man zumindest um das Problem des Entpackens dorthin wußte - nur hat man eben anstelle der generellen Überarbeitung auf "Reparaturen" gesetzt, die aber durch neue Ideen dann auch wieder ausgehebelt werden können.
Wenn von AVM die notwendige Geschwindigkeit (nun mag man noch darüber streiten, was da angemessen wäre, 9 Monate sind es m.E. eben nicht und wenn es für ältere Geräte gar keine 06.30 mehr gibt, bleiben die eben angreifbar auf diesem Weg) nur dann umgesetzt wird, wenn so ein Fehler bereits aktiv ausgenutzt wird oder zumindest öffentlich bekannt ist (bis zum Ausnutzen ist es dann schon noch ein weiterer gewaltiger Schritt), ist das wieder ein gewichtiges Argument für "full disclosure" von Beginn an - da beißt für mich die Maus keinen Faden ab, auch wenn ich nicht per se zu den Befürwortern einer radikalen "full disclosure"-Philosophie gehöre (wie viele Unterstützer der BSD-Projekte).
Nur dann wird der Hersteller (der das natürlich keinesfalls als "angenehm" empfindet, aus nachvollziehbaren Gründen) "unter Druck gesetzt" ... und das sollte man jetzt nicht mit "erpreßt" oder "genötigt" verwechseln - aber die (hoffentlich inzwischen hinfällige) Politik der stillschweigenden Fehlerkorrekturen rächt sich natürlich an dieser Stelle dann auch wieder, weil kein Nutzer (außer bei den beiden nunmehr von RedTeam inkl. PoC veröffentlichten Bugs) selbst prüfen kann, welchen Fehler AVM bei seinem Modell vielleicht schon mit einer kleineren Versionsnummer gefixt hat, weil das betreffende Update erst nach der späteren Version für eine der "Mainstream-Boxen" erschienen ist. Schon die Tatsache, daß bei den KNB ja wohl noch 06.2x-Versionen bei der 6490 im Einsatz sind, könnte ja jetzt einige Kunden auf dumme Gedanken kommen lassen ... immerhin gibt es dort aber das Update per Datei gar nicht erst (ein konformes Gerät erfordert auch ein anders signiertes Update (CVC) als es die AVM-DSL-Boxen erwarten/bieten und die 6490 hat diese höheren Weihen ja erhalten) und auch keinen "dsl_control", weil dieser "WAN-Teil" der Firmware eben nicht auf den Infineon-Quellen beruht (da ist ja gar kein Lantiq-SoC verbaut in so einer Kabel-Box).
Wenn hingegen die Versorgung mit der 06.30 schon das eindeutige Indiz dafür ist, welche Modelle AVM auch künftig mit Security-Fixes versorgen wird, dann kann sich jeder selbst ausrechnen, was es für seine eigene FRITZ!Box heißt - auch wenn es inzwischen wohl für weit mehr Modelle die 06.30 gibt, als ich überhaupt mitbekommen habe. Aber das zeigt auch wieder, daß eben das (unnötige) Verharren auf einer älteren Version auch für den Besitzer so einer Box ein unkalkulierbares Risiko wird, solange er nicht exakt weiß, welche Lücken geschlossen wurden und damit gar nicht selbst einschätzen kann (wenn er die Qualifikation dafür tatsächlich hat), wie weit ihn so ein Bug in seiner Umgebung tangiert.
