Fritzbox 6490 Cable Firmware Update?

Ich schrieb von "atomaren Operationen" und die drehen sich nicht um Nuklearteilchen o.ä. und auch nicht um den x86-Core im Puma6 (den gibt es bei anderen Boxen ja ohnehin nicht und die Lücke besteht auch bei VR9-Boxen), das "atomos" bezeichnet ja ursprünglich "das Unteilbare" und in diesem Zusammenhang geht es dabei eher darum, was man mit solchen Daten als "Basisoperation" eben so macht oder machen kann.

Das geht mit dem Schreiben und Lesen einer Datei los und aus diesen zwei Aktionen lassen sich dann Stück für Stück komplexere Dinge zusammenstellen. Eines wäre das Kopieren einer Datei, das aus direkt aufeinanderfolgendem Lesen mit Schreiben an eine neue Stelle besteht und die Frage ist am Ende nur, wie "unteilbar" solche Aktionen sein sollen. Man kann natürlich auch hingehen und das Kopieren, Verschieben, Löschen von Dateien als "Basisoperationen" annehmen ... bis hin zum Mischen von Dateien mit "ar7cfgconv".

Die viel spannendere Frage hier ist es doch, was das System alles vor dem Mischen einer bestehenden "ar7.cfg" und des Inhalts der Datei in einer "provideradditive.tar" noch machen muß, damit so ein Mischen überhaupt stattfinden kann. Ich wüßte nicht, daß von "ar7cfgconv" auch ein Tarball als Eingabe akzeptiert würde ... also muß da ja noch irgendetwas anderes erfolgen und so offensichtlich, daß es eine Art "Batchdatei" dort gibt, wo man einfach nur die eigenen Kommandos hineinschreiben muß, ist es dann doch wieder nicht ... dann wäre das sicherlich schon vorher irgendwo aufgefallen.

Man muß einfach nur mal überlegen, was mit der "provideradditive.tar" alles passieren muß, damit die dort enthaltenen Dateien für die Konfiguration der Box genutzt werden können - wer noch eine weitere Box hat, kann ja auch einfach mal testen, was mit so einer Datei geschieht. Selbst wenn man die Verarbeitung nicht direkt "sehen" kann, sollte sich ja anhand von Spuren im Dateisystem auch im Nachhinein noch rekonstruieren lassen, was die Firmware da so macht.

Dann überlegt man sich noch, daß unter Linux so vieles aus kleineren Programmen einfach nur zusammengesetzt wird - beim Firmware-Update habe ich z.B. mal aufgedröselt, daß da vom Webserver über die CGI-Schnittstelle "firmwarecfg" aufgerufen wird, was dann zuerst wieder das Shell-Skript "prepare_fwupgrade" startet und im Anschluß über eine "Pipeline" aus mehreren Kommandos die Signatur der Update-Datei prüft, bevor dann das install-Skript aus der neuen Firmware gestartet wird.

All das läßt sich ja anhand der "Zeilen" (bzw. der Zeichenketten) in den binären Komponenten der Firmware nachvollziehen ... wenn die Verarbeitung dieser Provider-Konfigurationen auf eine ähnliche Weise erfolgen sollte, muß sich auch davon ja irgendeine Spur in den Binärdateien von AVM finden lassen.

Vielleicht ist es ja schon eine Überlegung wert, zuerst einmal festzustellen, welche Dateien/Programme von AVM sich überhaupt mit dieser "provideradditive.tar" befassen ... wenn sie die irgendwie verarbeiten wollen, müssen sie die ja erst einmal öffnen und dazu wird (in den allermeisten Fällen jedenfalls) der Dateiname benötigt ... ergo sollte dieser auch in den Programmen und/oder Bibliotheken auftauchen, die sich mit der Datei befassen (solange man das nicht gezielt "obfuscated" und das findet bei AVM derzeit nicht statt).

okay, dann hab ich das mit den atomaren operationen falsch interpretiert. ich war dort bei schreiben der images über eva...
kann ja mal passieren... aber wie gesagt, ich bin da wohl raus...

dumbofrage:
dein letztes posting lässt mich über tr069 und nen eigenen server der sachen bereitstellt nachdenken...
einbahnstrasse? oder auf dem weg in die richtige richtung?

Eines muss ich auf jeden Fall mit Respekt feststellen, - dass rhetorische Talent von PeterPawn überzeugt,
Zeit nimmt er sich auch, nur die Antworten haben ein bisschen von "Sakrileg" ;-) , aber dort waren eben
auch nur anderthalb Stunden vorgesehen. Ist aber ok so, jeder hat seine Art zu helfen und ich hasse
es auch, wenn man sich nicht erst selbst etwas bemüht, bevor man mich fragt.

@noob_noob:
Solange Du keine konkrete Vorstellung hast, was Du über TR-069 konfigurieren willst (und was davon über TR-064 nicht erreichbar ist - auch das ist ja eine Möglichkeit der Konfiguration, haben wir erst vor kurzem bei der Änderung von "UpgradesManaged" per PowerShell-Skript gesehen), ist das vermutlich eher eine Sackgasse.

Das soll nicht heißen, daß dort nicht ggf. auch noch Lücken existieren (und so ein Update über TR-069 ist schon mal im Gegensatz zu einem per "Datei-Upload" eines im Online-Modus, wo auch weniger Dienste durch "prepare_fwupgrade" gekillt werden), aber IIRC war die Signaturprüfung bei einem Update-Image per TR-069 genau dieselbe wie bei den anderen Wegen - auf diesem Weg kommt also auch nur unmodifizierte Firmware in die Box. Das sollte (zumindest theoretisch) auch für Updates im CVC-Format gelten, ich unterstelle mal die korrekte Prüfung einer CVC-Signatur durch die Firmware, da das zum großen Teil bei der 6490 aus dem Intel-CEFDK stammt und nur das konkrete Update (auch da über "/var/install") nach der Dateiprüfung da von AVM "angestrickt" wurde (merkt man beim Vergleich mit der Firmware anderer Puma6-Geräte, z.B. von Hitron).

Allerdings gibt es auch beim Entpacken einer Firmware tatsächlich noch eine Lücke (Incident 515123), die aber nach Ansage von AVM im nächsten Major-Release (geplant in Q3/2016) geschlossen sein wird. Für das Ausnutzen dieser Lücke braucht es einerseits den lokalen Zugriff auf die FRITZ!Box und andererseits ein per TR-069 angestoßenes Update, weil nur dabei der USB-Stack in "prepare_fwupgrade" nicht gestoppt wird, denn so ein Online-Update könnte ja auch über einen UMTS-Stick erfolgen. Für das Ausnutzen der Lücke braucht es dann einen speziell präparierten USB-Stick mit dem passenden Dateisystem ... daher wird auch der funktionierende USB-Stack benötigt. Ob das bei der 6490 auf Anhieb klappt (da erfolgt das Entpacken ja etwas anders als bei den DSL-Modellen bzw. das Ergebnis sieht anders aus, weil in das NFS-Verzeichnis entpackt wird), habe ich nie bis zum Ende probiert - in der Theorie sollte es klappen, ist hier konkret jedoch viel zu viel Aufwand, weil es einige Vorbereitungen und Voraussetzungen benötigt.

gibt menschen, die brauebn nen schlag mit dem zaunpfahl in genick zum nachdenken. bzw aber auch genau diesen, wenn sie auf dem holzweg sind

- - - Aktualisiert - - -

PeterPawn schrieb:

Das soll nicht heißen, daß dort nicht ggf. auch noch Lücken existieren (und so ein Update über TR-069 ist schon mal im Gegensatz zu einem per "Datei-Upload" eines im Online-Modus, wo auch weniger Dienste durch "prepare_fwupgrade" gekillt werden), aber IIRC war die Signaturprüfung bei einem Update-Image per TR-069 genau dieselbe wie bei den anderen Wegen - auf diesem Weg kommt also auch nur unmodifizierte Firmware in die Box. Das sollte (zumindest theoretisch) auch für Updates im CVC-Format gelten, ich unterstelle mal die korrekte Prüfung einer CVC-Signatur durch die Firmware, da das zum großen Teil bei der 6490 aus dem Intel-CEFDK stammt und nur das konkrete Update (auch da über "/var/install") nach der Dateiprüfung da von AVM "angestrickt" wurde (merkt man beim Vergleich mit der Firmware anderer Puma6-Geräte, z.B. von Hitron).

Zum Vergrößern anklicken....

sorry, nochmal dumbo: ich muss mich zu cvc/intel-cefdk schlau machen. sagt mir nix. ob mir das nach lesen was sagen wird, bezweifel ich.
das, was du mit 515123 beschreibst, klingt auch interessant... SEHR... ich muss mal mehr dazu lesen... und hoffe, es zu verstehn/umsetzen zu können

PeterPawn schrieb:

Vielleicht ist es ja schon eine Überlegung wert, zuerst einmal festzustellen, welche Dateien/Programme von AVM sich überhaupt mit dieser "provideradditive.tar" befassen ... wenn sie die irgendwie verarbeiten wollen, müssen sie die ja erst einmal öffnen und dazu wird (in den allermeisten Fällen jedenfalls) der Dateiname benötigt ... ergo sollte dieser auch in den Programmen und/oder Bibliotheken auftauchen, die sich mit der Datei befassen (solange man das nicht gezielt "obfuscated" und das findet bei AVM derzeit nicht statt).

Zum Vergrößern anklicken....

Hallo PeterPawn und andere Interessierte,
ich konnte das Pattern "provideradditive.tar" in folgenden Dateien finden:

/bin/tr069starter

/lib/libar7cfg.so.1

/lib/libcfgimpexp.so.0

/lib/libcmapi.so.1

Nun wäre es toll, wenn man die Antwort auf Posting 2044487 hätte:

PeterPawn schrieb:

der Aufbau der einzelnen Dateien ist imho klar, es sollten cfg-Diffs von AVM sein, die sich mit den *cfgconv-Kommandos "mergen" lassen) ?
Alles darueber hinausgehende (z.B. ob da noch ein Shell-Skript ausgefuehrt werden kann, wie das /var/install in einem Firmware-Image, usw.)
liegt fuer mich weitgehend im Dunklen und auch die ueblichen Verdaechtigen wie "wehavemorefun" sind da nicht aussagefaehig. Da steht nur,
dass es das eben gibt, wie es funktioniert, fehlt aber.

Zum Vergrößern anklicken....

kann jemand Hinweise geben ?

Gruß
ncc-1701

OK ... suchen, auslesen, aufschreiben ist das eine - nun müßte man sicherlich ans "Interpretieren" der Fundstellen gehen und dann reduzieren sich die möglichen Dateien ja praktisch von alleine auf eine einzelne.

Was macht denn die Firmware so alles mit der fraglichen Datei? Was kann man denn da sehen und wozu sollte das notwendig sein bzw. wann wird da wohl was erfolgen?

Die Idee mit dem Shell-Skript hatte ich tatsächlich früher auch ... wie Du ja offenbar in anderen Beiträgen gelesen hast. Das war bzw. ist aber nicht der Weg, es geht nicht einmal um die dort enthaltenen Dateien, die von der Firmware erwartet und verarbeitet werden.

Der Witz bei solchen "Einbrüchen" ist es ja gerade, den existierenden Code mit Eingabedaten zu konfrontieren, die er so nicht erwartet und wo der Programmierer bei der Gültigkeitsprüfung geschlampt hat oder gar nicht davon ausging, daß ihm da jemand mit Absicht irreguläre Daten vorsetzen könnte und die dann trotzdem verarbeitet werden.

PeterPawn schrieb:

hat sich eigentlich schon mal jemand überlegt, wie so eine "providerspezifische Konfiguration" genau aussieht (also so eine "provideradditive.tar" im TFFS) und was mit der dann passiert, wenn die Firmware beim Start das Vorhandensein so einer Datei feststellt?

Zum Vergrößern anklicken....

ich könnte mir vorstellen, dass die Datei wie folgt ausgepackt wird:

PeterPawn schrieb:

Auf der anderen Seite wird auch im ctlmgr (vermutlich im Rahmen der Konfiguration der Box, wie es bei der "providers-049.tar" für D auch passiert) eine Datei /var/flash/provideradditive.tar verwendet, dort finden sich dann die Zeilen

Code:

/var/flash/provideradditive.tar
cat %s | tar xf -

, was relativ gut zu einem Zugriff auf TFFS-Nodes (nur "character oriented I/O", daher das "cat" vor dem "untar") passen würde und die Existenz eines passenden Nodes (der hätte die Minor-ID 29) voraussetzen würde.

Zum Vergrößern anklicken....

anschließend müssten diese Config-Diff-Files aus Verzeichnis provider_additive dann z.B. per CfgTakeOver auf die aktuelle Config applied werden;
dies ist meine Vorstellung wie "provider additive" funktionieren könnte.

Liege ich so richtig ? wenn ja welches Binary wird für diesen CfgTakeOver verwendet ?

Gruß
ncc-1701

Mit dem Auspacken liegst Du schon mal richtig (wenn auch das Busybox-Applet für "tar" problemlos mit TFFS-Nodes direkt umgehen kann, aber das mußte ich mir auch erst durch Tests erarbeiten, daher auch wieder der ältere Text, den Du da gefunden hast) - das ist tatsächlich notwendig ... wohin erfolgt das denn?

Gerade das könnte man ja anhand der weiter vorne angesprochenen Spuren im Dateisystem als nächstes einmal analysieren ... sofern die entpackten Dateien nicht hinterher sofort wieder entsorgt werden, müssen die ja noch irgendwo stehen und so viele Verzeichnisse, die man beschreiben könnte, gibt es im FRITZ!OS nicht.

Wobei ich keine Idee habe, wie Du hier auf den Begriff "cfgtakeover" kommst ... das hat damit eher wenig bis nichts zu tun und das Mischen der Dateien kann ja auch kaum der Ansatzpunkt für die Bedrohung sein (zumindest nicht für die, die ich meine - es kann aber natürlich durchaus auch bei diesem Mischen weitere Schwachstellen geben, das will ich nicht ausschließen), denn das sind ja genau die Daten, die von der Firmware in so einem Tarball erwartet und damit dann auch weiterverarbeitet werden. Die sind wohl kaum diejenigen, die ich in #934 im letzten Absatz meinte.

das Auspacken der provideradditive.tar erfolgt nach /var/tmp/provider_additive

/lib/libcfgimpexp.so.0


dies ergibt folgenden Auspackbefehl:

da der Inhalt der provideradditive.tar mit relativen Pfaden erfolgt, wäre bei "schlampiger Programmierung" auch so etwas wie die FTP-Logging-Lücke denkbar ???
d.h. ein Überschreiben von ungeschützten Dateien.

1. libcfgimpexp.so hat damit nur am Rande zu tun, weil es wohl auch über eine passend aufgebaute Export-Datei möglich ist, eine "provideradditive.tar" zu erzeugen, allerdings nur mit "regulärem" Inhalt (es gibt da ein paar "Schlüsselwörter" in den Libs, aber das Probieren an dieser Stelle war mir bisher immer zu mühsam). Ansonsten spielt die libcfgimpexp.so hier praktisch keine Rolle.

2. Auf welcher Box hast Du denn das Entpacken dieser Datei getestet? Ich bin etwas irritiert, weil nach meiner Erinnerung da eigentlich ein anderes Verzeichnis verwendet wurde (und das habe ich auch gerade noch einmal überprüft) - zumindest dann, wenn die Datei beim Start der Box entpackt wird (die Fundstelle in der libcfgimpexp.so kannst du eben hier erst einmal abhaken, siehe 1.).

3. Wenn Du mit der "FTP-Logging-Lücke" den Aufruf eines Shell-Skripts durch einen präparierten Benutzernamen beim FTP-Login (bis 06.2x ging das IIRC) meinst (hatte ich irgendwo mal erwähnt, als ich davon ausging, daß 06.0x-Versionen nun tatsächlich Geschichte sind), dann hat das mit dem Überschreiben von Dateien ja eigentlich nichts zu tun - das war der Aufruf eines Shell-Skripts auf einem USB-Stick, weil der Name dieser Skript-Datei in den Benutzernamen eingebettet wurde. Ansonsten müßtest Du genauer werden, welche Lücke Du meinst.

4. Was sind denn "geschützte Dateien" im FRITZ!OS? Ich hatte ja geschrieben, daß das alles etwas wackelig ist, wenn es um den Schutz von Dateien über ACLs (zumindest über die herkömmlichen Flags) geht, weil eben alles als "root" ausgeführt wird. Wenn es keine geschützten Dateien gibt, kann es eigentlich auch keine ungeschützten Dateien geben ... es sind dann halt alles "Dateien" und die haben tatsächlich die (manchmal angenehme, manchmal auch sehr unangenehme) Eigenschaft, daß sie sich komplett überschreiben lassen bzw. daß sich ihr Inhalt ergänzen oder ändern läßt.

Wobei es vielleicht wärmer wird ... aber ich kann natürlich nicht in fremde Köpfe schauen und wenn ich noch deutlicher werde, kann ich auch gleich den kompletten Weg für den Exploit beschreiben (was ich ja nicht unbedingt will). Hier sind aber ziemlich offensichtlich noch einige Punkte ungeklärt bzw. sie basieren mehr auf Vermutungen als auf Tests, um diese zu bestätigen.

Das "tar"-Applet der BusyBox arbeitet - nur nebenbei bemerkt - grundsätzlich mit relativen Pfaden - wenn man mit absoluten Pfaden versucht einzupacken, wird dort der "leading slash" immer entfernt und auch wenn man eine "handgemachte" Datei mit absoluten Pfaden hätte, würde die beim Entpacken genauso behandelt werden. Auch das "Traversieren" von Verzeichnissen durch ".." im Namen einer Datei funktioniert nicht ... alles bis zum letzten Vorkommen von ".." wird aus dem Dateinamen gelöscht (inkl. des nachfolgenden Schrägstrichs, auf diesem Weg kann man also auch keinen absoluten Pfad mit einem Slash am Anfang "konstruieren") und damit fällt das auch flach. Aber man muß nicht gleich das Kind mit dem Korn in den Brunnen mit dem Bade schütten ... es könnte ja trotzdem noch Wege geben, wie man aus dem Basisverzeichnis für das Auspacken eines Tarballs "ausbrechen" kann.

Die "schlampige Programmierung" liegt hier auch eher darin, daß da nicht nur die Dat(ei)en verarbeitet werden, die man in so einem Tarball erwartet und entsprechend "haben will". Wenn man ein "tar xf -" aufruft, wird eben alles entpackt, was sich in dem Tarball auf STDIN befindet ... will man das verhindern, müßte man ggf. noch die Namen der zu extrahierenden Member angeben beim Aufruf, das macht es dann schon eine Stufe sicherer.

Nun muß man das auch nicht überkritisch sehen, was der ursprüngliche Programmierer da machte ... es ist zwar nicht per se schon sicher entworfen, aber das hatte eben vor ein paar Jahren (und mind. 3 Jahre sollte der betreffende Code alt sein, er ist nur inzwischen vom "ctlmgr" in die "libcmapi.so" umgezogen) noch keiner so richtig auf dem Schirm, daß darüber eine Box auch angegriffen werden könnte (und erst recht nicht, daß Angriffe auch aus dem LAN erfolgen könnten ;-)).

Hallo miteinander,


ich wollte hier nur meine Erfahrungen mit dem Firmware Update kundtun:


- bin bei Kabel Deutschland
- habe eine Unity Media Box gekauft (ebay ...)


Auf der Box war 6.24 installiert --> debranding auf avm. Habe die Firmware 6.61 geflasht (ist ja hier zu genüge beschrieben, danke PeterPawn für die kleine HTML Update Site).
Nach dem Update waren die certificates noch auf old/old, konnte die Box auch nicht bei KD provisionieren.


Dann ein Online-Update (am Kabel Deutschland Anschluss) auf 6.62 --> certificates sind auf new/new, kann die Box problemlos in Betrieb nehmen.


Danke für die umfangreiche Beschreibung hier und thx again an PeterPawn für das Einbringen seiner Kompetenz.

PeterPawn schrieb:

Das "tar"-Applet der BusyBox arbeitet ... damit fällt das auch flach.

Zum Vergrößern anklicken....

Hallo PeterPawn und andere Sachkundige,
nun frage ich mich, wenn ich den "ctlmgr"-Code in Datei
ansehe, ob es auch "ctlmgr"-Code gibt, der OS-Befehle wie "system(/bin/sh /var/media/ftp/datei.sh)" ausführen kann ?

leider bin ich nicht so tief in der ctlmgr-Materie vertraut,
aber evtl. kann jemand Hinweise geben

Gruß
ncc-1701

Es gibt andere Möglichkeiten als das Traversieren von Verzeichnissen über "..", um beim "tar"-Applet der BusyBox auch außerhalb des eigentlichen Zielverzeichnisses (i.d.R. ist es das gerade aktuelle beim Aufruf, solange kein Parameter "-C" angegeben wurde) zu schreiben ... zumindest bei der von AVM immer noch verwendeten BusyBox 1.22.irgendwas.

Zwar gibt es inzwischen einen Patch dafür/dagegen (IIRC war die CVE-ID des Bugs "CVE-2011-5325", der sollte im BusyBox-Bugzilla zu finden sein), aber ziemlich offensichtlich ist das Problem im von AVM verwendeten Quell-Code noch vorhanden, denn auch die BusyBox-Version in der 141.06.61 ist dafür noch anfällig (will heißen, es funktioniert).

Wenn man außerhalb des Zielverzeichnisses schreiben kann, dann ist das ja auch nur die halbe Miete ... man kann dann zwar Dateien (in beschreibbaren Teilen des Dateisystems, was sich bei der FRITZ!Box praktisch alles unterhalb von /var versammelt, der Rest ist (größtenteils) "read-only") neu erstellen, aber schon das Editieren geht nicht mehr - dazu bräuchte es ja bereits ein Kommando und nur weil man Dateien überschreiben kann, kann man ja noch lange kein eigenes Kommando ausführen.

Aber der angedachte "Verwendungszweck" für das Freischalten von DVB-C auch bei Provider-Branding wäre bereits damit umsetzbar ... dafür braucht es ja nur die oft genug erwähnte Datei mit dem richtigen Inhalt und den Rest übernimmt dann das FRITZ!OS von alleine. AVM hat ja für die 06.6x diesen Mechanismus in der Retail-Version (auf der Basis des verwendeten Brandings in $OEM) sogar noch einmal geändert/entschärft, damit da kein Provider (absichtlich oder versehentlich) über SNMP an den Firmware-Features einer Kunden-Box herumschraubt.

- - - Aktualisiert - - -

Seitdem die Versionen 06.61 und 06.62 mehr oder weniger frei zugänglich sind per Download von AVM, ist es ja auch kein wirkliches Problem mehr, einen Blick in die Firmware zu werfen, indem man sich eines der Images nimmt und es entpackt.

Schon dabei kann man dann (teils erhebliche) Unterschiede und Gemeinsamkeiten mit der Firmware der DSL-Boxen entdecken und genauer untersuchen und der von mir angesprochene Mechanismus zum Freischalten der DVB-C-Funktionen (über 'docsis_state_changed" beim "Eintreffen" eines config-Files vom Provider) ist dort genauso nachzulesen, wie das anfängliche "Verriegeln" dieser Funktion bei einem der beiden (bisher bekannten) Provider-Brandings (in der /etc/init.d/rc.conf).

Zwar kann man auch dann ohne Shell-Zugang die Firmware noch nicht immer "live testen", aber während früher die Suche nach potentiellen Schwachstellen noch auf Analogien zur Firmware bei den DSL-Modellen angewiesen war und die dort ebenfalls vorhandenen Lücken zumeist eher uninteressant waren (weil der Shell-Zugriff da ja leichter zu haben wäre), ist das jetzt mit der nunmehr von AVM frei zugänglich gemachten Firmware für die 6490 auch kein wirkliches Problem mehr, da die spezifischen Schwachstellen "durch Augenschein" zu identifizieren und ggf. zu testen, wie weit sich diese ausnutzen ließen. Bisher war diese Firmware zusätzlich noch dadurch vor solchen Untersuchungen geschützt, daß sie eben nicht frei erhältlich war und die Analogien zur DSL-Firmware auch nicht immer stimmen (müssen) - man mußte erst den Shell-Zugriff haben, bevor man sich die konkrete Firmware ansehen konnte.

Das ist nunmehr entfallen und deshalb ist es um so wichtiger, daß identifizierte Lücken (zeitnah) geschlossen werden, wenn darüber auch der Einstieg in die DOCSIS-Firmware möglich ist. Früher eher eine Petitesse, weil es bei den DSL-Modellen eben auch einfacher funktioniert - heute der Einstieg in den Shell-Zugriff auf einer 6490.

Ich bin schon gespannt, was mit der 6590 kommen wird - wobei ich die inzwischen gar nicht mehr so richtig erwarte, denn für die Angebote der Provider reicht für die nächsten Jahre vermutlich die 6490 noch und so überbordend dürfte das Geschäft mit den DOCSIS-Boxen bei den Retail-Kunden auch nicht sein, daß sich das wirklich lohnt.

Man muß nur mal die Probleme und Verzögerungen bei der 7580 in die Überlegungen einbeziehen ... ich glaube nicht wirklich, daß AVM unbedingt noch eine weitere (unnötige) Baustelle in der Produkt-Palette mit einer neuen "FRITZ!Box Cable" bräuchte. Zwar ist die 6490 beim WLAN nicht mehr unbedingt "top", aber angesichts des WLANs und der aktuellen Probleme damit in der 7490/7580 ist vielleicht die ältere, dafür aber funktionierende Implementierung auch gar nicht so übel.

Eventuell wäre noch ein USB3-Anschluß, der vom x86-Core bedient wird, ein Merkmal, das zum Kauf einer 6590 inspirieren könnte - aber dazu muß der erst einmal nachweisen, daß damit der Zugriff auf Speicher-Volumes auch wirklich zügiger erfolgt und nicht weiterhin auf demselben Niveau herumdümpelt wie bei USB2.

Den direkten Widerspruch zwischen USB3 und 2,4 GHz-WLAN müßte AVM dann innerhalb des knappen Platzes in so einer Box auch noch überzeugend auflösen ... ich habe selbst noch keine 7580 getestet (so etwas mache ich immer erst dann, wenn sich eine halbwegs stabile Firmware abzeichnet), aber irgendwo habe ich m.E. auch etwas von Problemen mit dem WLAN gelesen, wenn bei der 7580 ein USB3-Gerät an einem der USB-Anschlüsse hing und arbeitete. Ich hatte ja immer so ein wenig die Hoffnung, daß AVM die SATA-Schnittstelle des Puma6 (der sollte eine haben nach dem, was man so liest) nach außen legen könnte - inzwischen sterben eSATA-Lösungen langsam aber sicher aus. Aber die hätten vermutlich weniger Probleme bei der Koexistenz mit WLAN auf engem Raum - allerdings dürfte die Schnittstelle im SoC sitzen und per se eher nicht für externen Anschluß (mit allem, was dabei zusätzlich zu berücksichtigen ist bei der "Elektrik") geeignet sein.

PeterPawn schrieb:

(...) daß AVM die SATA-Schnittstelle des Puma6 (der sollte eine haben nach dem, was man so liest) nach außen legen könnte - inzwischen sterben eSATA-Lösungen langsam aber sicher aus.

Zum Vergrößern anklicken....

Der einizige mass-storage controller im puma 6 (atom) ist ein (ungenutzter) IDE controller (gemaess Liste der PCI devices). Oder meinst du puma 7 (ich gehe davon aus dass die neue FB den hat)?

Das dürfte der SATA-Controller sein ... wer baut denn heutzutage noch IDE-Controller auf PATA-Basis irgendwo ein (mal vollkommen von den dazu notwendigen Pins abgesehen)? Wenn das nicht nur die Emulation irgendeines Controllers für das eMMC sein sollte, dann sollte es dieser sein. Welche PCI-ID hat der denn nach Deiner Anzeige (habe gerade keine Lust, selbst nachzusehen)?

Nach dem, was man bisher in den Quellen von AVM sehen kann, baut auch die 6590 (zumindest derzeit, bis zum tatsächlichen Erscheinen könnte AVM das vermutlich noch ändern, dann aber wohl kaum in den nächsten 6 Monaten damit auflaufen) auf den Puma6 oder der ist so weit zum Puma7 kompatibel (ich kenne keine Datenblätter, die über das von Intel freiwillig veröffentlichte Material hinausgehen und das "competence center" betritt man dort nur mit passenden Credentials), daß es für die Firmware keinen Unterschied macht.

arch/arm/mach-avalanche/puma6/avm_hw_config.c schrieb:

12 struct _avm_hw_config_table avm_hw_config_tables[] = {
13 { .hwrev = 199, .table = avm_hardware_config_hw199a }, /*--- FRITZ!Box Puma6 6460 ---*/
14 { .hwrev = 204, .table = avm_hardware_config_hw199a }, /*--- FRITZ!Box Puma6 6490 ---*/
15 { .hwrev = 213, .table = avm_hardware_config_hw199a }, /*--- FRITZ!Box Puma6 6490 eMMC ---*/
16 { .hwrev = 220, .table = avm_hardware_config_hw199a }, /*--- FRITZ!Box Puma6 6590 ---*/
17 };
18 EXPORT_SYMBOL(avm_hw_config_tables);

Zum Vergrößern anklicken....

Der einzige mass storage controller ist 00.e.0:
class code: 01018a (IDE)
device ID: 0x0c80

Ich dachte an puma7 weil der so gross fuer DOCSIS 3.1 beworben wird.

fesc schrieb:

Ich dachte an puma7 weil der so gross fuer DOCSIS 3.1 beworben wird.

Zum Vergrößern anklicken....

Ja, da sehe ich auch ein paar Widersprüche ... aber die neuen Feature bei DOCSIS 3.1 würde ich überweigend ohnehin eher in Software sehen (BPI+, PKI-Änderungen) oder in einem Frontend-Prozessor (wenn es um neue Modulationsverfahren und um die Verwendung von "subchannels" geht). Ohne konkrete Kenntnisse, was der Puma6 schon leisten kann und was es dafür für FEPs gibt und was der Puma7 da anders macht, ist das aber alles auch nur von mir geraten.

Auch die Frage, welche DOCSIS3.1-Merkmale die 6590 konkret unterstützen soll, ist mir noch nicht ganz klar - es gibt ja auch genug Merkmale und Optionen im Standard, deren Implementierung nicht unbedingt erforderlich ist, um sich mit dem Titel "DOCIS 3.1" zu schmücken.

Thema provideradditive.tar:

PeterPawn schrieb:

Aber der angedachte "Verwendungszweck" für das Freischalten von DVB-C auch bei Provider-Branding wäre bereits damit umsetzbar ... dafür braucht es ja nur die oft genug erwähnte Datei mit dem richtigen Inhalt und den Rest übernimmt dann das FRITZ!OS von alleine. AVM hat ja für die 06.6x diesen Mechanismus in der Retail-Version (auf der Basis des verwendeten Brandings in $OEM) sogar noch einmal geändert/entschärft, damit da kein Provider (absichtlich oder versehentlich) über SNMP an den Firmware-Features einer Kunden-Box herumschraubt.

Zum Vergrößern anklicken....

Hallo PeterPawn und andere Sachkundige,
ich denke der Busybox-Bug 8411 https://bugs.busybox.net/show_bug.cgi?id=8411
"tar: directory traversal via crafted tar file which contains a symlink pointing outside of the current directory"

erlaubt die Erstellung der für DVB-C benötigten Datei "/var/tmp/avmfeature.conf" mit Inhalt "0x10" mittels provideradditive.tar:

PeterPawn schrieb:

Incident-Nummer - die 480894 -
...
Also rufe ich hiermit zum "gemeinsamen Nachdenken" auf ...

Zum Vergrößern anklicken....

die "Fernsteuerung" einer Fritzbox mittels Browser (d.h. das serverseitige Ausführen von CGIs und LUA-Skripten) hängt bei FBs mit dem Softlink /var/html im RamDisk Bereich (tempfs) zusammen;
Auszug einer FB7490, jedoch sollte eine FB6490 FW 06.31 analog sein;


das Verzeichnis /var/html - oder der Ort auf den der Softlink zeigt - ist das wichtige Basisverzeichnis des Webservers
... und LUA-Skripte können modifiziert werden und erlauben auch Zugriff auf OS-Ebene.

Gruß
ncc-1701

ncc-1701 schrieb:

(...) hängt bei FBs mit dem Softlink /var/html im RamDisk Bereich (tempfs) zusammen;

Zum Vergrößern anklicken....

Sicherlich auch eine Möglichkeit, aber wirklich nur in diesem sehr speziellen Fall, daß der Besitzer auch gleichzeitig "der Angreifer" ist.

So eine gesonderte Verzeichnisstruktur für den Webserver (auf die ja dann der Symlink zeigen müßte) versteckt man nicht mal so auf die Schnelle auf einem USB-Stick, so daß der Besitzer der Box davon wenig oder nichts mitbekommt und dann braucht es für die Ausführung eigenen Codes ja noch den Browser oder zumindest den externen HTTP-Request. Das Kopieren des bestehenden Verzeichnisbaums für den Webserver und die nachträgliche Modifikation von Dateien dort, setzt dann schon wieder die Ausführung von Kommandos voraus - das wäre also auch eher nicht machbar, zumindest nicht als "Einstieg" in die Ausführung von eigenen Kommandos.

Will man diesen ganzen Zweig für den Webserver "verstecken" und bei jedem Start mit entpacken lassen, ist das für einen Node im TFFS auch etwas viel ... früher gab es eine Beschränkung auf 32 KB komprimierten Inhalts pro TFFS-Node - lag am Buffer für die zlib-Kompression, ob die Rahmendaten beim TFFS3-Treiber noch stimmen, müßte ich nachsehen.

Aber mit Schreibzugriffen auf die Verzeichnisstruktur unterhalb von "/var" hat man dann so viele Möglichkeiten, da auch andere Dateien zu ersetzen, daß nur noch die Phantasie das limitierende Element ist.

Früher hatte AVM mal in "firmwarecfg" ein zusätzliches Kommando bzw. eine zusätzliche Aktion nach dem Aufruf eines "tar"-Kommandos eingebaut, welches nach dem Entpacken eines (angeblichen) Firmware-Images immer wieder die Datei "/var/post_install" aus "/var.tar" (das liegt im Wurzelverzeichnis des SquashFS-Images) extrahierte, weil diese beim Entpacken ersetzt werden konnte (da wurde noch nach "/var" entpackt und nicht nach "/var/unpack"). Seitdem das entfallen ist, wird auch diese Datei nicht wiederhergestellt ... die wird zwar erst beim Reboot von "init" aufgerufen, aber das ist natürlich trotzdem eine nette Handreichung, wenn man mal davon ausgeht, daß die Box korrekt "heruntergefahren" und nicht einfach der Stecker gezogen wird.

Wenn sich schon mal jemand die "/var/install" genauer angesehen hat (noch einmal, die Firmware stellt AVM ja inzwischen freundlicherweise zur Untersuchung bereit), dann findet er dort ja auch die Kommandos zum Modifizieren der "/var/post_install", weil die eigentliche Installation neuer Firmware immer bis zum nächsten Neustart warten muß ... da wird dann die "/var/post_install" abgearbeitet und die neue Firmware in die richtigen Partitionen geschrieben; den Neustart löst der Update-Prozess dann noch selbst aus.

Hier wäre z.B. ein Ansatzpunkt, wie man ein Update auch vermeiden/unterdrücken und stattdessen erst einmal die neue Firmware auf den Speicher für das NAS kopieren könnte (auch so ein Vorgang, der eigentlich nur bei einer 6490 vom Provider interessant ist, denn bei anderen Modellen gibt es die Firmware zum freien Download, ebenso bei der Retail-Version der 6490 und da muß nichts "abgefangen" werden).

Da die "/var/post_install" von der "/var/install" nur fortgeschrieben wird (ich empfehle jedem, da einfach einmal hineinzuschauen), kann schon ein "exit" am (ursprünglichen) Ende dafür sorgen, daß die Kommandos zum Update nicht mehr abgearbeitet werden und vor diesem "exit" könnte man die Daten erst einmal auf den NAS-Speicher kopieren. Seitdem man den ursprünglichen Inhalt der Datei problemlos aus der AVM-Firmware extrahieren kann, ist das Einbringen eines kompletten, modifizierten Skripts auch kein ernsthaftes Problem mehr.

Und im Aufruf von eigenen Kommandos an solchen Stellen (es gibt noch andere Möglichkeiten) liegt dann auch die Gefahr für "normale FRITZ!Boxen" bei dieser Datei "provideradditive.tar". Die wird eben ziemlich blind beim Start des Systems entpackt (es gibt da noch einen Pferdefuß, mal schauen, ob der auch noch jemandem auffällt - warum gibt es eigentlich auch ein "tar cf /var/flash/provideradditive.tar provider_additive" in der libcmapi.so?) und kann mit passend zurechtgebogenem Inhalt Dateien im "tmpfs" der Box überschreiben (recht weit vorne im Startprozess).

Wenn jetzt wirklich ein Provider hingeht und eine derart modifzierte Datei anstelle der "normalen" "provideradditive.tar" installiert, dann kriegt man die - wenn andere Einstellungen auch noch passend gemacht werden - nicht einmal mit dem AVM-Recovery-Programm entfernt (das weigert sich ja und bei einer Provider-Box ist das bei weitem nicht so ungewöhnlich wie bei einer eigenen, da schrillen dann auch nicht gleich die Alarmglocken beim Kunden).

Werkseinstellungen überlebt die Datei wieder ... das kriegt man also gar nicht so ohne weiteres wieder aus der Box heraus, da muß man sich dann schon sein eigenes TFFS-Image basteln und diesen zusätzlichen Stream wieder auf dem Weg entfernen, auf dem man ihn eingebaut hat (oder man löscht halt vorher die "provider"-Variable im Bootloader und läßt dann das Recovery-Programm auf die Box los).

Auch wenn das vielleicht kein Provider wirklich benutzen wird (wobei man auch hier ja schon sehen kann, daß AVM eben gar nicht garantieren kann, daß ein Provider (oder jemand anderes) nicht auch vorhandene Lücken mißbraucht), so kann es doch auch wieder ein Dritter als Angreifer benutzen. Zwar muß der erst einmal die Chance haben, ein eigenes TFFS-Image zu schreiben, aber das kann praktisch jeder Computer machen, der zum Zeitpunkt des Starts einer FRITZ!Box eine Kabelverbindung zu dem Gerät hat. Nichts anderes als der FTP-Zugriff auf den Bootloader wird dafür benötigt und wie das genau geht (ein spezialisiertes Programm kriegt das auch definitiv auf Anhieb und ohne mehrmalige Versuche hin), haben viele hier bereits von Hand durchexerziert.

Das einzige augenfällige Problem nach dem Schreiben so eines "poisoned" TFFS-Images wäre es, wenn dabei die vorher noch vorhandenen Einstellungen auf einmal weg sind - und das wären sie, wenn der Angreifer wie das AVM-Recovery-Programm vorgeht und nur die auszulesenden Daten und seinen eigenen Payload für Node 29 zu einem neuen Image zusammensetzt. Aber seit der Einführung der "erweiterten Support-Daten" gibt es ja für den Besitzer der Box die Möglichkeit, sich den aktuellen Inhalt des TFFS im Rahmen der Support-Daten auch ausgeben zu lassen ... wenn das einem Angreifer ebenfalls gelingen sollte (er braucht nur eine einzige gültige SID für eine GUI-Session auf der FRITZ!Box), dann kann der sogar ein TFFS-Image für den nächsten Start bauen, nach dessen Installation der Besitzer gar nicht merkt, daß da mehr drin steht, als er eigentlich möchte.

Auch wenn die Lücke in diesem Thread am Ende vielleicht als positiv angesehen werden mag ... sie ist durchaus auch ein erhebliches Sicherheitsrisiko für andere Modelle und dabei interessiert mich gar nicht so sehr, wie wahrscheinlich so ein Angriff sein mag und welche Vorkenntnisse ein Angreifer dafür bräuchte.

Schon das gezielte Entpacken nur der Dateien, die in so einer "provideradditive.tar" normalerweise enthalten sein sollten (steht ja weiter vorne, was da so drin ist), würde dieses Problem merklich entschärfen, weil eben der Symlink gar nicht erst erstellt würde.

Warum AVM da schon für die erste Untersuchung 4 Wochen brauchte (und da kam ja auch nur eine Mail, daß das weiter untersucht würde, nachdem ich nach drei Wochen dann mal nachgefragt hatte) und es am Ende gar nicht weiter verfolgte, geschweige denn behoben hat (jedenfalls nicht bis zu diesem Laborzweig für die 7490), ist mir auch etwas rätselhaft - schon die erste Mail meinerseits hatte einen Anhang, in dem das Schreiben einer modifizierten "/var/post_install" über einen solchen Symlink demonstriert wurde.