Ich weiss nicht wo ich dir sonst schreiben soll #42
Replies: 4 comments
-
Discussions wäre z.B. eine Möglichkeit gewesen - deshalb konvertiere ich das im Anschluß auch.
Das hat ja auch niemand behauptet. Ich habe ihm vor längerer Zeit schon gezeigt, wie man - automatisiert - mit meinen Repos eine originale Firmware von AVM modifizieren und signieren kann, so daß man sie (beim zweiten Mal, weil der öffentliche Schlüssel schon in der laufenden Firmware enthalten sein muß) auch über das Web-GUI von AVM installieren kann. Das kann man alles hier: https://www.ip-phone-forum.de/threads/wie-modifiziere-ich-die-originale-firmware-vom-hersteller-und-wie-installiere-ich-meine-eigene-dann-auf-der-fritz-box.307161/ nachlesen und irgendwo am Ende klappt es dann auch mit dem Signieren. Dabei WIRD der Key nun mal mit Index 9 gespeichert - da gibt es gar kein "Geheimnis" und es hat weder mit Freetz noch mit Freetz-NG etwas zu tun. Das stimmt also inhaltlich auch nicht mit "hereingefallen" (und ich weiß tatsächlich auch selbst, wer wo mit welchen Pseudonymen unterwegs ist - nicht zu schreiben heißt ja nicht automatisch auch, daß man nicht lesen kann/will) - das Problem mit der Verifikation durch AVM bei ZWEI bestimmten Dateigrößen (bisher ging ich immer von einer aus und bin nicht mal sicher, ob das "schon immer" zwei Größen betraf) und den AVM-Images, die nicht zum TAR-Standard passen, ist ja nicht weg zu diskutieren. Hier habe ich mal ein Protokoll angehangen, bei welchen Dateigrößen die AVM-Komponenten zu einem anderen Hash über die zu signierenden Daten kommen, als meine Skript-Dateien: https://www.ip-phone-forum.de/threads/wie-funktioniert-eigentlich-das-signieren-der-avm-firmware.286213/post-2450313 Die letzten Änderungen an den Signatur-Skripts (https://github.com/PeterPawn/YourFritz/tree/signimage) passen nach meiner Überzeugung schon ... ich baue jetzt nur noch ein Skript, was man auf einer Box nur noch aufrufen muß, um genau die Tests, die in meinem Protokoll zu sehen sind, auch selbst auszuführen. Die Tatsache, daß da für den bereits behandelten Sonderfall dann immer noch keine erfolgreiche Prüfung möglich war, lag wohl tatsächlich an einem falschen Key - nur ist das am Ende auch "kein Beinbruch", denn niemand ist immer fehlerfrei. Ich finde/fand es sogar relativ angenehm (nach dem Umzug in den richtigen Thread), wie da "mitgemacht" wurde und daß am Ende auch der eigene Fehler eingestanden wurde (mit dem verwechselten Key) ... auch das hat man nicht so oft. Und solange meine Skript-Dateien ernsthafte und nachvollziehbare Probleme bereiten (und das mit Rest=17 KANN ich eben nachstellen, siehe Protokoll - das war bisher noch nicht behandelt, sondern nur Rest=18), fühle ich mich dafür auch verantwortlich und korrigiere sie so weit, wie es in meiner Macht liegt. Da ich obendrein den Ehrgeiz habe, daß mein Signatur-Skript auch auf der FRITZ!Box (bzw. bei mit dem BusyBox- Die einzige Möglichkeit wäre es noch, das Image danach noch durch ein Üblicherweise ist das für mich ein FRITZ!OS mit den Kommandos, die von AVM bereitgestellt werden und alles, was darüber hinausgeht, muß ich entweder "emulieren" (wie gerade wieder das Das mache ich für die Dateien in yf_bin mit dem parallel angebotenen Freetz-Klon - wenn ich da weitere Pakete/Programme dazulegen wollte, müßte ich erst mal schauen, ob die in Freetz (und nicht in -NG, über diese Brücke gehe ich nicht) überhaupt vorhanden sind oder sie notfalls einbauen in YourFreetz. Das ist meist anstrengender, als sich bei der Auswahl der zur Verfügung stehenden Programme zu beschränken, selbst wenn dann eine Umsetzung vielleicht etwas komplizierter wird. Aber schon die Tatsache, daß man sich bei solchen Einschränkungen auch ganz bewußt noch einmal selbst auf strikte POSIX-Kompatibilität beschränken kann, entschädigt etwas für solchen zusätzlichen Aufwand - denn dann sollte das (fast immer) auch auf anderen Systemen (bis hin zu BSD-Klons wie macOS) genauso funktionieren. Egal ... es gibt halt "Gründe", warum ich es mir so schwer mache, wie ich es (desöfteren) tue - nicht immer ist der leichteste Weg auch der beste, gerade wenn es um Portierbarkeit geht. Ich kann mich auch noch an Diskussionen mit Dir erinnern, wo es um die Frage ging, ob es solche "Spezialfälle" beim Signieren überhaupt gibt und/oder ob Du mit Deinem Nachbau schon deshalb auf der sicheren Seite bist, weil Du auf GNU-tar zurückgreifen kannst/willst. Da dort dann automatisch Wobei ich mir das eigentlich gar nicht so richtig vorstellen kann - denn wenn die tatsächlich zu signierenden Daten auch bei Deinem GNU-tar so groß sind, daß der letzte Block (der halt bei GNU-tar dann auch die volle Größe von 10240 Byte hat) nur noch zwei oder drei leere Blöcke (a 512 Byte) am Ende bereithält, dann müßte auch Dein GNU-tar beim Hinzufügen des Signatur-Members durch Da Du es ja vermutlich doch noch nie selbst getestet hast, was bei den verschiedenen "Füllständen" eines Images passiert, wenn man - wie Du - mit GNU-tar (beim erstmaligen Packen und mit nachfolgendem Das OpenSSL ist ja bei Dir dasselbe (kaum verwunderlich, da sind nicht so viele Permutationen möglich), wobei ich mir bei Deiner "Forderung", daß die Dateien mit den öffentlichen Schlüsseln immer 266 Bytes haben sollen, auch schon nicht so sicher wäre - ich hoffe mal, Du hast das auch mal für einen Modulus getestet, dessen "high order bit" nicht automatisch gesetzt war, bevor die Nullen davor geschrieben wurden. Denn warum stehen da manchmal (bei AVM allerdings fast immer) noch zwei Nullen vor den anderen (hexadezimalen) Ziffern? Weil das höchste Bit als Vorzeichen angesehen wird und damit wären alle Moduli, die mit einer hexadezimalen Ziffer zwischen 8 und F beginnen, negative Zahlen. Daher setzt man noch zwei Nullen davor (für die zwei "nibble" eines Bytes in hex) und hat damit zwar eine längere Zahl, aber eine, die wieder "positiv" ist. Es kann gut sein, daß sich die AVM-Firmware darum nicht schert und die zwei Nullen auch klaglos schluckt, wenn das High-Order-Bit im zweiten Byte nicht gesetzt ist - aber ich hätte das zumindest mal ausprobiert, auch wenn man sicherlich lange suchen muß, bis man einen Modulus gefunden hat, der dieses Bit nicht gesetzt hat (obwohl das "die andere Hälfte" des Zahlenraums wäre). Ich hatte das jedenfalls auch mal für diese Variante getestet - allerdings den umgekehrten Fall, wo dann eben keine Nullen vorne angefügt werden, wenn es nicht notwendig ist. Hier: YourFritz/framework/implant_public_key Line 295 in 1de5493 Da diese Variablen nur max. 256 Byte aufnehmen können (und das auch nur, wenn man sie über den FTP-Server in EVA setzt), mußte ich führende Nullen abschneiden, wenn ich die Werte ins Urlader-Environment packen wollte - und dann natürlich passend wieder rekonstruieren. Daher weiß ich auch, daß die AVM-Firmware auch mit Moduli zurecht kommt, die keine zwei führenden Nullen enthalten - selbst wenn solche bei AVM selbst offenbar nicht vorkommen in den gesammelten öffentlichen Schlüsseln. Weil ich gerade "im Flow" bin, werde ich mir vermutlich doch mal anschauen, was bei GNU-tar und OpenSSL (so, wie es Freetz-NG in der Wobei mir auch noch ein weiterer Grund dafür, warum ich das halt so und nicht anders mache beim Signieren, wieder eingefallen ist (beim Lesen dessen, was ich da zusammengeklöppelt habe) - es bestand (bei mir, aber auch bei anderen, wie @er13) durchaus der Wunsch, das Signieren so auszuführen, daß die signierte Datei bei identischem Ausgangs-Image immer denselben Inhalt hat (reproducible builds) und sich nicht bei jeder neuen signierten Datei andere Hash-Werte über den gesamten Inhalt (also inkl. Signatur) ergeben (denn dann kann man eben anhand des Hashs schon entscheiden, ob es dieselbe Datei ist oder nicht). Das klappt natürlich auch nicht, wenn man es so macht, wie Du in |
Beta Was this translation helpful? Give feedback.
-
|
An die Disukussion hab ich gar nicht gedacht
Im IPPF sind Anhänge nicht öffentlich. Am besten als Text schreiben oder sonstwo (github/pastebin) posten ;-) "mktemp" ist bei Freetz mit FOS 7.0 zuerst fehlend aufgefallen: https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/Config.in#L448 Wenn ich mir https://boxmatrix.info/wiki/Property:mktemp#Model-Matrix so anschaue benutzt AVM das wohl aber schon länger - manchmal.
Vielleicht kannst du dich noch daran erinnern dass ich mal die beiden Signaturmethoden vergleichen wollte, irgendwas mit dem (deinem?) Script funktionierte dann nicht und ich habs sein gelassen... Daher weiss nicht ob beide gleich gut sind! Probleme beim Flashen über AVM Webif hatte ich nie. Aktuelle flashes ich nur noch ca 1x/Monat da mein letztes Gerät mit FOS als Modem genutzt wird und immer die Gefahr besteht dass die Telekom die 30mbit-Assia-Drossel für 3 Wochen verhängt ^^
AVM nutzt doch immer nur 010001 :) Ich glaub wenn keiner gesetzt ist wird das als Fallback verwendet
Du meinst die temporäre Datei? Der Name ist bei jedem Durchlauf ein anderer aus 36^10 Möglichkeiten tar-gnu wird in NG deshlab verwendet weil die BB Version schlicht keine append kennt... Wie gesagt ich hab das aus kriegaex's ursprüngliched Idee oder Script, weiss nicht mehr genau.
Eigentlich wird fwmod nicht dazu verwendet ein vorhandenes Image zu signieren, sondern es wird falls aktiviert das Image signiert ausgegeben... Ob die append-Methode immer das gleiche Image ausgibt hab ich aber nie ausprobiert - warum sollte es nicht? Das hängt vom tar ab. Warum man unbedingt hier ein "reproducible build" habe will erschliesst sich mir nicht, Images werden nicht verteilt und selbst nachinstallierbare Pakete gibt es nicht richig (abgesehen von den nicht vollendeten Anfängem mit dynamic-external) PS Hast du dir angeschaut weshalb AVM in 7.29 was am Telefondaemon beim Parsing der übertragenen Rufnummer geändert hat?. Im Changelog find ich dazu nichts |
Beta Was this translation helpful? Give feedback.
-
Eben diese Quelle habe ich noch nie gesehen - ich hatte schon vor ca. 5 Jahren gefragt, wo man das denn nachlesen konnte und bisher hat mir das noch niemand sagen können. Mit "Lücke" meine ich nichts in Freetz-NG oder Aber das muß man eben erst mal ergründen - es beginnt ja damit, daß man erst einmal feststellt, was passiert, wenn man da noch leere Blöcke als EoA anhängt. Werden die nicht nur ignoriert, sondern bei Hashen mit einbezogen, ist das auch keine Lücke, sondern nur eine weitere Idee/Theorie, die sich nicht bestätigt. Davon hatte ich schon so viele, daß ich damit handeln könnte - Bug-Bounty ist ein eher undankbares Geschäft. 😏
Das ist der Exponent - der Modulus ist die 1024-Bit-Zahl in der ersten Zeile einer Datei im AVM-Format (.asc).
Kann man zwar auch auf der eigenen Box "nachmachen", aber ich hänge es hier noch mal ran, quasi als "Demo", denn ich sehe das dann hier (in "show and tell") als eine Art Beschreibung dessen, was ich an den Skripten zum Signieren noch geändert habe - das war mir nur zu lang für eine CODE-Box im IPPF. Aber der IPPF-Link mit dem "Verlauf" steht weiter oben, das muß ich hier nicht alles wiederholen (auch nicht als Dokumentation) - der Anhang steht unten.
DAS sehe ich tatsächlich auch als Problem, aber niemand verlangt das von denjenigen, die es anwenden. Man kann es ja auch einfach nur laden, sich genau ansehen und es danach erst ausführen (die enthaltenen Erst bei den Dateien in #reproducible builds Ich habe dabei halt auch nicht nur das Signieren kompletter Firmware-Images im Hinterkopf - für andere Zwecke (ein Beispiel findet man hier: https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/packages) wird das Signieren ja auch noch verwendet. Zwar kann tatsächlich niemand außer mir mit dem verwendeten privaten Schlüssel signieren (und das damit auch nicht 100% prüfen), aber man kann die Datei nehmen, meine Signatur entfernen und sie dann erneut mit einer eigenen Signatur unterzeichnen ... das kann man (bei identischer Ausgangsdatei) dann auch beliebig oft wiederholen und wird immer wieder bei demselben Ergebnis landen. Und auch wenn's lange nicht jeder so macht ... schon die einfache automatische Prüfung, ob eine lokal bereits vorliegende Datei und eine auf einem Server bereitgestellte einen identischen Inhalt haben (und sei es die noch einmal neben dem eigentlich interessanten File liegende Text-Datei mit einem Hash-Wert - das kennt man auch von genug Sites, die Software anbieten), kann für Entscheidungen pro oder contra im Bezug auf die Notwendigkeit eines Updates/neuen Downloads herangezogen werden. Und bei der Verwendung von AVM verwendet zum Packen auch mit ziemlicher Sicherheit irgendetwas anderes als GNU- Daher gehe ich davon aus, daß man bei AVM irgendwelche alten
Ich bin etwas knapp mit freier Zeit und habe mir daher bei AVM in letzter Zeit praktisch gar keine Einzelheiten der Firmware angesehen (mal abgesehen von diesem Thema hier) - wobei ich (angesichts des Tempos, mit dem AVM die 07.29 ausgerollt hat - mittlerweile ist man ja einigermaßen durch bei den Modellen) auch davon ausgehe, daß sich da irgendwo in den Vorgängerversionen ein kleines, niedliches Problem gezeigt hat, was zu dieser (doch einigermaßen ungewöhnlichen) Hauruck-Aktion geführt hat. Immerhin hat man in den letzten sieben Jahren dazu gelernt und behebt jetzt solche Probleme wohl schon, bevor sie auf breiter Front ausgenutzt werden. Ich habe jedenfalls bisher nichts mitbekommen, daß es vermehrt Probleme bei Besitzern von AVM-Geräten gab - also wird AVM hier schon vor dem größeren Schaden tätig geworden sein (mich irritieren eher die aktualisierten CAs lt. Anhang: Demo des Signatur-Problems bei bestimmten Größen der zu signierenden Daten |
Beta Was this translation helpful? Give feedback.
-
Das müsse auf der Freetz-Mailingliste gewesen sein. Die war aber nicht öffentlich und ein Archiv gab es nicht. Ich hatte mir nur die wichtigsten Auszüge als .txt gespeichert
Da sieht man gleich wie gut ich mich auskenne :)
Auf zb Github fänd ich es trotzdem vertrauenserweckender, dort sieht man die Historie (die man aber auch ändern könnte). Ein Webserver wie nginx könnte abhängig von der Uhrzeit, IP, Agent usw anderes Script ausliefern...
Das könnte man leicht beheben, zb den Timestamp der Signatur immer auf 1970 setzten, oder von der zu signierenden Datei kopieren oder vom .image in der zu signierenden Datei. Wobei die zu Signierende bei Freetz zuvor neu erstellt wird und eh immer unterschiedlich ist. Daher glaub ich für fwmod in Freetz ist das egal
Ich vermute nicht dass sie AVM beim Packen viel Stress gemacht hat. Da wurden irgend welche uralten Sourcen einer Tar implementierung genommen, und über die Jahre immer mitgeschleppt. Wenn es dann irgend wann mal auffiel wurde die Prüfung für diese entsprechend angepasst. Ohne Quellcode kann das niemand prüfen.
Dieses im September abgelaufene Letsencrpyt Zertifikat kann schon Probleme verursachen. Ein Updategrund für alle Boxen seh ich dafür aber auch nicht, höchstens so ein plus/beta.
Mit ist auch nur aufgefallen dass mit 7.39 wohl Wireguard getestet wird. Prima dass AVM im Jahr 2021 auffällt dass ein IPv4-only VPN Mist ist! Dass die bösen ISP bei CGNAT auch kein PCP für AVM anbieten! https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-6360/1306_Sind-VPN-Verbindungen-zur-FRITZ-Box-mit-IPv6-oder-DS-Lite-moglich/ |
Beta Was this translation helpful? Give feedback.
-
deshlab mach ich es hier, nach dem Lesen bitte einfach löschen...
Tja, du bist mal wieder auf die DEBen reingefallen! Und bevor du noch mehr Zeit mit diesen Experten verschwendest
"key9" hat mit NG nichts zu tun: https://github.com/Freetz-NG/freetz-ng/blob/master/fwmod#L1880
Freetz/ dagegen schon, dort gibt es aber keine FOS 7.25+
Sondern insti(ippf) aka osprey (deb-moderator) hat es selbst verpfuscht:
https://instinto.mooo.com:1974/osprey/avm_firmware_public_key9
https://youtu.be/kx5pf5YF2W8?t=117
https://www.digital-eliteboard.com/threads/491034/
Beta Was this translation helpful? Give feedback.
All reactions