freetz-ng und die FW7.39 + Boot Manager

[georg3003]

Hallo,
Bitte nicht böse sein, daß ich frage, wäre es rein theoretisch möglich das modfs auch auf eine 7590 (ax) zu bringen?

Und falls ja geht das über das Script, wie bei der 7490? oder nur über Freetz-ng wenn ich quasi mir ein neues image basteln lassen. Ist das wie fwmod zu behandeln oder ganz anders? Kleiner Tip wo ich das evtl. Nachlesen zum nachmachen finden kann? Ist es bei den "Other Patches" die Auswahl zu treffen? Oder wo kann ich die Auswahl treffen, falls es auf eine 7590(ax) geht?

Vielen Dank
Georg

 

[PeterPawn]

Noch Fragen?

Schon ... wäre halt nützlich zu wissen, ob das jetzt die Version mit os.execute ist oder ob nur das io.popen durch das direkte Lesen der Cache-Datei ersetzt wurde.

Kleiner Tip wo ich das evtl. Nachlesen zum nachmachen finden kann?

Irgendwo hier gibt es einen (mittlerweile auch wieder recht langen) Thread, wo ich das mit dem Verwenden der modfs-Skripte für die Modifikation von GRX5-Boxen und später auch für IPQ-Boxen ausführlich abgehandelt habe. Steht vermutlich irgendwo in "Modifikationen" - ich kenne aber den Titel nicht genau (war irgendeine Abtrennung aus einem anderen Thema). Da mußt Du also mal selbst suchen, wenn ihn nicht andere (@Insti wäre z.B. ein Kandidat, da sich einiges in dem Thread an ihn richtete, iirc) direkt verlinken können.

 

[georg3003]

Irgendwo hier gibt es einen (mittlerweile auch wieder recht langen) Thread, wo ich das mit dem Verwenden der modfs-Skripte für die Modifikation von GRX5-Boxen und später auch für IPQ-Boxen ausführlich abgehandelt habe. Steht vermutlich irgendwo in "Modifikationen" - ich kenne aber den Titel nicht genau (war irgendeine Abtrennung aus einem anderen Thema). Da mußt Du also mal selbst suchen, wenn ihn nicht andere (@Insti wäre z.B. ein Kandidat, da sich einiges in dem Thread an ihn richtete, iirc) direkt verlinken können.

Oh Danke zumindest für diese Info, somit weiß ich, daß ich etwas finden muss.

 

[PeterPawn]

@B612 - was mir auch noch auffällt: Eigentlich sollte bei der 7520 (bzw. bei beiden IPQ-Modellen in dieser Linie) keine Option zum Ändern des Brandings angeboten werden, denn das geht m.W. ohnehin nicht.

Dennoch ist switch_branding_support=true in der Ausgabe zu sehen - das sollte (obwohl ich genau weiß, wie man das anhand des Inhalts des Konfigurationsbereichs auf der Box (und das meint nicht die Versionsnummer von EVA) auch exakt ermitteln kann) bei einer Box, die mit einem FDT gebootet wird, eigentlich nicht aktiviert werden: https://github.com/PeterPawn/YourFr...b62b50dff421/bootmanager/gui_bootmanager#L223 - solange das Verzeichnis /proc/device-tree/chosen existiert.

Wenn AVM das jetzt auch noch geändert hat (und das erwähnte Verzeichnis nicht (mehr) existierten sollte - auch wenn das ebenfalls wieder "komisch" wäre, wobei das Publizieren des FDT im procfs auch optional ist iirc), dann müßte ich wohl doch noch das exakte Zerlegen des Konfigurationsbereichs im Flash einbauen, um nicht länger auf "unzuverlässige Merkmale" zurückgreifen zu müssen.

 

[B612]

Schon ...

Dachte ich mir. Ich aber auch an dich!

1.

io.popen

geht mMn nicht mehr. Das ist aber noch das kleinere Übel da man es mit dem io.open ersetzen kann. (Habe ich für das Bild gemacht) Dafür muss aber die Datei in /var/tmp/ schon vorhanden sein. Gut - dafür fallen mir ca. 10 Möglichkeiten ein wo man das beim Start der FB rein setzen könnte und du hast bestimmt über 100 Möglichkeiten.

2.

os.execute

Geht mMn auch nicht mehr. Und das ist mMn das größere Übel weil das in der reboot.lua für den eigentlichen reboot gebraucht wird (ca.14te Zeile von unten). Und dafür fällt mir noch kein Ersatz ein.

BTW: Der reboot geht in meinem Bild natürlich nicht. Nur die Anzeige geht. Aber das ist ja schon mal ein kleiner Schritt in die richtige Richtung.

So jetzt die GROSSE Frage an dich: Geht das irgendwie auch ohne poppen und ohne execute? Oder besser gefragt: bekommst du das ohne die beiden ?? hin?

 

[PeterPawn]

Da denke ich dann mal eine Weile drauf herum ... solange File-I/O noch funktioniert (das nutzt AVM ja selbst - das Entfernen/Blockieren von system()-Calls auf anderen Wegen trägt nach meiner Überzeugung auch nicht wirklich zum Erhöhen der Sicherheit bei und ist eher ein "unfreundlicher Akt"), kann man auch ganz einfach eine Shell mit ihrem STDIN-Handle in einem (durchlaufenden) Service hinter eine Pipe legen:

~ # rm -f /var/run/shell.fifo; mknod /var/run/shell.fifo p; sh < /var/run/shell.fifo & printf "/usr/bin/gui_bootmanager debug" >/var/run/shell.fifo
system type = VR9
system selector = 1
system is switched = true
system branding = 1und1
system branding is changeable = true
active kernel = /dev/mtdblock0
active filesystem = /wrapper/filesystem_core.squashfs
active system version = 113.07.24-86493
active system date = 18.02.2021, 17:12:04 Uhr
active system modification date = 02.03.2021, 01:57:23 Uhr
active system modification source = modfs
brandings supported on active system = 1und1 avm avme
inactive kernel = /dev/mtdblock2
inactive system is installed = true
inactive filesystem = mount:/dev/mtdblock3:/filesystem_core.squashfs
inactive filesystem mounted on /var/tmp/9161_1644609859/alt_root
inactive system version = 113.07.19-77201
inactive system date = 06.04.2020, 20:59:45 Uhr
inactive system modification date = 12.06.2020, 17:45:47 Uhr
inactive system modification source = modfs
brandings supported on inactive system = 1und1 avm avme
inactive filesystem dismounted
^C
~ #
[2]+  Done                       sh 0</var/run/shell.fifo
~ #

So wäre also schon mal "komfortabel" der Zugriff auf eine Shell möglich (denn das Schreiben in die Pipe kann auch deutlich später und von anderer Stelle erfolgen) ... aber auch mit einiger Unsicherheit, denn da kann dann wieder jeder schreiben (und deshalb nimmt man da dann halt auch nicht direkt ein /bin/sh). Ich hoffe mal nicht, daß sich AVM auf einen "Kampf" einlassen würde, bei dem es um das komplette "Verhindern" von OS-Aufrufen geht ... irgendein Weg findet sich immer, solange man die Firmware modifizieren kann.

Und das sogar üblicherweise "nur mit Bordmitteln" (wozu ich alles zähle, was von AVM installiert wurde PLUS eigene Dateien, die aber keine Binaries sind) ... das mknod verwendet AVM selbst (u.a. beim Erzeugen der Minor-Nodes im TFFS) und das müßte man schon seiner Fähigkeiten mit dem Typ p berauben - wobei das ohnehin kein POSIX wäre, denn das kennt nur ein mkfifo (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkfifo.html) und das mknod mit dieser Option ist "GNU-Slang".

Um das dann wieder sicherer zu bekommen, kann man sich einen Service erzeugen, dessen Shell-File die Daten ermittelt und dann in Schleife läuft, um diese Angaben einerseits in einen FIFO als Ausgabe zu schieben (woher der Lua-Code die Daten dann lesen kann) und parallel auf einem weiteren FIFO auf eine Eingabe zu lauschen, die dann eine Umschaltung triggert.

Das hätte sogar wieder den Vorteil, daß man diesen Trigger auch von anderer Stelle auslösen könnte (in modfs ist z.B. bisher ein zusätzlicher Aufruf von gui_bootmanager enthalten: https://github.com/PeterPawn/modfs/blob/f3cff1971db83152aa949944b069e26994e5c156/modfs#L3579 - um die ausgeführten Änderungen durch modfs zu erfassen) und dieses Triggern auch den "internen Zustand" des Skripts dahingehend ändern kann, daß die ausgegebenen Daten (insbesondere die Zeile system_is_switched, die für die Auswahl des korrekten Radio-Buttons in der Browser-Anzeige erforderlich ist) automatisch angepaßt werden.

---

Wobei mich schon interessieren würde, was sich AVM beim "Stilllegen" der Shell-Aufrufe aus Lua heraus "gedacht" hat - mal unterstellt, daß das tatsächlich absichtlich erfolgte. Es gibt - wie gesagt: solange man die Firmware ändern kann - noch so viele andere Optionen, wie man wieder zu einem Shell-Zugriff gelangen kann (bis hin zum Start einer Shell (analog zu einem rcmd-Aufruf) über den inetd), die viel "gefährlicher" sind und von denen manche sogar "zur Laufzeit" funktionieren.

Wie z.B. der Weg über den inetd, denn dessen Control-File ist "writable" und wäre auch wieder über Lua-Code per io.write zu verändern. Ähnliches gilt sogar für die Utilities, die vom Kernel für bestimmte Zwecke aufgerufen werden ... z.B. /proc/sys/kernel/hotplug oder /proc/sys/kernel/modprobe, wo man durch einfachen Schreibzugriff (und das läuft nun mal bisher alles mit Root-Rechten, wenn AVM das nicht auch noch saniert) auch einfach ein eigenes "Programm" eintragen kann, was der Kernel dann an passender Stelle aufruft und da muß man sich nur überlegen, wie man das dann passend triggert.

Was bei modprobe noch schwerer ist als bei hotplug (denn ein /sbin/hotplug existiert in der originalen Firmware nicht und man muß das nicht mal als "Wrapper" konzipieren) - aber das dann zu triggern, gelingt tatsächlich sogar ohne Authentifizierung auf der LAN-Seite, weil ein per ForceTermination getriggerter Neuaufbau der Verbindung auch gleichzeitig dafür sorgt, daß die ganzen Storage-Geschichten neu initialisiert werden (auch wenn ich das Beenden der WAN-Verbindung hier über ein Shell-Kommando auslöse):

~ # echo -e "#!/bin/sh\necho 'hotplug' >/dev/console\n" >/var/hotplug.sh
~ # chmod a+x /var/hotplug.sh
~ # /var/hotplug.sh
hotplug
~ # echo /var/hotplug.sh >/proc/sys/kernel/hotplug
~ # msgsend -a dsld disconnect
Feb 11 22:07:32 multid[2473]: dhcp_reset_binary_options: iface lan not found
~ # Feb 11 22:07:32 multid[2473]: dhcp_reset_binary_options: iface lan not found
Feb 11 22:07:33 multid[2473]: dhcp_reset_binary_options: iface lan not found
hotplug
Feb 11 22:07:34 multid[2473]: dhcp_reset_binary_options: iface lan not found
[Supervisor] Info: stop smb2.service

---- NQ Server was shut down ---
[Supervisor] Info: smb2.service exit success
[Supervisor] Info: start smb2.service
Feb 11 22:07:38 wsdd[9889]: starting ... (normal)
NQSERVER: server is ready
[Supervisor] Info: stop smb2.service

---- NQ Server was shut down ---
[Supervisor] Info: smb2.service exit success
[Supervisor] Info: start smb2.service
Feb 11 22:07:45 wsdd[10105]: starting ... (normal)
hotplug
NQSERVER: server is ready

Ich weiß natürlich nicht genau, wieviele dieser Wege AVM parallel zu den Lua-Änderungen (die ich jetzt mal unterstelle, auch wenn ich sie selbst noch nicht "in Aktion" gesehen habe) noch verbauen will/würde - und ich hoffe natürlich auch, daß es sich dabei dann um "allgemeine Verbesserungen im Sinne der Sicherheit" handelt und nicht um gezielte Sabotage.

Vielleicht macht ja mal jemand mit der originalen BusyBox eine Liste der enthaltenen Applets - es wäre (wenn AVM da tatsächlich noch weiter die Axt anlegen will) ja auch interessant, was da überhaupt noch enthalten ist. So kann ja z.B. auch das env-Applet der BusyBox genutzt werden, um ein Programm zu starten (und nicht nur das sh-Applet) - auch das geht notfalls wieder über den inetd. Wobei man spätestens beim Modifizieren der Firmware ja auch wieder eine eigene BusyBox hinzufügen könnte - dann müßte man halt von der minimalinvasiven Doktrin (die ich für den Boot-Manager eigentlich verfolge) abweichen. Gleichzeitig setze ich da eigentlich ABSICHTLICH nur noch auf POSIX-Kommandos in den Shell-Skripten (zumindest in der neuen Version im gesonderten Branch), denn dann funktioniert das einigermaßen unabhängig von Modell und Architektur der Boxen (zumindest was die Byte-Order und den Prozessor angeht) und es müssen nicht zusätzlich noch gesonderte Binaries "verwaltet" werden.

---

Ich wäge das mal noch etwas ab, wie man es am besten umsetzt ... sollten sich noch weitere Infos finden lassen (u.a. die o.a. Liste der Applet und vielleicht auch mal ein eigener Versuch mit dem o.g. Einsatz von Pipes für den Shell-Interpreter, damit ich weiß, ob mknod ... p funktioniert), nehme ich die auch gerne, denn das beeinflußt dann die Entscheidung natürlich auch.

 

[PeterPawn]

Ich habe mal zwei Varianten eines denkbaren Wrapper-Skripts eingecheckt:

YourFritz/bootmanager_wrapper_1 at main · PeterPawn/YourFritz

dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.

github.com

YourFritz/bootmanager_wrapper_2 at main · PeterPawn/YourFritz

dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.

github.com

mit dem man einen Service (über supervisor gestartet) realisieren könnte, der vom Lua-Code aus über "normale" I/O-Operationen (die ja wohl noch funktionieren) genutzt werden kann.

Beide Varianten lesen "Kommandos" aus dem FIFO /var/run/bootmanager/input (welche, steht im Header der jeweiligen Datei) und stellen die Daten, die für das Frontend benötigt werden (also die Ausgabe von gui_bootmanager get_values) unter /var/run/bootmanager/output bereit. Gestoppt werden sollte das Skript über das Kommando stop (nach /var/run/bootmanager/input geschrieben, aber bitte mit einem Zeilenende) - dabei werden dann noch einige Dateien abgeräumt, damit weitere Starts nicht an irgendwelchen existierenden Resten scheitern.

Ansonsten unterscheiden sich beide Varianten darin, wie sie angesprochen werden können. Die Variante 1 kennt auch noch ein get_values-Kommando, wobei hier die Daten parallel aus dem Ausgabe-FIFO gelesen werden müssen (und zwar komplett bis zum Ende), weil ansonsten der FIFO blockiert. Die zweite Variante stellt die Ausgabedaten IMMER bereit - auch unabhängig von einem zuvor gegebenen "Kommando". Auch hier muß aber immer der komplette Inhalt ausgelesen und die Datei danach geschlossen werden.

Variante 1 arbeitet dann ohne Cache-File und ruft die Daten bei jedem get_values-Kommando live ab (also mit nocache als Parameter), während Variante 2 immer nur die Cache-Datei in /var/tmp ausgibt. Dafür kann man dann bei Variante 2 mit dem clear_cache-Kommando die zuvor gesammelten Daten noch entsorgen, dabei werden dann auch gleich die aktuellen Daten neu erstellt - und beim nächsten Auslesen des Ausgabe-FIFO liegen dann die neuen Daten vor (weil auch das Cache-File erneuert wurde).

Damit sollte sich jetzt (mit passendem service-File für den supervisor von AVM) ein Service einrichten lassen, der nach dem Systemstart permanent aktiv ist und die FIFOs bedient. Auf die kann dann mit einfachen I/O-Funktionen in Lua zugegriffen werden - bei der Ausgabe (die ja dann nach /var/run/bootmanager/input schreiben muß) aber bitte beachten, daß die auch im "write mode" geöffnet wird (siehe https://www.lua.org/manual/5.1/manual.html#5.7) - Standard ist "nur lesen".

~ # sh /nand/bootmanager_wrapper &
~ # cat /var/run/bootmanager/output
active_version="113.07.24-86493"
active_date="18.02.2021, 17:12:04 Uhr"
active_modified_by="modfs"
active_modified_at="02.03.2021, 01:57:23 Uhr"
active_brandings="1und1 avm avme"
inactive_version="113.07.19-77201"
inactive_date="06.04.2020, 20:59:45 Uhr"
inactive_modified_by="modfs"
inactive_modified_at="12.06.2020, 17:45:47 Uhr"
inactive_brandings="1und1 avm avme"
current_branding="1und1"
switch_branding_support=true
current_switch_value=0
system_is_switched=false
~ # printf "stop\n" >/var/run/bootmanager/input
~ # ls -l /var/run/bootmanager
ls: /var/run/bootmanager: No such file or directory
[1]+  Done                       sh /nand/bootmanager_wrapper
~ #

- ein Beispiel mit der Variante 2.

 

[koyaanisqatsi]

Moinsen


Was io.popen() und os.execute() angeht.
Aus Sicherheitsgründen werden die Funktionen/Methoden der Libraries io und os gerne mal sandboxed*.
Genau wie bei dieser Online Demo: https://www.lua.org/cgi-bin/demo?globals
Gewissheit bringt euch vielleicht, wenn ihr auch mal reinschaut in die tables io und os.
Dabei könnt ihr mal schauen ob AVM das ordentlich gemacht hat
...denn normalerweise werden vollständige Kopien in package.loaded.[io und os] für require() vorgehalten.
Sind die auch weg? Und wenn nicht, sind sie noch unberührt?
Wenn ja, dann reicht: io = require('io') os = require('os')
( Weil require() schaut immer zuerst in package.loaded nach und bei Erfolg wird das dann auch geladen )
...um sie zu "restaurieren".


* Die komplette Library fehlt oder einzelne Funktionen/Methoden sind entfernt worden

 

[PeterPawn]

@koyaanisqatsi :
Da der Lua-Code, den ich in den AVM-Code einfüge, ja nicht im "luftleeren Raum" arbeitet, MÖCHTE ich keine zusätzlichen Requirements verwenden - selbst wenn das im aktuell vorhandenen AVM-Code keine Auswirkungen haben würde. Das widerspricht eben auch meiner Doktrin, die Änderungen auf das wirklich Notwendige zu beschränken - wenn danach (im "flow of execution") noch weiterer AVM-Code ausgeführt wird, soll der - im Rahmen des Möglichen - auch nach dem Patchen unveränderte Bedingungen vorfinden.

Für mich stellt sich auch weniger die Frage, auf welchem Weg die Funktionen deaktiviert wurden, die auf einen system()-Call hinauslaufen könnten ... ich frage mich eher, warum AVM das überhaupt macht. Wenn es generell das "Auslassen" von Features ist (also schon zur Build-Time erfolgt), kann ich das nachvollziehen, weil es (ohne Mehraufwand) die Angriffsfläche verringert. Sollten das tatsächlich Sandbox-Techniken sein, mit denen AVM diese Funktionsaufrufe limitiert (zum Nachlesen für Interessenten z.B. hier: http://lua-users.org/wiki/SandBoxes), dann geht das nicht ohne ZUSÄTZLICHEN Aufwand und wofür sollte der gut sein?

Wann setzt man denn Sandboxing ein (zumindest in dieser Form, wo es nur um Einschränkungen bei den verfügbaren Funktionen geht)? Doch eigentlich nur dann, wenn man Lua-Code ausführen will, dessen Quelle man nicht 100% vertrauen kann - entweder weil es (lokaler) User-Code ist (z.B. in Form von Plugins) oder weil der aus einer Quelle "nachgeladen" wird, die man nicht selbst unter Kontrolle hat. Beides dürfte beim FRITZ!OS (zumindest bisher, vielleicht hat AVM ja noch andere Pläne in der Schublade) nicht der Fall sein - und auch wenn man Befürchtungen hegt, daß DATEN von der Benutzerseite (die man ja auch nicht selbst "kontrolliert", weshalb gründliche Validierung solcher Daten zu den Grundlagen ihrer Verarbeitung gehört) zur Ausführung nicht erwünschter Programme führen könnten, sollte man eher auf eine noch ausführlichere Prüfung der Daten setzen ... was aber immerhin eine zweite (oder auch weitere) "Verteidigungslinien" nicht ausschließt.

Nur gibt es eben noch viele andere "Scheunentore" (ich hatte oben ja nur ein paar "prominente" Beispiele aufgezeigt) und wenn man sich tatsächlich Sorgen um "code injection" machen sollte und vorbeugende Maßnahmen ergreifen will, dann wäre ein "Aufräumen" im Rechte-Konzept des FRITZ!OS (wo dann eben nicht mehr alles mit Root-Rechten arbeitet) genauso ein erster Schritt, wie das Verwenden von ACLs für den Aufruf von OS-Funktionen, wofür es auch bereit ausgereifte Techniken im Linux-Kernel gäbe (SELinux, AppArmor, etc.). Damit kann man einem Angreifer, dem tatsächlich das Ausführen eigenen Codes auf der Box gelingt, viel mehr Steine in den Weg legen, als mit einem (doch etwas primitiven) "sandboxing" direkt im Lua-Interpreter - erst recht dann, wenn es tatsächlich irgendwo noch "full-featured packages" geben sollte, die sich durch require oder dofile aktivieren ließen.

 

[PeterPawn]

Um hier auch noch ein (gedankliches) Schloß dran zu machen von meiner Seite ... die hier gewonnenen Erkenntnisse (danke für's Testen) sind in eine neue Version zum Testen eingeflossen;

[Info] - Boot-Manager - Umschalten zwischen den zwei Systemen in einer (passenden) FRITZ!Box

Könnte ebenfalls mit einer 7520 sowie (mal schauen wo die abgeblieben ist) einer 3272 und falls sich niemand anderes findet, falls erforderlich auf einer 7590 (wenn es die Zeit zulässt).

www.ip-phone-forum.de

[Info] - modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Fritzbox 7490 Fritz OS 7.29 Leider funktioniert das Modscript mod_show_vpn_on_overview unter 7.29 nicht. Es wird nichts eingefügt.

www.ip-phone-forum.de

Bis weitere Erkenntnisse vorliegen, ist die Sache damit für mich erst einmal erledigt.

Sollte es erforderlich sein, dazu weitere "Fehlerdiskussionen" zu führen, würde ich das auch lieber im oben verlinkten Thread zum Boot-Manager durchführen - schon weil das eine andere "Gliederungsebene" ist, die mit Freetz-NG nicht direkt zu tun hat.

Der Boot-Manager funktioniert ja auch ohne Freetz oder Freetz-NG (das sind m.W. die einzigen Lösungen als "Framework" für Änderungen, die zur Laufzeit eigene Oberflächen bereitstellen) - der Einbau kann über das Skript add_to_system_reboot.sh (Link) auch bei beliebigen anderen Optionen für das Anpassen der Firmware erfolgen (es sind ein paar Randbedingungen zu beachten, was den Aufruf des erwähnten Skripts anbelangt) - da bestehen keine weiteren Abhängigkeiten zu irgendwelchen anderen Dateien (u.a. deshalb ist das auch "größer" - für ein einzelnes Modell und eine einzelne FRITZ!OS-Version ginge das auch deutlich kompakter ... aber der Platzbedarf ist hier nicht das entscheidende Kriterium).