[Frage] Frage zum Thema : Signieren von Firmware

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
525
Punkte für Reaktionen
128
Punkte
43
Hallo Fachwelt,

ich versuche gerade folgenden Beitrag zu verstehen ( http://freetz.org/wiki/help/howtos/development/sign_image ) um diesen ggf. ins Newbie-Wiki zu implementieren.

Meine Frage :
Wo liegt der Vorteil wenn ich ein solches "signiertes" Image baue ?

Wenn ich den Artikel richtig verstehe, dann habe ich die Möglichkeit ein solches von mir gebautes Image im Anschluß wie früher über das AVM-WebIF als FW-Update in die Box laden zu können wenn ich vorher ein schon ein mit meinem Schlüssel signiertes Image auf der Box habe. So weit so gut, aber warum soll sich nun ein User die Arbeit machen sein Image zu Signieren wenn er doch 1.) eh ein Image mit Freetz auf der Box hat und er 2.) das neue (unsignierte) Image über die Freetz-Update-Funktion zur Box flaschen könnte ?

Bitte jetzt keinen Schitstorm starten. Es ist nur eine Frage da ich und ggf. auch andere User z.Z. noch keinen Vorteil im signieren der Freetz-Image sehe oder ich habe ja ggf. auch nur etwas noch nicht verstanden oder sehe gerade wieder einmal den Baum vor lauter Bäumen nicht.
 
Wenn man schon Freetz auf der Box hat bzw. es einmal drauf gebracht hat, ist es in der Tat weniger interessant. Wenn Freetz drauf ist, ist es eher als eine Alternative bzw. als eine Art Backup-Methode zu betrachten.

Interessant wird es aber, wenn man fwmod in dem no freetz-Modus verwendet. Ab dem Zeitpunkt, wo sich der eigene (Public-)Key auf der Box befindet, wird das Flashen jedes weiteren (modifizierten) Images bequemer. Bequemer in dem Sinne, dass es übers AVM-Web-If geht und man sich nicht mit dem Raussuchen/Verstehen der richtigen (der zu der Box passenden) EVA-Flash-Methode (Stichworte NOR-Boxen vs. NAND-Boxen bzw. push_firmware vs. eva2memory) beschäftigen muss. Man muss lediglich sicher stellen, dass jedes weitere Image, welches man flashen möchte, mit demselben Schlüssel signiert ist und der Public-Teil in dem neuen Image weiterhin enthalten ist.

Es sei angemerkt, dass es sich bei Freetz lediglich um die Intergration der von YourFritz zur Verfügung gestellten Funktionalität handelt. Man kann auch direkt YourFritz verwenden.
 
Danke für dein Feedback.

Also sehe ich das im Moment richtig, das es für Newbies aktuell noch keinen "einfacheren" Weg gibt eine Box ab der Fw 6.5x mit ein Freetz-Image zu flaschen als einen Downgrade auf eine Fw < 6.5x zu machen ?
 
Zuletzt bearbeitet:
Na ja, "einfach" ist subjektiv und durch eine gute Anleitung kann die Wahrnehmung, was nun "einfacher" ist, "kippen". Die Stichworte push_firmware und eva_to_memory habe ich schon genannt.
 
Ich versuche mich mal an dem Weg. Vielleicht schaffe ich es ja so meine 7560 mit Freetz zu modifizieren.

Vielleicht finde ich ja so einen Weg das alte Newbie-Trunk-HowTo auf einen aktuellen Stand zu bringen.
 
Sofern ich es richtig verstanden habe, gibt es zwischen dem Flashen eines signierten Images über das AVM Webinterface und dem Flashen eines unsignierten Images mit der Freetz eigenen Funktion einen wesentlichen Unterschied:

Wenn ich per AVM Webinterface update, dann landet das neue Image bei den neueren Boxmodellen in den "inaktiven" Partitionen, und nach dem Flash wird die Bootloader Variable linux_fs_start geändert, so daß dann das neue System gestartet wird.

Im Gegensatz kann ich mit der in Freetz enthaltenen Funktion zwar auch unsignierte Images flashen, diese landen dann aber in den "aktiven" Partitionen und linux_fs_start wird nicht geändert.

Daraus ergibt sich beim Flash über die AVM Funktion ein aus meiner Sicht wesentlicher Vorteil: Ist das neu geflashte Image aus irgendeinem Grunde nicht startfähig oder arbeitet anderweitig nicht korrekt, so brauche ich lediglich per FTP die Variable linux_fs_start wieder umschalten und lande auf meinem vorherigem und hoffentlich fehlerfreien Image. Und gerade bei den neueren Firmware-Versionen, welche beim freetzen noch als "Under Development" bzw. "highly experimental" eingestuft sind, sehe ich dies als deutlichen Vorteil.

C.U. NanoBot
 
@NanoBot: wer hat Dir denn des erzählt? Freetz-Update-Methode weicht zwar von der AVM's Methode ab, aber am Ende wird letzten Endes genauso /var/install aufgerufen und das Umschalten findet dort statt.

Das, was Du sagst, trifft auf die von Freetz erstellten in-memory-Images zu. Diese werden Stand jetzt (wenn man keine Vorkehrungen trifft) in der Tat in die aktive Partition geschrieben.
 
sry wenn OT aber @er13

wie genau ist der Ablauf der eva_to_memory ?

habe da ja einen Fall - zwar 6490 die "gebrickt" ist - aber nachdem ich daran eh nichts mehr kaputt machen kann - habe ich mich schon mal mit dem eva_to_memory (um in die Aktive partiton schreiben zu können) auseinander gesetzt, allerdings konnte ich keinen "Erfolg" verbuchen.

Wie genau lautet der Aufruf der eva_to_memory ?

Folgt danach noch ein "command" oder wie oder was ? (sry wenn ich jetzt so dumm frage, bzw ich auf dem Schlauch stehe)
 
Die Abläufe beim "eva_to_memory" habe ich mal im Thread zum "modfs-Starter" beschrieben, zusammen mit einer Erklärung, wie man ein solches Image "von Hand" erstellen könnte.

Ansonsten erwartet "eva_to_memory" halt eine FRITZ!Box, die auf eine FTP-Verbindung zum Bootloader reagiert - wie die dahin kommt, interessiert das Skript nicht wirklich.

Aufgerufen wird es mit einem oder zwei Parametern, der erste ist der Dateiname eines passenden Images (welche Voraussetzungen das erfüllen muß, ist auch irgendwo mehrfach beschrieben und diskutiert) - image2ram würde aus einem "normalen" Image (egal ob "Freetz" oder "AVM original") eine passende Datei erstellen. Der zweite Parameter kann die IP-Adresse der FRITZ!Box sein - fehlt sie, wird 192.168.178.1 verwendet.

Das Skript ermittelt dann die Größe des Images und errechnet aus der Größe des Hauptspeichers und des Images einen neuen (temporären) Wert für "memsize" und eine Ladeadresse für das Image im RAM der Box. Dann werden diese errechneten Werte in der Box gesetzt (inkl. "kernel_args_tmp" mit der korrekten Beschreibung des RAM-Images) und im letzten Schritt wird dann die Image-Datei zur Box übertragen. Tritt dabei kein Fehler auf, startet die Box dieses Image nach der Übertragung ... das heißt dann, der Rest der FTP-Session "fällt aus" und die Box beendet ihrerseits einfach die Verbindung.

Das funktioniert aber nur für Boxen, die zur Beschreibung des Images im RAM auf den Parameter "mtdram1" setzen (findet man in den Kernel-Quellen für das jeweilige Modell) ... die 6490 gehört da (so wie es "eva_to_memory" im Moment macht) aber ohnehin nicht dazu, dort ist das Skript also auch nicht wirklich "zielführend". Die 6490 verwendet ja auch keine (Init-)Skripte, mit denen ein ins RAM geladenes System sich selbst in die korrekten Partitionen schreibt - das machen m.W. die Versionen mit einem "Wrapper"-Filesystem (über die /etc/inittab im Wrapper und einen dort enthaltenen Aufruf von "/sbin/flash_update" im Wrapper-FS) und die GRX500-Modelle (7560/7580), wobei bei letzteren das über das "normale" Filesystem und die dort liegende "/etc/init.d/E03-flash_update" (aus dem Kopf, ohne Gewähr) erfolgt.

Für die 6490 bringt "eva_to_memory" also gar nichts und für die (erste) Installation eines Freetz-Images reicht (sofern die Box im richtigen "Modus" ist), einfach ein "eva_to_memory <image_file>". Wer das neue System in die inaktive Partition schreiben lassen will, kann einfach vorher noch die Variable "linux_fs_start" auf den alternativen Wert setzen ... dann schreibt sich auch ein nicht weiter modifiziertes System ("wenn man keine Vorkehrungen trifft") in die richtige (sprich, die zuvor inaktive) Partition.


-Auch wenn das Signieren (bzw. der wichtigere Einbau eines eigenen öffentlichen Schlüssels) auf den ersten Blick bei einem Freetz-Image keinen unmittelbaren Vorteil versprechen mag, so gibt es noch einen weiteren Aspekt, den ich zumindest mal erwähnen möchte (habe ich im "modfs"-Thread letztens bereits einmal getan).

Der "autorun"-Mechanismus von Freetz ist ja ein etwas zweischneidiges Schwert ... wenn der aktiviert ist, kann jeder mit einem physikalischen Zugang zur Box einfach einen USB-Stick mit einem eigenen "autorun.sh"-Skript anstecken (so ist jedenfalls mein Wissensstand, den ich gerne korrigieren lasse, wenn ich etwas übersehen habe) und damit problemlos die komplette Box übernehmen - inkl. Einrichtung zusätzlicher Konten oder Zurücksetzen des Admin-Kennworts oder oder oder ... die Box ist praktisch schutzlos. Das wird zwar m.W. auch "angesagt" bei der Aktivierung oder es steht irgendwo im Wiki, aber es gäbe auch eine wesentlich bessere - oder zumindest sicherere - Lösung.

Setzt man an dieser Stelle nämlich ein (selbst-signiertes) Image für diesen "autorun"-Mechanismus ein, braucht es nur einen einzigen Aufruf einer AVM-Komponente (tr069fwupdate), um die in so einem Image enthaltene Datei "./var/install" nach automatischer Signaturprüfung durch die AVM-Firmware zu starten und dabei kann so ein Image auch noch (fast) beliebige weitere Dateien enthalten (wenn man ein paar wenige Fallstricke beachtet).

Damit hat man dann wieder ein "autorun", was eben keine riesige Sicherheitslücke in das System reißt ... ähnliches könnte man sich auch für die Dateien beim "Externalisieren" überlegen, denn auch das reißt - sofern irgendein "Nicht-Admin" (Schreib-)Zugriff auf den Ort der Speicherung dieser Daten haben sollte (im schlechtesten Fall reicht dafür eine "directory traversal"-Lücke in einer zusätzlichen (Server-)Software, die man in sein Freetz-Image installieren läßt) - eine gewaltige Lücke in das FRITZ!OS.

So, wie "normale" Linux-Distributionen die Integrität ihrer Pakete und Repositories über PGP-Signaturen absichern, so könnte man den AVM-Mechanismus auch selbst (und auch generell für Freetz) "zweckentfremden". Das hat den Vorteil, daß alles dafür Notwendige bereits im FRITZ!OS von AVM enthalten ist (und ohnehin bei den meisten Benutzern drinbleiben muß, sonst gehen auch keine DECT-Update usw.) und man nicht erst mühsam (und platzfressend) eine andere Signaturlösung installieren muß.

- - - Aktualisiert - - -

BTW ... ich weiß ja nicht, wieviele Leute dieses "autorun" dann auch benutzen, aber bei der aktuellen Firmware (die ohne entsprechende Patches USB-Volumes immer mit "noexec" mountet) dürfte das ohnehin nicht funktionieren, so wie es derzeit in der "libmodmount.sh" steht.

EDIT: Es kann natürlich auch sein, daß Freetz da die "udev-mount-sd" auch bei neuerer Firmware soweit "entkernt", daß deises "noexec" von AVM gar nicht zum Zuge kommt. Dann sollte man das vermutlich nachziehen und nur auf ausdrücklichen Wunsch des Benutzers weglassen - gelingt es einem Angreifer, den Suchpfad auf ein solches USB-Volume zu erweitern und dort ein Kommando zu hinterlegen, was bei AVM (oder auch in Freetz, allerdings weiß ich nicht, ob es so etwas dort gibt) ohne (absoluten) Pfad aufgerufen wird, dann würde eine solche Datei auch von einem USB-Volume geladen und ausgeführt - genau dagegen hilft ja die "noexec"-Option beim Mounten.

Je nach installierter Software sollte man sich sogar überlegen, ob man nicht zusätzliche Optionen (z.B. "nodev") auch noch hinzufügen möchte. Richtet jemand dort (also auf einem USB-Volume mit einem geeigneten Dateisystem) ein "device file" für eine TFFS-Partition ein und gibt es eine (Server-)Software auf der Box, die dort (aus so einer Datei) lesen könnte (bei AVM fehlt diese bzw. es wird korrekt "abgelehnt" bei den NAS-Funktionen) und derselbe Angreifer kann diese Software irgendwie ansprechen/benutzen, dann ist im Handumdrehen der komplette TFFS-Inhalt aus der Box extrahiert und bei Schreibzugriff sogar wieder ein modifizierter Inhalt (ggf. inkl. neuer Freetz-Settings samt Admin-Passwort oder -Konto) auf der Box installiert.
 
Zuletzt bearbeitet:
Die Abläufe beim "eva_to_memory" habe ich mal im Thread zum "modfs-Starter" beschrieben, zusammen mit einer Erklärung, wie man ein solches Image "von Hand" erstellen könnte.

Ansonsten erwartet "eva_to_memory" halt eine FRITZ!Box, die auf eine FTP-Verbindung zum Bootloader reagiert - wie die dahin kommt, interessiert das Skript nicht wirklich.

Aufgerufen wird es mit einem oder zwei Parametern, der erste ist der Dateiname eines passenden Images (welche Voraussetzungen das erfüllen muß, ist auch irgendwo mehrfach beschrieben und diskutiert) - image2ram würde aus einem "normalen" Image (egal ob "Freetz" oder "AVM original") eine passende Datei erstellen. Der zweite Parameter kann die IP-Adresse der FRITZ!Box sein - fehlt sie, wird 192.168.178.1 verwendet.

Das Skript ermittelt dann die Größe des Images und errechnet aus der Größe des Hauptspeichers und des Images einen neuen (temporären) Wert für "memsize" und eine Ladeadresse für das Image im RAM der Box. Dann werden diese errechneten Werte in der Box gesetzt (inkl. "kernel_args_tmp" mit der korrekten Beschreibung des RAM-Images) und im letzten Schritt wird dann die Image-Datei zur Box übertragen. Tritt dabei kein Fehler auf, startet die Box dieses Image nach der Übertragung ... das heißt dann, der Rest der FTP-Session "fällt aus" und die Box beendet ihrerseits einfach die Verbindung.

Das funktioniert aber nur für Boxen, die zur Beschreibung des Images im RAM auf den Parameter "mtdram1" setzen (findet man in den Kernel-Quellen für das jeweilige Modell) ... die 6490 gehört da (so wie es "eva_to_memory" im Moment macht) aber ohnehin nicht dazu, dort ist das Skript also auch nicht wirklich "zielführend". Die 6490 verwendet ja auch keine (Init-)Skripte, mit denen ein ins RAM geladenes System sich selbst in die korrekten Partitionen schreibt - das machen m.W. die Versionen mit einem "Wrapper"-Filesystem (über die /etc/inittab im Wrapper und einen dort enthaltenen Aufruf von "/sbin/flash_update" im Wrapper-FS) und die GRX500-Modelle (7560/7580), wobei bei letzteren das über das "normale" Filesystem und die dort liegende "/etc/init.d/E03-flash_update" (aus dem Kopf, ohne Gewähr) erfolgt.

Für die 6490 bringt "eva_to_memory" also gar nichts und für die (erste) Installation eines Freetz-Images reicht (sofern die Box im richtigen "Modus" ist), einfach ein "eva_to_memory <image_file>". Wer das neue System in die inaktive Partition schreiben lassen will, kann einfach vorher noch die Variable "linux_fs_start" auf den alternativen Wert setzen ... dann schreibt sich auch ein nicht weiter modifiziertes System ("wenn man keine Vorkehrungen trifft") in die richtige (sprich, die zuvor inaktive) Partition.


Danke für die Erläuterunng auch wenn Du diese schon mehrmals getippt hast/haben solltest.

Ich bin hänge mit der 6490 leider immer noch am selben Punkt und komme alleine nicht weiter - und bislang blieben die Antworten auf meinen letzten Post bezüglich dieser Box siehe http://www.ip-phone-forum.de/showthread.php?t=287470&p=2214507&viewfull=1#post2214507 leider aus - wurde auch nicht in einen extra Thread verschoben (sollte ich vll doch mal einen Admin/Mod anschreiben, damit es verschoben wird??) da das schreiben in die aktive Partition mit einem 501 beendet wird, hoffte ich, auf diesem Wege in die aktive Partition zu schreiben, aber wenn dem so ist, kanns nicht klappen - allerdings schien das script mit der 6490 kein wirkliches Problem gehabt zu haben

Code:
[COLOR="#FF0000"]eva_to_memory.log[/COLOR]
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2567 0x0 0x36409
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
RETR env
150 Opening BINARY data connection
226 Transfer complete
SETENV memsize 0x0dded800
200 SETENV command successful
SETENV kernel_args_tmp mtdram1=0x8dded800,0x90000000
200 SETENV command successful
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,54,69)
STOR 0x8dded800 0x90000000
150 Opening BINARY data connection
226 Transfer complete
 
@stoney0815 - OT und nur ausnahmsweise, weiter nur im anderen Thread:
Das Problem besteht halt darin, daß das Image ja nicht nur in den Speicher geschrieben werden sollte, sondern der Bootloader es anschließend auch noch "starten" muß.

Das geht bei der 6490 schon damit los, daß auf diesem Weg eben nur ein "System" gestartet würde und das zweite (wir erinnern uns, daß so eine 6490 einen ARM- und einen ATOM-Prozessor verwendet) gar nicht berücksichtigt wird. Das klappt mit einem AVM-Kernel schon mal definitiv nicht (zumindest nicht auf diesem Weg), denn der wartet früher oder später darauf, daß er sich mit dem anderen System synchronisieren kann (man braucht nur mal einen Blick in die "dmesg"-Ausgabe einer funktionierenden 6490 zu werfen) und das entfällt schon mal, wenn das andere System gar nicht läuft.

Ansonsten ist Dir sicherlich auch selbst aufgefallen, daß man in Deinen mitgeschnittenen Daten nicht einen einzigen "echten" FTP-Dialog sehen kann ... das einzige, was da passiert, sind wiederholte SYN-Versuche, die auch klappen und wenn der Server sich dann mit "220" identifiziert hat, wird die Verbindung wieder geschlossen. Das war's dann auch schon und aus der Beschreibung des Aufbaus beim Mitschnitt werde ich ebenfalls nicht schlau. Wenn da wegen irgendeines PA in einer anderen FRITZ!Box Pakete "unterschlagen" werden bei einem Mitschnitt (ACKs für "unseen packets" sind ein starker Hinweis darauf), dann kann man damit halt nichts anfangen. Dann nimmt man einen (semi-professionellen) Switch mit der Möglichkeit, den Traffic eines Ports auf einen anderen zu spiegeln und schneidet dort den Traffic mit oder man baut einen Monitor in die Ethernet-Verbindung ein (das kann auch ein Linux-Router sein).

Trotzdem kann ich immer noch nicht nachvollziehen, wieso (und wie) Du auf die Idee kommst, da eine Partition "in kleinen Happen" beschreiben zu wollen - wenn ich etwas davon geschrieben habe, daß Du das so konservativ wie möglich "einstellen" sollst, dann ging es immer darum, die echten - bei der FRITZ!Box ankommenden(!) - Daten irgendwie zu sehen (und das finde ich in keiner der beiden eth-Dateien aus Deinem ZIP-File).

Soweit ich die zwischenzeitlichen Tests verstanden habe, lassen sich ja auch alle Partitionen (inkl. derer für Dateisystem und Kernel) erfolgreich beschreiben, solange die Daten nur "kurz genug" sind. Das verstärkt natürlich den Verdacht noch mehr, daß es irgendwie an der TCP-Flußsteuerung liegen muß, wenn die Box beim Schreiben einer Partition (und ich glaube nicht, daß alle anderen Stellen im eMMC schadhaft sind) ihrerseits die Verbindung kappt, nachdem eine gewisse Datenmenge übertragen wurde.

Ob die nun immer genauso groß ist oder nicht (es also am Löschen/Buffern des (eMMC-)Flashs oder an einem "buffer full" für den FTP-Empfang generell liegen könnte), sollte ja genau der Mitschnitt als Ergebnis zeigen - davon ist halt nichts zu finden, weil gar keine Datenübertragung protokolliert wurde (jedenfalls sehe ich da keine).

Was sollte ich also antworten? Abgesehen davon ist das tatsächlich mehr ein Thema für den anderen Thread ... also Fortsetzungen ohnehin dort - auch wenn ich im Moment nicht wüßte, was ich schreiben soll. Du mußt irgendwie dafür sorgen, daß man mal einen Mitschnitt des bei der FRITZ!Box eingehenden(!) Verkehrs sehen kann und das auch noch für die fehlschlagenden Versuche, einen längeren Inhalt dort zu speichern. Das Ziel ist zunächst mal die Feststellung, ob die FRITZ!Box immer nach einer - mehr oder weniger festen - Datenmenge die Verbindung kappt. Dafür sollen an der FRITZ!Box nur "normgerechte" Pakete eingehen - also weder "jumbo frames" noch irgendwelches "offload processing", was die früheren Mitschnitte "unleserlich" machte, verwendet werden.

Der TCP-Stack im Bootloader dürfte eher rudimentär ausfallen und damit sollte man den eben nicht mit irgendwelchen Überraschungen konfrontieren.
 
@NanoBot: wer hat Dir denn des erzählt? Freetz-Update-Methode weicht zwar von der AVM's Methode ab, aber am Ende wird letzten Endes genauso /var/install aufgerufen und das Umschalten findet dort statt.
Das, was Du sagst, trifft auf die von Freetz erstellten in-memory-Images zu. Diese werden Stand jetzt (wenn man keine Vorkehrungen trifft) in der Tat in die aktive Partition geschrieben.

Ok, das war mir neu, da muß ich also wohl was mit dem flashen aus dem Bootloader heraus verwechselt haben. Also ist es tatsächlich egal ob man das neue Image signiert oder nicht. Sofern man bereits Freetz auf der Box hat, kann man Freetz intern also auch unsigniert flashen.
 
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.