SIAB in AVM FW integrieren

[KingTutt]

Hallo,

ich habe mit fwmod_custom aus Freetz bis zur Firmware 113.06.83 immer ein Shell in a Box (SIAB) in die original AVM FW integriert. Die Binaries hatte ich mit freetz gebaut, statisch gelinkt und dann einfach (ohne das ganze Freetz) in die AVM FW gepackt:

• Firmware auspacken
• zusätzliche Dateien in die passenden Verzeichnisse kopiert (Binaries in /usr/bin und zusätzliche Libs in /lib )
  
• Firmware wieder gepackt und signiert (mit eigenem Schlüssel)
• Firmware auf die FritzBox gespielt -> fertig und läuft

Seit dem Wechsel der OpenSSL Version in freetz von 0.98 auf 1.0 habe ich nun das Problem, dass ich nicht zwei unterschiedliche Subversionen von OpenSSL 1.0 (die Version von AVM und die von Freetz) in das gleiche Verzeichnis (/lib) kopieren kann. Mein Versuch, ein anderes Verzeichnis zu nehmen (/usr/lib/custom) hat zwar in soweit funktioniert, dass die Dateien in dem Verzeichnis von fwmod mit in das FW Image gepackt werden, allerdings scheinen zusätzliche Verzeichnisse nicht mit auf der Box installiert zu werden. Was mache ich falsch bzw. wie kann ich einfach ein zusätzliches Verzeichnis mit 2-3 Bibliotheken mit in die FW packen, so dass sie beim installieren der FW auch auf der FritzBox landen?

Viele Grüße und Danke im voraus
KingTutt

 

[PeterPawn]

Wenn Du Shell-In-A-Box statisch gelinkt hast, brauchst Du doch die anderen OpenSSL-Bibliotheken (libssl/libcrypto) gar nicht mehr.

 

[koyaanisqatsi]

Moin

Und die dann doch relativ große statisch gelinkte SIAB Binary kann dann sogar (austauschbar) im externen Speicher rumliegen.
...nur das Startrskript müsste dementsprechend angepasst sein.

 

[PantaRhei]

Die Binaries hatte ich mit freetz gebaut, statisch gelinkt

Wie hast Du dies gemacht ?
Befehle, Config ?
nur mit diesen Inputs wird das für etwaige hilfswillige Leser nachvollziehbar;

 

[PeterPawn]

Wie hast Du dies gemacht ?

Es dürfte nicht so schwer sein, das nachzuvollziehen: https://github.com/Freetz/freetz/blob/master/make/shellinabox/Config.in#L37 ... und das Problem liegt ja auch nicht am Kopieren, so daß auch diese Kommandos (überwiegend) uninteressant sind.

Die Kernfrage ist es, warum @KingTutt hier überhaupt außer dem Binary "shellinaboxd" noch weitere Dateien kopiert bzw. kopieren will - für die Funktion des statisch gelinkten Programms sind die nicht erforderlich.

Aber selbst dann wäre es kein Problem, diese Bibliotheken in einem zusätzlichen Verzeichnis zu versammeln und dieses Verzeichnis in der Loader-Reihenfolge mit einem passenden Wert für "LD_LIBRARY_PATH" im Environment vor die Verzeichnisse im "rootfs" zu setzen bei der Suche nach passenden Bibliotheken. Da reicht es auch aus, wenn dieser LD_LIBRARY_PATH nur für den Start des betreffenden Daemons solchermaßen gesetzt ist und alle anderen Prozesse weiterhin die Standard-Reihenfolge (siehe uClibc-Quellen, dort kommt auch der Loader her) verwenden.

 

[er13]

Wie von Peter schon angemerkt - ein (komplett) statisch gelinktes Binary bedarf keiner (dynamischen) Libraries.

Bei einem (mit der Freetz-Toolchain) dynamisch gelinkten Binary gibt es folgende Wege den Loader dazu zu zwingen, die Libraries aus einem von /lib:/usr/lib abweichenden Verzeichnis zu laden:

1. per Setzen der Variable LD_LIBRARY_PATH (wurde von Peter ebenso bereits angesprochen).
2. per Ablegen der Library unter /usr/lib/freetz - das ist nämlich das erste Verzeichnis, in dem beim Laden eines mit der Freetz-Toolchain dynamisch gelinkten Binarys gesucht wird.
3. sollte einem der Pfad /usr/lib/freetz nicht gefallen, so kann dieser in der Freetz-menuconfig-Konfiguration unter "Toolchain options/FREETZ_RPATH" verstellt werden (ggf. muss die Experten-Ansicht davor aktiviert werden). Nach Anpassen des Pfades muss make erneut aufgerufen werden, dabei werden alle Target-Binaries/-Libraries erneut übersetzt. Man muss dann die erneut übersetzten Binaries/Libraries ins Image kopieren. Als Pfad wäre irgendein Pfad im schreibbaren Bereich der Box sinnvoll, hinter diesem könnte sich auch ein Symlink verstecken - der eigenen Fantasie sind da keine Grenzen gesetzt.

Bei 2 und 3 wird der sogenannte run-time search path (RPATH) in dem Binary hartkodiert, wodurch die Notwendigkeit des Setzens einer Variable entfällt (der hartkodierte Pfad kann immer noch per Setzen der Variable übersteuert werden, falls der Bedarf besteht).

 

[PeterPawn]

Nachtrag meinerseits noch ... bei der AVM-Version der uClibc ist der Support für RUNPATH wohl nicht aktiviert (jedenfalls nach der mitgelieferten Konfigurationsdatei):

$ grep LDSO uclibc.config.vr9
LDSO_LDD_SUPPORT=y
# LDSO_CACHE_SUPPORT is not set
LDSO_PRELOAD_ENV_SUPPORT=y
# LDSO_PRELOAD_FILE_SUPPORT is not set
# LDSO_STANDALONE_SUPPORT is not set
# LDSO_PRELINK_SUPPORT is not set
# LDSO_RUNPATH is not set
LDSO_SEARCH_INTERP_PATH=y
LDSO_LD_LIBRARY_PATH=y
# LDSO_NO_CLEANUP is not set
# LDSO_GNU_HASH_SUPPORT is not set

Wenn man also ein Programm mit passendem RPATH verwenden will (der wird ja in die Binärdatei geschrieben), dann muß man zwingend auch die Freetz-Version der C-Library (bzw. des Loaders) verwenden - da reicht dann der Austausch einzelner Binaries nicht mehr aus.

 

[KingTutt]

Hallo zusammen,

viele Dank für die diversen Hilfestellungen.

Wie hast Du dies gemacht ?
Befehle, Config ? nur mit diesen Inputs wird das für etwaige hilfswillige Leser nachvollziehbar;

Entweder man macht es per Hand wie PeterPawn geschrieben hat, oder man nutzt Freetz so wie ich. Dazu bietet sich die Option "build statically linked library" beim Paket shellinabox ja direkt an.

Die Kernfrage ist es, warum @KingTutt hier überhaupt außer dem Binary "shellinaboxd" noch weitere Dateien kopiert bzw. kopieren will - für die Funktion des statisch gelinkten Programms sind die nicht erforderlich.

Ich habe für für shellinaboxd zusätzlich die Option "build with support for FRITZ!OS certificate" angewählt, welche dann privatekeypasswd einbindet. Letzteres benötigt dann allerdings libprivatekeypasswd als shared lib (zumindest habe ich dafür keine static Option gesehen) und ich bin davon ausgegangen (vermutlich fälschlich), dass dann auch die OpenSSL-Bibliotheken (libssl/libcrypto) dazu noch einmal benötigt werden.

Aber selbst dann wäre es kein Problem, diese Bibliotheken in einem zusätzlichen Verzeichnis zu versammeln und dieses Verzeichnis in der Loader-Reihenfolge mit einem passenden Wert für "LD_LIBRARY_PATH" im Environment vor die Verzeichnisse im "rootfs" zu setzen bei der Suche nach passenden Bibliotheken. Da reicht es auch aus, wenn dieser LD_LIBRARY_PATH nur für den Start des betreffenden Daemons solchermaßen gesetzt ist und alle anderen Prozesse weiterhin die Standard-Reihenfolge (siehe uClibc-Quellen, dort kommt auch der Loader her) verwenden.

Genau das habe ich versucht umzusetzen und das hatte auch soweit immer funktioniert. SIAB habe ich aus /etc/init.d/E47-siab bei Systemstart gestartet und in dem shell script habe ich export LD_LIBRARY_PATH=/var/custom/lib;/lib gesetzt gehabt. Allerdings ist das Verzeichnis /var/custom/lib mit den Dateien nach der Installation auf der Fritz!Box nicht vorhanden gewesen.

Ich werde es jetzt noch einmal mit dem von @er13 vorgeschlagenen Pfad /usr/lib/freetz vesuchen und mich anschließend zurück melden.

Nachtrag:
Wenn ich zusätzliche Bibliotheken unter /usr/lib/freetz packe oder unter /lib/custom, dann scheint bei der Signierung der image-Datei nach dem Packen mit fwmod etwas schief zu laufen, denn ich bekomme beim Flashen die Meldung, dass es sich um keine von AVM freigegebene Firmware handelt.
Nutze ich das Verzeichnis /var/lib um zusätzliche Bibliotheken abzulegen, dann funktioniert das Flashen ohne Probleme (die eigene Signatur wird akzeptiert) allerdings werden die Dateien nicht mit installiert, d.h. das Verzeichnis /var/lib (sowie die Bibliotheken darin) gibt es hinterher auf der FritzBox nicht. Warum das so ist verstehe ich leider nicht. Irgendwie werden zusätzliche (Unter)Verzeichnisse nicht einfach mitangelegt, während zusätzliche Dateien in bestehenden Verzeichnissen keine Probleme bereiten.

 

[PeterPawn]

Auch "privatekeypassword" wird in eine statisch gelinkte "shellinaboxd"-Datei mit eingebunden ... das Paket bietet nur keine gesonderte "statisch"-Option. Trotzdem wird auch eine "libprivatekeypassword.a" erzeugt und die wird dann vom Linker für "shellinaboxd" herangezogen. Die erzeugte Datei funktioniert tatsächlich ohne jede weitere Abhängigkeit - außer halt vom FRITZ!Box-Zertifikat, wenn man sie mit den entsprechenden Optionen aufruft.

Ob eine Datei weitere Abhängigkeiten hat (und welche), kriegt man am besten mit einer Kombination auf dem "file"-Kommando (was einem erst einmal sagt, um was für eine Datei es sich handelt) und (bei dynamisch gelinkten Programmen) einem "ldd"-Aufruf für die betreffende Datei heraus. Wenn das "ldd"-Kommando (für die richtige Plattform allerdings, das müßte man sich bei Freetz also aus der Toolchain heraussuchen) etwas von "not a dynamic executable" ausgibt, dann ist das in aller Regel (wenn es ein ELF-Binary ist, was einem "file" davor gezeigt hat) ein rein statisch gelinktes Programm, was vielleicht noch einige Konfigurationsdateien braucht, aber keine weiteren DSOs (zumindest nicht zum Starten, ob auch ein "dlopen" mit einer statisch gelinkten "libdl" geht, weiß ich gerade gar nicht).

Das Verzeichnis "/var/custom/lib" kann auf einer "normalen" Installation gar nicht vorhanden sein ... selbst wenn es im SquashFS-Image gefüllt sein sollte, mountet der Startcode des Systems dort unter "/var" ein "tmpfs" und entpackt den Inhalt von "var.tar" dorthin.

Das mit dem "/var/custom/lib" ist eigentlich dafür gedacht, daß da ein Image mit solchen Erweiterungen (und seinem eigenen internen "/lib"-Verzeichnis) unter "/var/custom" zur Laufzeit gemountet wird ... ein solches Image erzeugt aber Freetz nicht von selbst. Da wäre dann noch einiges an Handarbeit angesagt - wobei ich ohnehin nicht verstehe, wieso Du das Kopieren derartiger Dateien durch die Freetz-Toolchain erwartest, wenn Du doch nach eigener Aussage mit "fwmod -u" und "fwmod -p" arbeitest. Oder habe ich #1 da so falsch verstanden? Ansonsten mußt Du halt die notwendigen Kopieraktionen in eine "fwmod_custom" packen ... aber auch da mußt Du Dir schon die notwendigen Dateien (und damit die Befehle fürs Kopieren) selbst heraussuchen aus den Staging-Verzeichnissen der Toolchain.

 

[KingTutt]

Danke @PeterPawn für die zusätzlichen Erläuterungen. Wenn "privatekeypassword" auch schon in eine statisch gelinkte "shellinaboxd"-Datei mit eingebunden ist, brauche ich in der Tat nur die erzeugte Datei "shellinaboxd" in die Firmware integrieren und nicht mal "privatekeypassword" selbst.

 

[KingTutt]

Ich hätte nochmals eine Frage hinsichtlich shellinaboxd und der Option "use of existing box certificate and key". Ich habe festgestellt, dass auf einer meiner drei administrierten 7490 nach jedem Neustart ein neues Zertifikat generiert wird. Das hat zur Folge, dass man jedes Mal im Browser wieder eine neue Ausnahme hinzufügen muss.
Bei der ersten 7490 mit original AVM FW kann ich da Problem nicht beobachten. Bei der zweiten, wo ich in die originale AVM FW mittels freetz lediglich ein OpenVPN integriert habe, tritt die Problematik auch nicht auf. Lediglich auf der dritten 7490, wo ich mittels Freetz fw-custom ein statisch gelinktes shellinaboxd integriert habe tritt dieses Problem auf. Nun mutmaße ich, ob dieses statisch gelinkte shellinaboxd mit der o.g. Option die Ursache sein könnte. Leider weiß ich nicht, wann normaler Weise ein neues Zertifikat erstellt wird (ich vermute kurz vor Ablauf des bisherigen) und ob es da überhaupt einen Zusammenhang geben kann.
@PeterPawn: Da IMHO die Option in Freetz ausgehend von Deiner ersten Version in modfs erfolgt ist, könntest Du mir eine Einschätzung geben?

 

[PeterPawn]

Solange niemand in die Dateien "/var/flash/websrv_ssl_{key,cert}.pem" schreibt (ich wüßte nicht, warum das Shell-In-A-Box machen sollte, weder mit noch ohne Patch) und dabei ein vorhandenes, gültiges Zertifikat (und natürlich den Key) überschreibt, wird das Zertifikat von der FRITZ!Box gar nicht erneuert.

Es wäre also zu klären, wer da warum in diese Dateien schreibt bzw. warum die AVM-Komponenten die Datei nicht lesen können - dann generieren sie nämlich auch ein neues Zertifikat, praktisch bei jedem Start des "ctlmgr" (man muß nicht die gesamte Box neu starten für einen Test).

Der private Schlüssel ist eben noch einmal zusätzlich verschlüsselt (wie genau, steht irgendwo beim Thema "privatekeypassword" oder in der generellen Beschreibung der AVM-Verschlüsselung - am Ende ist das nur der MD5-Hash der "maca", iirc) - das Zertifikat ist "frei lesbar".

Also am besten mal beides aus der Box herauskopieren (oder ein "openssl" hinein) und von Hand prüfen, was da enthalten ist - und zwar in regelmäßigen Abständen, falls es doch immer wieder überschrieben werden sollte.

Bei mir funktioniert jedenfalls das Shell-In-A-Box genauso mit dem Box-Zertifikat, wie es ein "dropbear" auch tut oder auch ein "sshd" aus dem OpenSSH-Paket bzw. "stunnel" - die dabei verwendeten Binaries gibt es im "binaries"-Branch des GitHub-Repositories und man könnte damit zumindest mal einen "Quervergleich" ausführen, wenn Du eigene Binaries verwenden solltest.

Es braucht vielleicht auch mal den (EDIT: gemeinsamen) Blick in Deine eigenen Skript-Dateien ... denn irgendwie mußt Du das ja selbst einbinden und starten, wenn Du kein Freetz-Image verwendest (was absolut keine "Pflicht" ist, ich tue es auch nicht und lasse das bei mir über E99-custom aus einem eigenen Image starten).

 

[KingTutt]

@PeterPawn danke für die Ratschläge.

Es wäre also zu klären, wer da warum in diese Dateien schreibt bzw. warum die AVM-Komponenten die Datei nicht lesen können - dann generieren sie nämlich auch ein neues Zertifikat, praktisch bei jedem Start des "ctlmgr" (man muß nicht die gesamte Box neu starten für einen Test).

Mit dem "ctlmgr" kenne ich mich leider noch nicht aus. Muss der selbst neu gestartet werden, oder benutzt man den um services neu zu starten, b.Z. den Webserver?

Ich habe mir die Datei "/var/flash/websrv_ssl_cert.pem" mal angesehen und sie mit dem Zertifikat verglichen, welches im Browser angezeigt wird. Dabei habe ich festgestellt, dass das Zertifikat nicht benutzt wird, sondern das, was unter /var/tmp gespeichert ist.

Es braucht vielleicht auch mal den (EDIT: gemeinsamen) Blick in Deine eigenen Skript-Dateien ... denn irgendwie mußt Du das ja selbst einbinden und starten, wenn Du kein Freetz-Image verwendest (was absolut keine "Pflicht" ist, ich tue es auch nicht und lasse das bei mir über E99-custom aus einem eigenen Image starten).

Eingebunden ist shellinaboxd (hoffentlich) genauso wie bei Dir. Unter "/etc/init.d" habe ich eine Datei "E47-siab" in der wie hier beschrieben ein
"/var/custom/usr/bin/shellinaboxd --port=8010 --user=0 --group=0 --cert-from-box --background --pidfile=/var/run/shellinaboxd.pid --no-sni --disable-ssl-menu --service=/:0:0:/var/media/ftp:/sbin/ar7login"
steht.

Nach Deinen Ausführungen nach müsste ich also irgendwie mal rausbekommen, warum nicht das Zertifikat unter /var/flash nicht benutzt wird, bzw. warum die beiden nicht identisch sind. Vorschläge?

 

[PeterPawn]

Ich habe das gerade mal bei einer 7580 mit 06.92 angesehen, die auch kein von mir hochgeladenes Zertifikat hat ... da steht in dem Zertifikat im TFFS (also unter "/var/flash/websrv_ssl_cert.pem") die normale Liste von Domain-Namen (fritz.box, myfritz.box, usw.) und in dem unter "/var/tmp/websrv_ssl_cert.pem" steht zusätzlich noch die externe IP-Adresse der Box in den X509v3-Extension und der CN lautet auch auf die externe IP-Adresse und nicht auf "fritz.box".

Das ist ziemlicher Bockmist, falls AVM das absichtlich macht (und gilt offenbar nur dann, wenn man kein eigenes Zertifikat hochgeladen hat, in so einem Fall traut man sich das hoffentlich auch künftig nicht) - am Ende verlassen sie sich offenbar darauf, daß die AVM-eigenen Apps den Public-Key direkt pinnen und nicht das Zertifikat, mit dem er beglaubigt wird.

Aber jeder lokale Browser (und auch jeder externe Zugriff) springt dann natürlich im Dreieck, wenn sich ggf. mitten in einer Verbindung das Zertifikat der Gegenstelle ändert (falls das auch beim Wechsel der externen Adresse geschieht - wenn die schon mal mit im Zertifikat steht) - das erweckt ja fast den Anschein, als wolle AVM mit Macht die lokale Verwendung von TLS verhindern, solange der Benutzer nicht sein eigenes Zertifikat hinterlegt hat.

Mir ist das bisher wohl nicht aufgefallen, weil ich auf den Produktiv-Boxen halt Zertifikate meiner eigenen, privaten CA verwende und in den in Frage kommenden Browsern dann diese CA als "trusted" hinterlegt ist.

Es kann also tatsächlich sein, daß AVM inzwischen (seit wann weiß ich dann gar nicht, aber bei der 06.8x war es m.E. noch nicht der Fall - auch das Verhalten meiner 6490 mit 06.83 (und automatischem Zertifikat) würde dafür sprechen, denn da passiert das eben nicht) tatsächlich für den eigenen Webserver (der "ctlmgr" ist praktisch alles in einem, von der zentralen Verwaltung von Einstellungen bis hin zum Webserver, wird mit "ctlmgr -s" gestoppt und im einfachsten Falle mit "ctlmgr" wieder gestartet, Beispiel im "tvi"-Skript in "tffs" - aus dem Kopf, nicht zu wörtlich lesen) bei jedem neuen Start oder sogar bei jeder Änderung der externen IP-Adresse auch ein neues Zertifikat generiert.

Das sollte aber nicht dazu führen, daß auch Shell-In-A-Box mit diesem "wechselnden" Zertifikat arbeitet, denn dort wird eigentlich die Version aus dem TFFS und nicht aus dem "tmpfs" verwendet:

https://github.com/PeterPawn/freetz...atches/boxcert/900-box_certificate.patch#L122

Gleiches sollte für alle anderen Patches von mir gelten, welche die Verwendung des Box-Zertifikats für irgendeinen zusätzlichen Service nachrüsten.

 

[KingTutt]

Ich habe das gerade mal bei einer 7580 mit 06.92 angesehen, die auch kein von mir hochgeladenes Zertifikat hat ... da steht in dem Zertifikat im TFFS (also unter "/var/flash/websrv_ssl_cert.pem") die normale Liste von Domain-Namen (fritz.box, myfritz.box, usw.) und in dem unter "/var/tmp/websrv_ssl_cert.pem" steht zusätzlich noch die externe IP-Adresse der Box in den X509v3-Extension und der CN lautet auch auf die externe IP-Adresse und nicht auf "fritz.box".

Kann ich für meine 7490 mit FW 06.93 bestätigen. Und in der Tat, wenn ich "ctlmgr" einmal mit "ctlmgr -s" stoppe und danach mit "ctlmgr" wieder starte, ist das Zertifikat unter "/var/tmp/websrv_ssl_cert.pem" ein neues, obwohl sich die externe IP-Adresse nicht geändert hat. Die 7490 hängt nämlich über LAN1 an einer FB 6430 und bekommt immer die gleiche IP zugewiesen.

Ich werde mir das bei Gelegenheit mal auf meiner anderen 7490 mit freetz drauf anschauen, allerdings habe ich auch da ein eigenes Zertifikat (Lets Encrypt sei Dank) hinterlegt. Bei der dritten 7490 mit originaler AVM FW ist allerdings keine eigenes Zertifikat hinterlegt und dort überlebt das vorhandene sogar ein Firmwareupdate...

 

[PeterPawn]

dort überlebt das vorhandene sogar ein Firmwareupdate...

Was verstehst Du denn unter "überlebt"? Das Zertifikat in "/var/flash/websrv_ssl_cert.pem" bleibt bei mir auch mit neuerer Firmware ab 06.9x unangetastet - auch über ein Firmware-Update hinweg. Es gibt zwar einige Situationen, wo das FRITZ!OS auch ein neues "permanentes" Zertifikat generiert, aber das geschieht bei mir definitiv nicht bei jedem Neustart und das regelmäßige Verändern des Zertifikats in "/var/tmp/websrv_ssl_cert.pem" ist definitiv von Shell-In-A-Box komplett unabhängig, das habe ich auch auf Boxen, wo gar kein SIAB vorhanden, geschweige denn aktiv ist.

Das Zertifikat in Flash hat auch ein Ausstelldatum vom 01.01.1970, weil es praktisch immer zu einem Zeitpunkt generiert wird, wo die Box noch keine Zeit hat (und auch keinen Internet-Zugang zu einem NTP-Server), während das andere i.d.R. ein Datum aus diesem Jahr hat, wenn die Box wenigstens einmal gestartet wurde.

Selbst wenn sich das Zertifikat im Flash wirklich auch ändern würde (der private Schlüssel bleibt m.W. aber auch dann gleich, wenn die Box sich selbst ein neues Zertifikat ausstellt), kann man das kaum nachvollziehen ... solange das (wenn die Konfiguration erst mal eingestellt ist) immer zur selben Sekunde nach dem Laden des Systems geschieht (bei meiner 7580 ist es Sekunde 39), ändert sich am Zertifikat praktisch gar nichts, selbst wenn man diesen Vorgang beliebig oft wiederholt.

Wie gesagt ... alle meine Patches benutzen das Zertifikat nur (lesend), keiner ändert auch nur ein Byte am Inhalt des Keys oder des Zertifikats und auch nicht an den "Meta-Daten" - außer ggf. "atime", wobei die bei TFFS-Nodes auch keinen echten Sinn ergibt.