[Info] Unter die Haube geschaut - Änderungen/Neuigkeiten im FRITZ!OS der Labor-Reihe 07.19

[PeterPawn]

Ich mache hier mal einen Thread auf, in dessen erstem Beitrag ich - in loser Reihenfolge - die wichtigsten Sachen aufführen will, die mir beim Blick in die Innereien der neuen Labor-Version 113.07.19-73512 (auch wenn die nach Labor-Maßstäben schon fast wieder angestaubt ist) aufgefallen sind. Die Änderungen bei der 7590 dürften ähnlich ausfallen ... schon die von AVM veröffentlichten Informationen in der "infolab.txt" der jeweiligen ZIP-Archive sprechen ja dafür.

Das hier zu Beschreibende betrifft sowohl ein paar deutlich sichtbare Neuheiten, als auch einige Spekulationen und die Erkenntnisse werden sich sicherlich - wie so oft beim Erscheinen einer "neuen Generation" des FRITZ!OS, auch wenn das wohl keine 8 in der Nummer wird - auch erst nach und nach entwickeln.

Bisher habe ich diese Version noch gar nicht auf einer 7490 installiert, die ersten Infos beruhen also bisher ausschließlich auf dem Blick auf/in die entpackte Firmware und schon der erste Start kann da ggf. eine (falsche) Annahme wieder über den Haufen werfen - ich werde also deutlich machen, wo die Erkenntnisse aus Tests der installierten Version starten. Etwaige Irrtümer werde ich auch nicht dadurch korrigieren, daß ich einmal Geschriebenes ändere oder lösche ... wenn nötig, kommt da eine Ergänzung mit dem Verweis auf neuere Erkenntnisse hin oder ich gehe sogar davon aus, daß man die Beiträge bis zum Ende liest und spätere Korrekturen auch im "reinen Text" findet und erkennt. Wer das nicht möchte, sollte ggf. gleich in Erwägung ziehen, ab hier nicht weiterzulesen.

---------------------------------------------------------------------------------------------------------------------

Kernkomponenten:

- 7490: generell wohl GCC 5.5.0 als Compiler, uClibc-ng 1.0.30 als C-Library, Kernel-Version unverändert 3.10.107

- 7590: GCC 8.3.0, musl libc 1.?.?(!) als C-Library, Kernel-Version 4.9.198 - ich wage mal eine pessimistische Prognose hinsichtlich der Open-Source-Quellen, denn "musl" steht unter MIT-Lizenz und wenn die nicht dabei sind und sich niemand der Sache annimmt, die entsprechend einzupflegen (auch wenn bei "musl" jetzt nicht wirklich viele Konfigurationsoptionen existieren, wie bei uClibc[-ng]) im passenden Stand (denn auch da gibt es ab und an eine neue Version: http://git.musl-libc.org/cgit/musl/), dann würde Freetz wohl langsam sterben bei den neueren Modellen ... die Software-Auswahl von AVM, wenn es gilt, bisher verwendete Teile zu ersetzen [von NTFS über Samba bis jetzt zur C-Library] zeigt ja auffällig in eine bestimmte Richtung und die geht eindeutig weg von GPL und Verwandten

------------------------------------------------------------------------------------------------------------------------------------

Kurze Stichpunkte von meinem Notizzettel - nicht immer mit ausführlicher Betrachtung:

- Systemstart über ein "systemd"-Derivat (zumindest benutzt das dieselben Strukturen wie der "systemd") mit dem Namen "supervisor"

- dadurch aufgeteilter Start der meisten Dienste ... vieles ist schon auf den "supervisor" (ich nenne den jetzt "SV", bei AVM gibt es auch eine neue Library "libsvctrl.so", die wohl zur Steuerung dieses Daemons dienen dürfte) umgestellt - das findet sich in "/etc/boot.d" und in "/lib/systemd/system" und nur noch wenige Skript-Dateien sind in "/etc/init.d" verblieben, wobei mancher Start eines Dienstes auch einfach wieder eines der "rc.something"-Scripts aus "/etc/init.d" aufruft

- durch den geänderten Ablauf beim Start sind sicherlich viele Modifikationen noch einmal zu überprüfen, besonders solche, die sich in zuvor vorhandene AVM-Dateien eingeklinkt haben (Bsp: debug.cfg (aka rc.user) - die "S99-tail" bzw. "E99-tail", aus der die zuvor aufgerufen wurden bei den meisten Mods, gibt es gar nicht mehr, ebensowenig wie die "rc.tail.sh")

- damit funktioniert auch der Start von Freetz nicht mehr so richtig (wenn ich das richtig in Erinnerung habe bzw. richtig lese), weil die Änderung zum Aufruf der "rc.mod" aus der "rc.tail.sh" (https://github.com/Freetz/freetz/blob/master/patches/scripts/115-patch-ds_off.sh) ins Leere greift und auch der Versuch, sich an der "/etc/init.d/rc.S" zu vergehen (im "else"-Zweig des Patches,) hier zum Scheitern verurteilt ist

- witzig ist es (jedenfalls in gewissen Grenzen), daß die BusyBox von AVM immer noch den "telnetd" als Applet enthält - halt mit der bekannten Überprüfung, ob "/usr/sbin/telnetd" ein Symlink ist (wohin ist dann schon wieder egal) ... man braucht also für einen schnellen Telnet-Zugriff noch eine Möglichkeit zum Setzen des Symlinks und zum Starten des Daemons, aber nicht zwingend weitere Binaries (was bei der 7590 wieder bedeutsam werden könnte, wenn die immer noch das "overlayfs" im Kernel enthält und man damit - mit sehr geringem Aufwand - den Symlink im "upperdir" erzeugen könnte)

- die Verwaltung der VPN-Verbindungen wurde (vermutlich) aus dem "ctlmgr" ausgelagert (wobei Teile wohl auch im "kdsld" waren) und in einen neuen Daemon namens "vpnd" integriert, der auch ein IPC-Interface hat (was das kann, kriegt man erst wieder so richtig raus, wenn man den mal in Aktion erlebt)

- zuerst dachte ich schon, AVM hätte die "Vorgaben" in der "ar7.cfg" heftig zusammengestrichen, weil die nur noch 4.775 Byte belegt, im Gegensatz zu 11.826 in der 07.11 - das hat sich aber als Irrtum herausgestellt, weil AVM nur auf die ganzen Leerzeichen (ggf. auch Tabs) in der Vorlage verzichtet und das jetzt nicht mehr eingerückt ist ... was das am Ende beim Export bedeutet oder ob da wieder das "bekannte Bild" entsteht, muß sich noch (er)weisen

- wenn's schlecht läuft, müssen die ganzen Tools überarbeitet werden, die mit Export-Dateien umgehen können ... es gibt intern zusätzliche "Dateitypen" namens "B64FILE" und "CRYPTEDB64FILE" und wenn der Name nicht in die Irre führt, wird AVM da wohl Base64-Kodierung für die Daten verwenden - ob das die bisher verwendete Hex-Kodierung für "[CRYPTED]BINFILE" ersetzt oder ergänzt, wäre ebenso noch zu erkunden (geht wieder erst nach der Installation)

- PŸUR ist als Vorlage für die VoIP-Provider hinzugekommen

- einige Utilities wurden "renoviert" und befinden sich jetzt nicht mehr unter /usr/sbin wie bisher, sondern sind direkt in /sbin zu finden (wenn man die durch eigene Dateien ersetzen wollte)

- zusammen mit dem Samba-Server "nqcs", der ja als Versuch schon vor einem knappen Jahr mal "das Licht der Welt erblickte" im FRITZ!OS, wird jetzt offenbar auch AppArmor (ein zusätzlicher Security-Layer, der die Rechte von Prozessen auf das tatsächlich Notwendige zusammenstreichen kann und das ist erst recht sinnvoll, wenn es - wie im FRITZ!OS - ansonsten kein "Rechtekonzept" gibt und praktisch alles als "root" läuft) in diese Version Einzug halten

- bisher ist der "nqcs" jedenfalls wohl der einzige Prozess, der unter AppArmor-Regie arbeitet (siehe /lib/apparmor.d) - AVM legt hier offenbar auch nur das bereits von "apparmor-parser" verarbeitete binäre Profil dazu (Option -o) und ich muß erst mal schauen, ob "apparmor-parser" das auch wieder zurückübersetzen kann oder ob der laufende AppArmor-Daemon dann auskunftsfreudiger ist hinsichtlich der Rechte, die dem "nqcs" tatsächlich zugestanden wurden von AVM

- daß der "multid" dazugelernt hat, versteht sich angesichts des offiziell eingeräumten DoT-Supports von selbst ... aber daß er jetzt wohl auch noch LLDP versteht (und zwar vermutlich nicht nur, wenn ihn andere befragen, sondern auch zur Zusammenstellung der eigenen "Weltsicht" - aka FBSTATE, u.U. sogar mit irgendwelchen persistent gespeicherten Daten, die "libavmfbstate.so" enthält jedenfalls Strukturen, die man bei AVM sonst nur findet, wenn es um die Verarbeitung von Konfigurationsdateien geht), steht bisher aber nicht bei AVM (und vielleicht funktioniert es ja auch noch nicht, es ist aber neu im "multid")

- die Zertifikate für die Validierung von DoT-Servern hat AVM gesondert in der Firmware untergebracht (als "dot_ca_root.pem") ... da sind 17 CA-Zertifikate enthalten (nur gezählt, nicht weiter dekodiert mit "openssl x509") und eines davon ist wohl auch das LE-(CA-)Zertifikat - wer aber mit einer gänzlich eigenen PKI und der originalen Firmware DoT betreiben will (also auch mit eigener CA und von der signierten Zertifikaten), der wird wohl in die Röhre schauen und um eine Änderung (Hinzufügen der eigenen CA zu den erlaubten) nicht herumkommen

- das "preloading" von Firmware-Updates, wobei diese dann im NAND-Flash (andere Geräte mit eMMC sind hier ja bisher auch nicht Thema) unter "FRITZ" gespeichert werden, war schon in der 07.1x in Ansätzen vorhanden ... jetzt ist wohl irgendetwas wie ein "SILENT_UPDATE" dazugekommen und die Box kann irgendwie angewiesen werden, eine neue Firmware-Version erst einmal nur zu laden und abzulegen, bevor sie später irgendwann installiert wird

- ob das direkt mit der Möglichkeit der Auswahl eines Zeitraums für die Installation von Updates korreliert oder ob das doch am Ende nur ein Mechanismus ist, mit dem der JUIS die Box dazu anweisen kann, solche Updates schon mal "auf Lager" zu packen und ob das gar auch noch über TR-069 geht, muß sich erst noch zeigen (vielleicht auch erst dann, wenn dieser Fall tatsächlich mal auftaucht bei AVM)

- jedenfalls hat AVM die Liste der "verbotenen Dateien" beim NAS-Zugriff nun noch einmal erweitert, nachdem schon in der 07.1x diese ".../FRITZ/firmware_update.image[.something]"-Dateien hinzugekommen waren - nunmehr ist auch der Zugriff auf die BPjM-Updates blockiert (der Zugriff auf die "Stammdatei" mit ".data" war das bereits) und auch die Dateien für die C&C-Überprüfungen (candc.data und candc.update) werden jetzt wohl vor dem Benutzer "versteckt" bzw. sind wohl zumindest nicht länger lesbar über die NAS-Funktionen ... wenn jetzt noch die Media-Server-DB dazukäme (ich nehme mal an, daß die immer noch lesbar ist, denn in der "libavmacl2.so" ist sie nicht als "spezieller Name" zu finden), müßte man beim Auslesen von USB-Sticks über den Media-Server doch endlich mal raten (das wäre zwar "sicherer", aber noch längst nicht "sicher", für die "other files", die eben keine Media-Dateien sind)

- auf den ersten Blick sieht auch noch ein Feature namens "asec" spannend aus ... das sieht nach irgendwelchem zentralen "Nachrichtensammeln" aus, was AVM da (unter Zuhilfenahme des "nanomsg-ng"-Projekts (https://github.com/nanomsg/nng) - was, nebenbei bemerkt, ebenfalls unter MIT-Lizenz steht und das war vermutlich auch der Punkt, nach dem AVM sich dieses Projekt für diesen Zweck ausgesucht hat) zusammenstrickt - ich habe es allerdings bisher nur aus den Funktionsnamen geschlossen und nichts davon in Aktion gesehen; abgesehen davon, wird dieses Sammeln ggf. erst mit mehr als einem Gerät loslegen, solange die Daten nicht doch am Ende für jemand ganz anderen gedacht sind ... wenn da von "trusted" und "untrusted" die Rede ist, werde ich schnell hellhörig

 

[grundigboy]

Hallo Peter Pawn,

ich bin sprachlos. Wenn hier jemand von AVM mitliest, sollte er Dir sofort einen Job anbieten. Das kann man ja schon fast als Reverseengineering auffassen. Jedenfalls machst Du die Arbeit von AVM für Laien wie mich etwas transparenter.

Vielen Dank!

 

[koyaanisqatsi]

Moinsen

- wenn's schlecht läuft, müssen die ganzen Tools überarbeitet werden, die mit Export-Dateien umgehen können ... es gibt intern zusätzliche "Dateitypen" namens "B64FILE" und "CRYPTEDB64FILE" und wenn der Name nicht in die Irre führt, wird AVM da wohl Base64-Kodierung für die Daten verwenden - ob das die bisher verwendete Hex-Kodierung für "[CRYPTED]BINFILE" ersetzt oder ergänzt, wäre ebenso noch zu erkunden (geht wieder erst nach der Installation)

Das Telefonbuch lässt sich mit /usr/bin/base64 -d problemlos mitsamt der grottigen XML Struktur "decrypten".

Lustigerweise steht in den erweiterten Supportdaten, wie sie zu behandeln sind...

radio history
extract like this: base64 -d <radio_hist.b64> | gzip -dc > radio_hist.txt
-------------
<<<<<BASE64:BEGIN>>>>>

...oder ist das nur bei den Inhaus Versionen so?

- jedenfalls hat AVM die Liste der "verbotenen Dateien" beim NAS-Zugriff nun noch einmal erweitert, nachdem schon in der 07.1x diese ".../FRITZ/firmware_update.image[.something]"-Dateien hinzugekommen waren - nunmehr ist auch der Zugriff auf die BPjM-Updates blockiert (der Zugriff auf die "Stammdatei" mit ".data" war das bereits) und auch die Dateien für die C&C-Überprüfungen (candc.data und candc.update) werden jetzt wohl vor dem Benutzer "versteckt" bzw. sind wohl zumindest nicht länger lesbar über die NAS-Funktionen ... wenn jetzt noch die Media-Server-DB dazukäme (ich nehme mal an, daß die immer noch lesbar ist, denn in der "libavmacl2.so" ist sie nicht als "spezieller Name" zu finden), müßte man beim Auslesen von USB-Sticks über den Media-Server doch endlich mal raten (das wäre zwar "sicherer", aber noch längst nicht "sicher", für die "other files", die eben keine Media-Dateien sind)

Auweia, ist mir im NAS Webinterface gestern passiert, dass im FRITZ Verzeichnis der frisch hochgeladene "xml" Ordner vor meinen Augen verschwand.
...sowas passiert mit FTP jedenfalls ( noch ) nicht.

 

[iXware]

- Systemstart über ein "systemd"-Derivat (zumindest benutzt das dieselben Strukturen wie der "systemd") mit dem Namen "supervisor"

der Supervisor wird doch üblicherwiese in Docker-Containern eingesetzt... da ist er mir jedenfalls aufgefallen

 

[PeterPawn]

Wenn Du den hier meinst:

Supervisor: A Process Control System — Supervisor 4.2.5 documentation

... den kenne ich auch aus der Benutzung zusammen mit bzw. in Docker-Containern (wenn auch selten, weil "multi-service container" ja fast ein Widerspruch in sich sind).

Nur verwendet der ja eigentlich andere Strukturen zur Prozess-Steuerung und andere Verzeichnisse (http://supervisord.org/configuration.html), als das, was da im FRITZ!OS hinzugekommen ist. Der Syntax-Aufbau der Service-Files und auch die verwendeten Pfade (/lib/systemd/system) in 07.19 sehen viel eher nach "systemd" aus.

Vielleicht gibt es aber tatsächlich ein ähnliches "supervisor"-Projekt und das ist am Ende doch kein von AVM angepaßtes Derivat des "systemd" - das werden irgendwann die Quellen mal zeigen, so der OSS-Gott oder AVM (was ich per se nicht gleichsetzen würde) das will.

Ich kenne bisher kein solches Projekt (und war auch bei der Suche danach im Netz nicht sehr erfolgreich) - wenn Du tatsächlich das von mir oben verlinkte Projekt meinst, bezweifle ich eher, daß AVM auf diesem aufsetzt und erst recht, daß dieses von AVM 1:1 eingesetzt wird.

 

[PeterPawn]

Ich habe jetzt mal bei AVM einen Versuchsballon gestartet und die Quellen für die 07.19 angefordert ... eine Beschränkung der Lizenzbestimmungen auf "Release-Versionen" kann ich dem GPL-Text nicht entnehmen und die öffentliche Labor-Version ist auch keine "interne Nutzung" mehr.

Bei der Gelegenheit habe ich das gleich noch auf die 7490, 7580 und eben die 7590 erweitert und auch die Quellen für die Release-Versionen 07.12 (solange die 07.11 dieselben verwendet, ansonsten auch die für diese Version) angefordert ... immerhin sind die Versionen jetzt alle mehr als drei Monate draußen. Sollte sich jemand veranlaßt sehen, das ebenfalls noch einmal bei AVM einzutüten, könnte das vermutlich nicht wirklich schaden - besonders dann, wenn man das möglichst noch vor Weihnachten erhalten wollte (auch für Freetz hängt das "replace kernel" ja an der Verfügbarkeit der (korrekten) Quelltext-Pakete), wo vielleicht ja doch die Zeit für die eine oder andere "Integration" vorhanden wäre.

Ansonsten würde ich mal raten, daß sich die neuesten Labor-Versioenn tatsächlich auch auf den internationalen Versionen der FRITZ!Box (mit Branding "avme") installieren und benutzen lassen ... sogar die 7490-Version enthält die notwendigen Daten und Einstellungen für eine internationale Box.

Das steht zwar (m.W. - gerne nehme ich Hinweise auf entsprechende Quellen) nirgendwo offiziell bei AVM, aber der Blick in die Firmware zeigt es dann doch (neben der anderenorts schon erwähnten /var/install), daß alles Notwendige an Bord wäre ... allerdings auch erst seit der Subversion 74093 (7590) bzw. 74082 (7490).

Vielleicht lohnt sich in den Threads für die Labor-Reihe der beiden Modelle auch noch einmal ein entsprechender Hinweis (was auch heißen soll, daß ich selbst den dort nicht platzieren werde) ... event. findet sich ja der eine oder andere Interessent mit einer internationalen Box.

Ich hänge hier mal einen Link auf den 7590-Labor-Thread an, weil dort schon geschrieben steht, was AVM hinsichtlich der Voraussetzungen, die ein Browser erfüllen muß, geändert hat: https://www.ip-phone-forum.de/threads/fritz-box-7590-07-19-labor-serie.305074/post-2349964

Nach der Installation (auf einer 7490) und der Analyse einer Sicherung mit dieser Version stellt sich heraus, daß AVM wohl tatsächlich das "BINFILE" durch "B64FILE" komplett ersetzen will ... damit müssen dann die entsprechenden Tools auch angepaßt werden. Für "decoder" versuche ich das zeitnah auf die Reihe zu kriegen.

 

[hermann72pb]

@PeterPawn Mir macht da mehr Sorgen, dass die ganzen alten "Injektionen" in die Start-Routinen (vor allem FREETZ) nicht mehr lauffähig wären, wie du ja oben schreibst. Da ich wiederum dein modfs nicht nutze und nicht in Detail angeschaut habe, wie du es gemacht hast, würde mich interessieren, was du denn bei modfs anders als bei FREETZ machst, dass es dennoch trotz neusten Änderungen lauffähig wäre. Aber bitte kurz und knapp, wenn es geht. Die Story über 600 Pixel und Session-ID bei FREETZ brauchst du nicht zum x-ten Mal zu wiederholen...
Dass du dich an deine crypt-Themen schon so früh ran machst ist sehr gut. Es ist auch sehr gut, dass du detailliert die Neuerungen analysiert hast und hier auch mit allen teilst. Mich würde aber gerne deine Prio-Liste interessieren: Was siehst du als Hauptbaustellen für alle mods im Zusammenhang mit neuen Firmwares? Was muss man tun, damit FREETZ trotzdem start- und lauffähig wäre?

Danke!

 

[PeterPawn]

Heute um 15:57 Uhr habe ich von AVM die Mitteilung erhalten, daß die Quellen für 07.12 für die drei Modelle 7590, 7580 und 7490 auf dem OSP-Server bereitstehen.

Die Quellen für die Labor-Version brauchen noch etwas, steht in derselben Mail.

--------------------------------------------------------------------------------------------

Was noch auffällt in der 113.07.19 ... das bisher zum Generieren von internen RSA-Keys verwendete openssl_genrsa ist verschwunden.

Nun war das ja bisher auch ein Problem in der FRITZ!Box (zumindest in der Theorie), daß da beim Start mit "blanker Firmware", also den Werkseinstellungen, irgendwann beim Start des ctlmgr mal die benötigten internen Keys generiert wurden (über die libcmapi.so) und daß sich die Abläufe bis dahin ziemlich gut "voraussagen" ließen und praktisch immer nach demselben Schema abliefen (also reproduzierbar waren mit eher geringen Streuungen), weil auf die Ergebnisse der DSL-Initialisierung in E40-net (wo sich die Umgebung dann tatsächlich mal unterscheiden könnte) keine Rücksicht genommen wurde bis zum Start des ctlmgr in E46-net und es ansonsten keine anderen Entropie-Quellen gab.

Zumindest keine der üblicherweise im Linux-Kernel implementierten (s.a.: https://www.bsi.bund.de/SharedDocs/...uxRNG/LinuxRNG.pdf?__blob=publicationFile&v=2), denn die FRITZ!Box hat weder eine RTC (und zu diesem Zeitpunkt auch nur sehr, sehr selten tatsächlich eine aktuelle Uhrzeit, die ebenfalls als Entropie-Quelle herhalten kann) noch eine HDD, wo der Kernel aus unterschiedlichen Zugriffszeiten (weil sich die Scheiben halt drehen und nicht feststeht, wie lange es dauert, bis ein gesuchter Sektor unter dem Schreib-/Lesekopf auftaucht) ebenfalls etwas Unordnung gewinnen kann.

Auch mit Eingabegeräten (Tastatureingaben, Mouse-Bewegungen) sieht es an so einer FRITZ!Box (wie an jedem anderen SOHO-Router) eher mau aus ... damit kommen da nicht so sehr viele Quellen zusammen, aus denen sich eine solche Unordnung als Startwert für einen (P)RNG (einen "(pseudo) random number generator" - der eben bei identischen Vorgaben auch identische Ausgaben liefern würde) ableiten ließe und so etwas schränkt den Umfang (bzw. die "Zufälligkeit") von Zufallswerten häufig tatsächlich so weit ein, daß man mit überschaubarem Aufwand die am Ende aus diesen (schlechten) Zufallszahlen generierten RSA-Keys ermitteln kann (selbst wenn das immer noch sehr viele verschiedene sein mögen, sind eben 1 E5 oder 1 E6 Keys schon "überschaubar" mittels moderner Rechentechnik) und wenn man deren private Anteile (aka "privater Schlüssel") dann erst einmal kennt, kann man mit diesem Key aufgezeichnete verschlüsselte Verbindungen auch wieder dekodieren (zumindest solche ohne "perfect forward secrecy" - PFS) oder sich als "man in the middle" (MITM) in solche Verbindungen einklinken.

Wenn AVM das openssl_genrsa also zugunsten eines anderen Zeitpunkts (und zu diesem Zeitpunkt dann mehr Entropie verfügbar ist, damit die Zahlen auch tatsächlich zufällig sind) oder auch einer anderen, zusätzlichen Entropie-Quelle für die Generierung dieser Zufallszahlen entfernt hat, wäre das sogar sehr positiv ... auf alle Fälle hat man das Generieren mal in die libavmcrypto.so umgezogen (als ac_gen_rsa_private_key_async()) und verwendet offenbar direkt die Funktion RSA_generate_key_ex() aus der libcrypto.so von OpenSSL dafür - hoffentlich nach ordentlichem "Seeden" des RNG.

Wenn das jetzt auch noch zu einem "unvorhersehbaren Zeitpunkt" aufgerufen wird (oder die Qualität durch eine passende Entropie-Quelle sichergestellt ist, was dann den Zeitpunkt wieder unerheblich werden läßt) und dieser Umzug am Ende nicht nur dem Umstand geschuldet ist, daß die Firmware inzwischen mehr als einen dieser Keys braucht (u.a. auch für die Nexus-Authentifizierung) und man deren Generierung irgendwie zusammenfassen wollte, dann könnte der RSA-Key nach dem Zurücksetzen einer FRITZ!Box von dieser Labor-Version an tatsächlich von deutlich höherer Qualität sein. Ich finde es nur schade, wenn/daß AVM solche "Kleinigkeiten" (auf die sich ja in der Vergangenheit auch Kritik an der Firmware stützte) nicht veröffentlicht und man das alles irgendwie selbst erkunden muß.

Gut, vielleicht wäre damit auch das Eingeständnis verbunden, daß es mit der Entropie einer FRITZ!Box zum Zeitpunkt der Generierung des internen privaten Schlüssels tatsächlich nicht so weit her war ... den Überblick darüber hat wohl am ehesten AVM selbst, weil man dort ja ziemlich problemlos über alle angemeldeten MyFRITZ!-Boxen iterieren könnte und jeder identische öffentliche Schlüssel (nicht das Zertifikat, nur der darin beglaubigte Schlüssel) zeigt automatisch auch an, daß der private Schlüssel derselbe ist.

Aber wenn man eine solche Schwachstelle dann abgestellt hat (was ich jetzt mal unterstelle/hoffe) und AVM war keineswegs der einzige Hersteller, der sich für solche "embedded devices" diese Fragen stellen lassen mußte (https://cseweb.ucsd.edu/~swanson/papers/Oakland2013EarlyEntropy.pdf), dann sollte man auch damit prahlen und an die Öffentlichkeit gehen.

Ich hoffe nur, ich täusche mich hinsichtlich der Qualität jetzt nicht und AVM wollte am Ende nur dafür sorgen, daß man das Kennwort für den privaten Schlüssel nicht länger in einem Aufruf von openssl_genrsa "abgreifen" kann ... wie das beim zuvor verwendeten Aufruf openssl_genrsa -aes128 -passout 'pass:%s' 2048 > %s möglich war, wenn man ein eigenes Shell-Skript (o.ä.) in den Suchpfad einschmuggeln konnte vor dem bzw. anstelle des eigentlichen openssl_genrsa ... denn der Aufruf erfolgte ohne komplette Pfadangabe und war damit zumindest auch potentiell anfällig für "path injections" ... und "by the way": Für den Aufruf von "openssl_req" beim Generieren eines (self-signed) Zertifikats gilt das mit der Path-Injection noch immer. Nun kann man natürlich die Frage stellen, wie man den Suchpfad ändert und die Theorie aufstellen, daß jemand, der das vermag, dann auch die Datei gleich im SquashFS austauschen oder überlagern könnte ... aber so eine zusätzliche Hürde ist eigentlich nie falsch und manchmal auch der (häufig nur zufällige) Stolperstein, an dem ein Hacker am Ende scheitert (selbst wenn externe Volumes inzwischen nur noch mit "noexec" gemountet werden, was durchaus eine weitere "Verteidigungslinie" darstellt).

EDIT: Der Link hier: https://factorable.net/weakkeys12.extended.pdf geht zu einer Abhandlung über praktische Tests von Entropie in solchen Geräten ... der oben war "abgerutscht" beim Kopieren aus meiner Linksammlung und führt zu Vorschlägen, wie man mangelhafter Entropie bei "embedded devices" entgegenwirken kann.

 

[PeterPawn]

Die neueste Labor-Version für die 7590 (ich schaffe es rein zeitlich nicht, in jede dieser Versionen zu schauen und weiß nicht mal genau, welche die vorhergehende war - mit "neueste" meine ich die 74611) enthält jetzt ziemlich am Beginn des Bootprozesses folgenden zusätzlichen Aufruf:

#!/bin/sh
. /etc/boot.d/msg
mount -t proc proc /proc
mount -t tmpfs tmpfs /var
mount -t sysfs sysfs /sys
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
mount -t securityfs securityfs /sys/kernel/security
tar xf var.tar
[ -x /etc/init.d/rc.hwcrypto ] && /etc/init.d/rc.hwcrypto

(es geht um die letzte Zeile des Ausschnitts)
und inzwischen gibt es diese "rc.hwcrypto" auch (die 74093 hatte sie noch nicht, obwohl die Aufruf-Zeile schon vorhanden war ... aber auch die LKM fehlten noch).

Diese Datei hat jedenfalls den folgenden Inhalt:

#!/bin/sh

. /etc/boot.d/msg

ENTROPY_FILE="/proc/sys/kernel/random/entropy_avail"

# threshold at which linux stops polling hwrng devices for data
# see random_write_wakeup_bits in /drivers/char/random.c
ENTROPY_THRESHOLD=896

# fill entropy pool
modprobe eip123

while [ $(cat $ENTROPY_FILE) -lt $ENTROPY_THRESHOLD ]; do
        msg_info "Waiting for entropy"
        sleep 1
done

und zeigt für mich zwei Punkte:

1. AVM verwendet ab jetzt bei den GRX-Boxen die Hardware-Unterstützung für Verschlüsselung und zwar offensichtlich als LKM-Kombi ( eip123.ko und eip123_hw.ko in /lib/modules/$(uname -a)/extras).

2. AVM initialisiert jetzt tatsächlich ganz am Beginn des Bootprozesses (man sieht im ersten Code-Kasten ja, daß das direkt nach den "basics" erfolgt, sowie überhaupt das Dateisystem einigermaßen komplett initialisiert ist samt "tmpfs") den Zufallszahlengenerator im Linux-Kernel (LRNG) und zwar über die Hardware-Funktionen der DEU - ansonsten würde sich aus der Schleife mit dem "sleep 1" ja kein Entropie-Zuwachs ergeben, weil nichts weiter läuft oder gestartet wird. Der Bootvorgang wird erst dann fortgesetzt, wenn genug Entropy vorhanden ist (hier 896 Bit = 112 Byte). Damit hat sich meine "Spekulation" in #8 ja dann weitgehend erledigt bzw. es hat sich wohl sogar bestätigt, daß AVM da etwas unternommen hat.

Damit steigt für mich auch die Wahrscheinlichkeit, daß AVM die Hardware für VPN-Verbindungen nutzt und nicht nur zum Generieren von Zufallszahlen und Keys. Das könnte den IPSec-Durchsatz bei GRX-Boxen deutlich steigern ... ich bin mal gespannt, ob das etwas ausmacht und wenn ja, wieviel. Es könnte jedenfalls für manchen dann auch ein Argument sein, so manche 7490 zugunsten von GRX-Boxen (irgendwann wird es auch mal eine GRX750-Box von AVM geben, vermute ich zumindest) zu entsorgen ... vielleicht sinken damit ja die Gebrauchtpreise der 7490 bald deutlich, wenn sich diese als "Bremsklotz" im VPN erweisen sollten.

EDIT: Für die ganz aufmerksamen Leser ... uname -a ist oben natürlich Quark, da müßte ein uname -r stehen.

 

[PeterPawn]

Ich bin ja echt mal gespannt, was das mit der SMB-Unterstützung in der Firmware wird.

Das ist ja (mit ziemlicher Sicherheit) ein Zukauf von YNQ (https://www.visualitynq.com/products/ynq) und die reklamieren immerhin für sich:

YNQ™ runs in millions of embedded devices such as scanners, printers, home routers, mobile devices, X-ray machines, automation devices, automotive, aerospace and defense and virtually any device that is required to perform full file sharing functions in a Microsoft Windows networking environment.

auf ihrer Website.

Dort gibt es zwar auch noch "NQ Storage" (https://www.visualitynq.com/products/nq-storage), aber das "erbt" seine Technologie ja nach den eigenen Worten ebenfalls von YNQ und ausgehend von der Beschreibung der "Zielgruppe" für NQ Storage und basierend auf der Zeichenfolge "YNQ %d.%d.%d" im "nqcs"-Daemon in der AVM-Firmware, bleibe ich bei der Annahme, es handele sich um YNQ - also der "kleine Bruder" von NQ Storage, was den "standalone server" für SMB anbelangt.

Schaut man sich jetzt an, welche Aufstände AVM offenbar treibt (vielleicht ja sogar treiben muß?), um das Zeug halbwegs sicher/sinnvoll/stabil in die Firmware zu bekommen, fragt man sich ja unwillkürlich, ob da bei den "X-ray machines" oder den "aerospace and defense devices" keine mit MIPS-Architektur und basierend auf einem "stinknormalen" Linux-Kernel dabei sind (YNQ soll ja auch jede Menge anderer OS unterstützen, darunter auch "real-time OS" - RTOS - wie VxWorks oder QNX) bzw. angesichts der "Vorkehrungen" seitens AVM hofft man das fast inständig.

Denn AVM hat für "nqcs" ja nicht nur AppArmor in die Firmware aufgenommen (womit die Rechte, die sich ein erfolgreicher(!) Angreifer auf den SMB-Stack verschaffen könnte, per se schon mal eingedämmt werden können - ebenso vermindert man die Auswirkungen eines amoklaufenden Daemons, wenn man seine Zugriffsrechte auf Teile des System einschränkt) ... man hat in diesen Daemon auch noch einen zusätzlichen Thread zur Überwachung eingebaut (crashwatcher). Wenn der Name hier Programm ist und der eigentliche SMB-Server so oft das Zeitliche segnet, daß es diese Krücke braucht (ich habe noch keinen Absturz gesehen, aber auch noch keinen echten Streß gemacht), dann würde das zumindest auch erklären, warum AVM den in der vorherigen FRITZ!OS-Version lieber nicht veröffentlichte.

Nun wäre es zwar ohnehin blauäugig zu vermuten, daß eine "closed source"-Software per se sicher sein sollte ... es gibt genug Gegenbeispiele. Selbst von extrem vielen Firmen "nachgenutzte" Software (z.B. alles das, was auf Tuya (https://en.tuya.com/) basiert bei der Home-Automatisierung oder auch GoAhead (https://www.embedthis.com/goahead/), ein Webserver, der sich bei IP-Kameras besonderer Beliebtheit erfreut und auch immer wieder Security-Schlagzeilen macht) hat immer wieder ihre Probleme und wenn man sich das Portfolio des Herstellers von YNQ so ansieht, fällt ja auch schnell auf, daß der zwar für sein YNQ immer von "fully complies with x,y,z standards" redet, aber von "secure design" oder "security" ist auf der gesamten Web-Page (außer rechts in irgendwelchen "hot news") nie die Rede.

Außerdem ist der "standalone server" nur ein Teil des YNQ-Produkts und vielen der "Verwender" reicht in irgendwelchen Geräten eben auch ein Client (z.B. wenn ein Scanner irgendwelche erzeugten Dateien auf einem Windows-PC sichern soll, denn da ist der PC ja der "Server" - oder auch, wenn ein Media-Player Dateien von einer SMB-Freigabe wiedergeben soll). Das schränkt dann die "millions of devices", auf denen der verwendet wird als "standalone server", auch schon wieder ein.

Und last, but not least ... es ist ja nun auch nicht so, daß der Anbieter dieser Software ausschließlich auf C-Programmierung und Software für solche "embedded devices" (mit möglichst kleinem Footprint) spezialisiert wäre (was ja meist mit einem tieferen Verständnis einer Sprache/Technologie verbunden ist, als bei "querbeet"-Programmierung durch den Praktikanten - damit kennt man dann irgendwann auch die "sicheren Konstrukte" einer Sprache und weiß sie zu verwenden) ... da gibt es den SMB-Client auch noch mal in Java (aber wohl keinen Server) und eben den "NQ Storage". Letzterer wird zwar vermutlich auch auf C basieren (wenn der seine Fähigkeiten schon aus YNQ "inherited" nach der Beschreibung), aber es handelt sich wohl doch um ein eigenständiges Produkt und damit vermutlich auch um eigenständige Quellen.

Wenn dann der Anbieter mehr Aufwand in die Entwicklung von NQ Storage als Server und YNQ als Client steckt (wobei die Java-Variante jNQ eben für Geräte auf Android-Basis auch noch paßt, z.B. irgendwelche Fernseher mit Android und Media-Player, die von SMB-Freigaben lesen können), dann wäre es praktisch "normal", wenn dieses YNQ als "Server" gar nicht sooo oft eingesetzt wird, wie es die Webseite behauptet ... man muß ja ohnehin die "Selbstbeweihräucherung" bei der Produktbeschreibung noch abziehen.

Summa summarum ... ich bin einerseits skeptisch und andererseits neugierig, wie sich das mit dem SMB-Support entwickelt bei AVM. Ich hätte niemals gedacht, daß AVM für ein zugekauftes Produkt sogar hingeht und AppArmor in den Kernel aufnimmt - aber man sieht/sah wohl keine andere Möglichkeit.

Ich würde ja (persönlich) sehr gut auf SMB-Support verzichten können ... wenn die Firmware einen vernünftigen WebDAV-Server anbieten würde, kämen heutzutage praktisch auch fast alle anderen Geräte (inkl. Windows-PCs) als Client damit klar (der Rest spricht dann auch noch FTP oder UPnP/DLNA).

Leider gibt es da keine Software (weder "free" noch "commercial"), die für "embedded devices" tauglich wäre und am besten noch in C geschrieben wurde (neon (http://www.webdav.org/neon/) deckt praktisch auch nur die Client-Seite ab) - ich wüßte jedenfalls keine und hatte vor längerer Zeit mal dahingehend recherchiert (vielleicht auch nicht gründlich genug, wenn doch jemand eine kennen sollte) ohne verwertbares Ergebnis.

Vielleicht ist es ja an der Zeit, daß mal jemand eine solche schreibt ("antfs" hat AVM ja auch umgesetzt auf Basis von NTFS-3G) und die vielleicht sogar noch unter eine passende Lizenz stellt (oder gg. Gebühr lizensiert an Interessenten). WebDAV kann man jedenfalls sogar problemlos über TLS-Verbindungen im Internet verwenden ... bei SMB braucht es schon mehr "Expertise" für eine sichere Konfiguration einer "WAN-Installation" und deutlich mehr Aufwand (bis hin zu Kerberos und AD) - am Ende kriegt man auch "Features" mit beim SMB-Protokoll in Version 3, die man für so eine FRITZ!Box eigentlich gar nicht braucht.

 

[hermann72pb]

@PeterPawn: Um deinen Monolog hier ein bisschen zu unterbrechen... Ja, mit 7490 und mit dem eingebauten VPN-Server kann ich es bestätigen, dass die Box da schon an ihre Grenzen kommt, wenn man VPN mächtig nutzt und parallel versucht per VOIP zu telefonieren. Man hört es schon an den Aussetzern in der Telefonie. Ich habe so eine Box produktiv im Einsatz und ausnahmsweise für mich ohne FREETZ, weil in dem speziellen Fall die Box tatsächlch schon etwas mehr mit ihren Grundfunktionen (Telefonie, VPN, Routing) zu kämpfen hat, sodass ich ihr aus Stabilitätsgründen nicht zugetraut hatte, dass da noch FREETZ parallel läuft. Von daher wäre es schon ein Grund in dem Falle von einer 7490 zu einer 7590 zu wechseln. Dass dies jetzt generell zu einem Trend wird, glaube ich aber nicht. Denn die interne VPN-Lösung von AVM ist derzeit alles andere als Selbstläufer: Der AVM-eigener Client funktioniert mit WIN10 nicht, man muss schon auf die Drittanbieter-Lösung zurückgreifen. Die von AVM als Standard vorgeschlagene Konfiguration kann man eigentlich auch vergessen. Man muss schon sehr viel im Vorfeld LESEN, um das Ding vernünftig zum Laufen zu bekommen. Ich behaupte mal, dass 95% der heutigen Fritz!Box-Nutzer es kaum mehr zum Laufen bekommt, bzw. keine Ausdauer haben wird, es sich anzueignen. Von daher sehe ich den Anteil der wirklichen Nutzer der AVM-VPN-Lösung heutzutage als sehr gering.
Bzgl. SMB ist natürlich eine interessante Beobachtung. Und auch hier stimme ich dir bzgl. Fehleranfälligkeit von "closed source" nur zu. Entgegen der allgemeinen Meinung (vor allem im Management-Kreisen), dass man sich durch das Geld die Stabilität gegenüber "diesem Bastel-OSS-Kram" kauft, stimmt das nur bedingt. Und ich kenne auch einige Beispiele aus meinem beruflichen Umfeld, wo dies nachweislich wiederlegt wurde. Nun jetzt meine Frage als Nicht-IT-Fachman an dich, der das auch beruflich macht: Warum tut AVM das? Ist es die allgemeine Angst gegen die OSS? Aber damit sind sie doch über die Jahre gut gefahren und haben auch gut Geld verdient. Was stört sie an dem Geschäftsmodell?

MfG

 

[PeterPawn]

Warum tut AVM das?

Wenn ich das wüßte ... bei SMB denke ich mal, daß die neueren Samba-Versionen die Ressourcen einer FRITZ!Box zu sehr belasten würden (das sind eben keine "richtigen Computer", nicht mal verglichen mit vielen Einplatinen-Rechnern auf ARM-Basis).

Da die auch ab und an mal ihre Probleme haben, war der Antrieb bei AVM wohl nicht vorhanden (solange MS SMBv1 noch unterstützte) und außerdem konnte AVM in letzter Zeit immer mal wieder betonen, daß FRITZ!OS von Samba-Fehlern nicht betroffen ist (https://avm.de/service/aktuelle-sicherheitshinweise/), weil die bekanntgewordenen Probleme fast immer Teile betrafen, die in der uralten Version, die AVM verwendet(e), noch gar nicht implementiert waren. Wenn ohnehin alle Welt Samba 4 einsetzt, sucht ja auch fast niemand mehr nach Problemen in Samba 3 (AVM verwendet bis heute 3.0.37).

Seitdem MS nun Ernst macht und SMBv1 wg. bekannter Schwächen in den Windows-Clients deaktiviert, muß AVM halt irgendwie reagieren. Eine "volle" Samba4-Installation braucht eine FRITZ!Box erstens nicht (die muß sich in keine Windows-Domäne und kein Active-Directory integrieren lassen) und zweitens würde die wohl eben (s.o.) die meisten Boxen ziemlich belasten im Hinblick auf den Ressourcenverbrauch.

Wenn man dann auch noch berücksichtigt, daß AVM schon bei der bisher eingesetzten Samba-Version heftig an den Quellen geändert hatte (schon um da die eigene Rechteverwaltung aus der "libavmacl2.so" anzudocken und ebenso, um nicht benötigte Samba-Funktionen gar nicht erst bereitzustellen, wo sich diese nicht einfach durch Konfigurationseinstellungen beim Build deaktivieren lassen), dann verstehe ich schon, daß man diesen Aufwand für neuere Samba-Versionen nicht wiederholen wollte ... zumal man auch dafür wieder die geänderten Quellen veröffentlichen müßte (was dann andere Hersteller problemlos nachnutzen dürften) und damit tut sich AVM (nach meinem Empfinden und für mich auch nur schwer nachvollziehbar - man profitiert ja auch von dieser Software) wohl schon immer schwer.

Es brauchte ja (soweit ich das "aus der Geschichte" kenne) auch erst den (Zivil-)Prozess zwischen AVM und Cybits (den allerdings AVM angestrengt hatte), um bei AVM das Verständnis dafür zu wecken, daß es (a) OpenSource-Lizenzen gibt und man sich als Lizenznehmer dann (b) auch an deren Bestimmungen zu halten hat und es sich bei der AVM-Firmware in der vorliegenden Form zwar um ein "Sammelwerk" nach §4 UrhG handelt (das hat das Gericht bejaht), an dem man trotzdem nicht alle Rechte ausschließlich hält und damit auf die Rechte anderer Rücksicht nehmen muß (das AVM-Ansinnen dahingehend wurde verworfen und festgehalten, daß die GPL-Bestimmungen Gültigkeit haben - "Danach stehen der Klägenn an der Firmware als Ganzes - und so sind ihre Anträge zu verstehen - keine urheberrechtlichen Unterlassungsansprüche zu.", LG Berlin, Az. 16 O 255/10 vom 08.11.2011).

Ich wüßte jedenfalls nicht, daß AVM vor dem Urteil irgendwie bereit gewesen wäre (und zwar jenseits eines "Psst, hast Du schon gehört/gelesen/bemerkt, daß ..." durch irgendwelche "Whistleblower" unter den Mitarbeitern), die von dieser Firma geänderten Quellen für die Pakete, deren Lizenzbestimmungen das fordern, auch tatsächlich zu veröffentlichen (und nicht nur irgendetwas dazu in irgendwelchen Text-Dateien zu schreiben, wie das "theoretisch" wäre).

Auch die frühere Ansicht seitens AVM, man dürfe von AVM bereitgestellte Firmware-Images für die FRITZ!Boxen nicht selbst weiterverbreiten (auch an das IPPF erging ja offensichtlich eine solche Forderung, wie man heute noch in alten Threads nachlesen kann), brauchte ja erst diese "Klarstellung" und heute würde wohl keiner mehr auf die Idee kommen, die Verbreitung der (unveränderten) AVM-Images (für das FRITZ!OS, ich rede hier nicht von Firmware für Zubehör, das ggf. keine Software mit solchen Lizenzen verwendet) wäre ein Copyright-Verstoß (heute ist das nur noch Verschwendung von Speicherplatz und Bandbreite, wenn ständig Leute auf der Suche nach alten Versionen sind, weil sie nicht wissen, wie sie seit 06.5x irgendetwas installieren sollen).

Nun kann man halt nur spekulieren, wo AVM am Ende hin will ... ich wäre nicht einmal besonders überrascht, wenn man dort auch Experimente mit anderen OS (z.B. QNX Neutrino oder einem BSD-Derivat) angestellt hätte. Nur stellen die meisten SoC-Hersteller eben für ihre Chipsets in erster Linie die Patches für Linux-Versionen bereit (schon bei BSD ist das m.W. nicht häufig der Fall) und der Aufwand, diese Patches selbst auf ein ansonsten nicht vom SoC-Hersteller unterstütztes OS zu übertragen, dürfte auch deutlich höher liegen, als es AVM stemmen könnte, wenn man ständig neue Chipsets "ausprobiert" in der eigenen Produktpalette.

Es macht ja auch wenig Sinn ... besser ist es immer, man konzentriert sich auf das eigene "Kerngeschäft" und das war/ist bei AVM wohl deren "Multi-Protocol Router"-Stack, der schon zu ISDN-Zeiten entwickelt und dann ständig erweitert wurde (das dürfte heute noch der Kern des "kdsldmod" sein) - zusammen mit den Telefonie-Funktionen, die ja ebenfalls proprietär sind, während andere Hersteller dann auch mal Asterisk einsetzen. Irgendwann kam dann wohl noch die "Smarthome-Idee" als weiteres Standbein dazu und zum "Vermeshen" der Geräte wurde AVM ja auch eher von den Entwicklungen der Konkurrenz gezwungen.

Da verstehe ich schon, wenn man keine Kraft in die Entwicklung eines eigenen SMB-Stacks stecken will (und auch ein für AVM angepaßtes Samba 4 fiele für mich in diese Kategorie) ... und das Angebot an (funktionierenden und heute noch verfügbaren, sowie die neueren Versionen unterstützenden) kommerziellen Lösungen ist an dieser Stelle auch nicht wirklich üppig: https://en.wikipedia.org/wiki/List_of_products_that_support_SMB

Ich kann mir also auch gut vorstellen, daß AVM da schon eine (bestimmt nicht billige) Lizenz erworben hat(te) (der Lizenzgeber wird sonst kaum der Veröffentlichung im Rahmen von Labor-Versionen der früheren Reihen zugestimmt haben) und die tatsächlichen Probleme "in the wild" wurden wohl erst danach bemerkt - denn man hat ja auch damals schon ziemlich damit getrommelt, daß FRITZ!OS nun endlich SMBv2+ unterstützen sollte.

Aber selbst wenn man sich wg. Problemen für ein anderes (Vor-)Produkt entscheiden wollte ... der Markt ist da nicht so üppig und die Konkurrenz nicht wirklich groß. Andere Hersteller setzen halt auf Samba und haben kein Problem damit, daß es sich dabei um "GPL software" handelt (weil sie es auch weitgehend ungeändert verwenden) ... der Hersteller von YNQ betont ja ausdrücklich auf seiner Home-Page den Stolz darauf, daß das bei seiner Software gerade nicht der Fall wäre.

Bei einem anderen Hersteller als AVM, wo es ansonsten außer Samba keine weitere GPL-Software gäbe, würde ich diesen Umstand (nicht-GPL-Software) auch noch auf der "Haben"-Seite verbuchen ... aber wenn AVM alles das "rauswerfen" wollte, was in der Firmware GPL-lizensiert ist (selbst wenn jetzt die C-Library bei den GRX-Boxen wohl auf "musl" unter MIT-Lizenz wechselt, bleibt noch genug anderes übrig, bis hin zum Kernel und der BusyBox), würde nach dem "Alles raustreten ..." das FRITZ!OS in sich zusammenbrechen.

Andere Hersteller haben es da aber auch (bei den meisten Geräten) etwas leichter ... das sollte man m.E. auch nicht aus den Augen verlieren. Wenn so ein SOHO-Router ansonsten nichts weiter zu tun hat, als ein paar Netzwerk-Pakete zwischen einem LAN und dem Internet hin und her zu schaufeln, dann bleiben da sicherlich auch noch genug Reserven, um auch mal Samba 4 für den SMB-Support zu verwenden. Aber eine FRITZ!Box "im Vollausbau" hat eben noch alle möglichen anderen Aufgaben (das kann man mögen und feiern oder auch nicht) und wenn Samba 4 dann zu Problemen bei der Telefonie führt, finden das die Kunden wohl weniger witzig.

Wenn AVM hier nicht auf unterschiedliche Lösungen setzen will (eine große für die "kleinen" und eine eher kleine für die "großen" Boxen), kann man das sicherlich nachvollziehen ... und wenn die Boxen mit ausreichenden Reserven wg. vieler anderer fehlender Funktionen dann am Ende den einzig vernünftig funktionierenden SMB-Server hätten, wäre das wohl auch nicht wirklich hilfreich für den Ruf der Boxen.

Wie gesagt ... ich hätte da tatsächlich komplett auf SMB-Support verzichtet und stattdessen auf WebDAV gesetzt - das ist ebenfalls ein erprobtes Protokoll (beim Online-Speicher verwendet AVM es ja selbst, wenn auch die Client-Seite - wobei auch hier wieder umfangreiche Anpassungen am originalen Source-Code vorgenommen wurden und man daher auch dort nicht immer direkt auf neuere Versionen umsteigen kann durch Ersetzen der "Basis-Version") und dient auch bei vielen anderen Funktionen zum Datenaustausch als "Grundlage" ... nicht zuletzt ist es auch in verschiedenen RFCs gut spezifiziert (http://www.webdav.org/specs/), so daß immer seltener Probleme bei der Interoperabilität (I14Y) auftreten.

AVM hat halt viele eigene Erweiterungen/Ersetzungen in der Firmware ... und die fallen einem dann auf die Füße, wenn man - wie hier beim SMBv2/v3-Support - nicht länger mit den alten Versionen arbeiten kann und nun neuere Versionen erst wieder anpassen müßte ... zumindest da, wo die verwendete Software nicht selbst die "Hooks" zum "Customizing" durch einen Hersteller bereithält.

Auch rächt es sich jetzt vielleicht, daß da eben nicht immer die kompletten Funktionen "ausgelagert" wurden in AVM-geschriebenen Code, sondern der vorhandene Code "irgendwie" verändert wurde (jedenfalls bei dem, was man sehen kann, weil AVM die Quellen veröffentlichen muß). Wer in fremdem Code alle paar Zeilen eine eigene Änderung einfügen will oder muß, der hat praktisch bei jeder neuen Version auch das Risiko, daß sein eigener Patch nicht mehr paßt, weil es sich verschoben hat und "Anker-Zeilen" sich geändert haben. Wer hingegen die fragliche Funktion komplett in eine eigene Datei auslagert und dort ändert und erst beim Linken dafür sorgt, daß anstelle der "originalen" nunmehr seine eigene Funktion verwendet wird, der hat manchmal weniger Kopfschmerzen (oder zumindest andere).

Bei AVM sieht man häufig einen "Mischmasch" aus diesen beiden Strategien - der "ftpd" aus den "inetutils" ist ein Paradebeispiel in dieser Hinsicht. Es gibt "ausgelagerte Funktionen" (z.B. alles das, was in der "usermap.c" steht) und trotzdem wurde auch in der "ftpd.c" heftig geändert - das geht soweit, daß man als Leser der Quellen gar nicht mehr einschätzen kann (ohne den Vergleich mit den originalen Quellen, die man auch nicht mehr ohne weiteres findet), wo AVM nun geändert hat und wo nicht. Denn die AVM-Änderungen liegen eben nur selten als Patch-Files für originale Quellen vor (das gilt auch für Samba 3.0.37) ... zumindest bei dem, was man der Öffentlichkeit so anbietet.

Wenn das auch für "AVM intern" so sein sollte, kann ich auch wieder verstehen, daß wohl kaum jemand das Bedürfnis hat, die jeweiligen Basis-Programme auch regelmäßig zu aktualisieren, wenn es dort neue Versionen gibt.

Wenn dann ein Projekt bei seiner Software eine ähnliche "Informationspolitik" fährt, wie es AVM macht ("Wir empfehlen die Installation jedes Updates, sicherheitsrelevante Änderungen werden von uns nicht gesondert ausgewiesen."), dann muß man sich auch nicht wundern, wenn irgendwelche Patches, die in freier Wildbahn lange integriert wurden, bei AVM noch nicht enthalten sind bzw. es lange braucht, bis diese Änderungen Einzug in neue Firmware halten.

Ein Beispiel hier wäre WPA2-KRACK - auch dort hat AVM ja eigene Änderungen am "hostapd" und "wpa_supplicant" vorgenommen, wobei sie diese Änderungen aufgrund der Lizenz (BSD) nicht veröffentlichen müssen (was sie dann natürlich auch nicht tun) ... somit bleibt man hier auf die "Gnade" von AVM hinsichtlich der Korrektur von Security-Problemen angewiesen.

Glücklicherweise gibt es nicht soo viele OSS-Projekte mit derselben Informationspolitik, wie sie von AVM betrieben wird (zumal man sich dort ja die Änderungen meist ohnehin ansehen könnte, wenn das eben "open source" ist) ... das ändert aber nichts daran, daß bei AVM hinsichtlich der Änderungen an einigen ur-ur-uralten Programmpaketen offenbar häufig auch das "Prinzip Hoffnung" gilt. Wobei man bei den meisten der verwendeten Pakete nicht mal mehr richtig nachvollziehen kann, auf welchem Patch-Stand die nun tatsächlich sind ... eben auch, weil AVM nur die geänderten Dateien bereitstellt und nicht Original plus Patch (die "AVM-Version" könnte man sich dann ja selbst erstellen aus diesen Dateien).

Zwar ist es auch tatsächlich nur dieses, wozu sie die Lizenzbestimmungen verpflichten ... aber wenn die interne Organisation dort tatsächlich die sein sollte, die man aus den Veröffentlichungen ablesen kann, dann gute Nacht.

Da ist man dann bei anderen Herstellern, wo man weiß, daß die ihre Firmware nach 1-2 Jahren gar nicht mehr pflegen, fast schon wieder besser dran (ja, das ist vielleicht etwas übertrieben, aber nicht vollkommen falsch) ... denn damit muß man nicht "raten", ob eine Firmware jetzt die Änderungen für dieses oder jenes Problem auch enthält. Wenn es keine neue gibt, kann die auch keine Korrekturen enthalten, die nach ihrem Erscheinen erst notwendig/bekannt wurden - bei AVM bleibt einem i.d.R. (oder zumindest deutlich zu häufig, auch wenn die Beschreibungen der Änderungen in den Labor-Versionen detaillierter zu werden scheinen) auch nur die Hoffnung, daß AVM tatsächlich die bekanntgewordenen Probleme auch in den "angepaßten" Programmpaketen beseitigt hat.

Das sind jedenfalls meine Eindrücke und die Gedanken zur Verwendung von OpenSource-Software bei AVM, die ich mir so mache ... zwar ist die AVM-Firmware z.T. auch wg. solcher Änderungen so beliebt, weil sie manches vereinfachen, gleichzeitig hat sich AVM damit aber m.E. auch selbst ins Knie geschossen, wenn es darum geht, Vorhandenes durch Neueres oder gar Besseres zu ersetzen.

Wobei auch da vielleicht ein Wechsel der "Denkrichtung" stattgefunden hat (ob gezwungenermaßen oder freiwillig, lasse ich jetzt mal dahingestellt, falls mein Eindruck überhaupt richtig sein sollte) ... man braucht nur mal überlegen, wie lange bei AVM noch Kernel auf der Basis einer 2.6-Version "up to date" waren und wie lange es dauerte, bis der erste Schritt zu (einem damals auch schon angegrauten) Kernel 3.10 vollzogen wurde. Da kam der Sprung auf 4.9.198 bei der 7590 ja jetzt schon einigermaßen überraschend ... wenn sich AVM damit nicht nur "Ruhe für die nächsten Jahre" erkaufen will, wäre das ja schon ein beachtlicher Wechsel in der "Update-Philosophie" für die verwendeten Programmpakete.

Das gilt vom Kernel über die C-Library bis zum Compiler, wobei man mal abwarten muß, ob das auch für anderes so fortgeschrieben wird. Bei OpenSSL ist AVM inzwischen ja auch einigermaßen hinterher und aktuell (auch das hat ja Jahre gedauert, bis man sich - gezwungenermaßen - von 0.9.8 verabschiedete) ... wie das bei weniger "augenfälligen" Paketen am Ende ist, wird die Zeit zeigen. "hostapd" ist z.B. seit August 2019 bei Version 2.9, AVM verwendet in 07.19 weiterhin Version 2.7-devel und das ist die erste, in der WPA2-KRACK gefixt wurde (die erschien dann offiziell im Dez. 2018) - die Änderungen seitdem (Changelog: https://w1.fi/cgit/hostap/plain/hostapd/ChangeLog) haben für AVM wohl keine Relevanz (und schon die ständige Neubewertung einer solchen Einschätzung bindet Ressourcen).

 

[hermann72pb]

@PeterPawn Danke! So ausführlich wäre es aber nicht nötig gewesen...
Bzgl. ftpd kann ich dir nur zustimmen. Ich hatte mich mal vor mehreren Jahren hier damit ein wenig beschäftigt. Mir wurde damals erklärt, dass ftpd keine Eigenentwicklung von AVM ist, sondern eben diese Abwanderung vom besagten OSS-Projekt, allerdings so stark kastriert und vergewaltigt, dass man es kaum mehr erkennen konnte. Da ich auch damals nicht besonders stark im Patchen fremder Sourcen war (wo AVM offensichtlich sich zuhause fühlt), hatte damals Oliver mir geholfen, den ftpd irgendwie in Richtung Originalpaket zu führen. Wir sind aber damals damit kräftigt gescheitert, weil genau das da vorzufinden war, was du beschreibst: Änderungen an diversen Stellen und in diversen Dateien, wo man es gar nicht erwartet. Zu dem Zeitpunkt gab es in FREETZ zwei weitere FTP-Server, sodass ich irgendwann mal Richtung VSFTP dann vollständig gewandert bin und meine Bedürfnisse damit dann erfüllt hatte. Ich hatte noch versucht, eine umschaltbare FTP-Server-Hülle damals zu bauen, dass man quasi den AVM-FTPD durch VSFTP oder BFTP ersetzen könnte, sodass der AVM-Restkramm denken würde, es wäre deren eigener FTP-Server, obwohl es in Wirklichkeit einer von FREETZ wäre. Diese Bestrebung hat aber leider kein breites Interesse hier in IPPF gefunden. Danach hat AVM deren FTPD mit dem SAMBA, Mediaserver, WeDAV usw. so eng "verheiratet", dass man kaum mehr hinterher laufen konnte. Den FTPD hatten sie auch relativ früh an INETD angehängt, aber natürlich auf die perverseste Art und Weise, wie es nur AVM tun kan, sodass es mit dem ursprünglichen inetd-Gedanken und der Modualrität gar nicht mehr zu tun hatte... Das waren noch die Zeiten...
Bzgl. OSS, anderer Routerhersteller und Co. Ich gebe dir Recht, dass man bei den meisten Taiwanesen und Chinesen wohl davon ausgeht, dass sie höchstens 1-2 Jahre ihre Router, Switches, WebCams (und was auch alles immer noch gibts) unterstützen und dann ist "Ende der Veranstaltung". Das ist konsequent, obwohl natürlich ärgerlich. Bei AVM hat man wahrscheinlich noch die alte deutsche Mentalität zumindest bei den "Mainstream"-Produkten 7270->7390->7490->7590. Man will sie irgendwie möglichst lange am Leben halten. Aber auch das tut man natürlich seitens AVM auch nicht so wirklich oder zumindest nicht transparent genug. Das stimmt schon. Dennoch kann ich auch hier einen Paradebeispiel von meinem heutigen Kampf gegen meine "managed" D-Link-Switches bringen: Ich hatte heute den halben Tag in den Sand gesetzt, um deren Web-Interface halbwegs https-fähig hinzukriegen. Es geht nur mit den veralteten 128-bit Zertifikaten und auch das in einer spezieller Form. Alles undokumentiert, versteht sich. Von daher sind da unsere AVM-Freunde schon fast die "Streber" im Vergleich zu diesen "konsequenten" Kollegen aus dem Fernosten.
Bzgl. SAMBA auf der Box. Ich bin auch der Meinung, dass SAMBA auf der Box (so wie AVM den Router nun definiert) wenig verloren hat. Wer will, kann seine SAMBA-Zentralle mit einem NAS realisieren, oder sich einen RaspberryPi oder noch besser Odroid (und andere) dafür zulegen. WebDAV oder FTP (mit SSL natürlich) würden für den Datenaustausch mit der Box eigentlich ausreichen.

MfG

 

[PeterPawn]

Ich habe immer noch die Hoffnung, daß mit dem Einbau der Benutzung der Crypto-Hardware in die AVM-Firmware auch andere Entwicklungen als nur VPN davon profitieren.

Schon für die Encryption (ja, selbst für das Signieren) von Datenpaketen bei SMB3 braucht ja das OS entsprechende Ressourcen, das gilt natürlich genauso für die andere, "sichere" Kommunikation im LAN, angefangen bei TLS-Pflicht(!) für das GUI über TLS-Support auch bei internem FTP (ich weiß gerade gar nicht, ob das intern überhaupt unterstützt wird, wenn es für externe Verbindungen aktiviert wurde) bis hin zur Frage, ob WebDAV-Dateitransfers nun mit oder ohne TLS ablaufen sollten.

Beim GUI sind Datenmengen und Frequenz von Requests sicherlich noch nicht kritisch (und über die WAN-Verbindung ist da die Verschlüsselung natürlich auch unverzichtbar) ... aber wenn es um größere Datentransfers im LAN geht (angefangen beim Abspielen von Videos vom FTP-Server der FRITZ!Box), dann braucht eben eine gesicherte Übertragung praktisch dieselben Ressourcen, wie eine VPN-Verbindung und daß die FRITZ!Boxen da (in der derzeitigen Implementierung) "under-performer" sind, ist ein offenes (und oft auch von Vergleichstests herausgestelltes) "Geheimnis" (sie haben eben auch zuviele Aufgaben gleichzeitig für die vorhandene Hardware, wenn man die "spezialisierten Hardware-Einheiten" nicht nutzt, weil sie ggf. nicht in allen SoC vorhanden sind).

Daher habe ich ein klein wenig Verständnis dafür, daß AVM das mit der sicheren Datenübertragung im LAN bisher nicht so richtig ernst nimmt (mal abgesehen vom GUI, wo der "Overhead" nach meiner Ansicht den Gewinn an Sicherheit wert wäre) ... nur sollte man dann eben - anstatt sich irgendwelche neuen Features auszudenken - irgendwann auch mal "konsolidieren" und das, was - gerade aus Sicht der Kunden - bisher mehr "suboptimal" implementiert wurde, von eher tönernen auf massive und tragfähige Füße stellen ... da gehört die Nutzung der DEU bei GRX-Boxen für mich dazu.

Es gibt immer mehr Geräte in den (W)LANs, die ihrerseits ein Risiko für andere LAN-Teilnehmer darstellen (nur ein aktuelles Beispiel: https://www.heise.de/ratgeber/Gegen...nd-Kamera-im-Netzwerk-belauschen-4617092.html - ich kenne zwar den Inhalt nicht wirklich, weil das hinter einer Paywall liegt und ich mich der verweigere, aber ich kann mir vorstellen, was man gefunden hat) und da sollte man als Hersteller des Routers als zentrales Element in den allermeisten Heimnetzen in D dann eher mit gutem Beispiel - gerade in puncto Sicherheit - vorangehen und nicht erst dann reagieren, wenn es unumgänglich wird, weil es (aktive) Angriffe auf die eigenen Modelle gibt. FRITZ!Boxen sind zwar schon einigermaßen sicher (gerade auch im Vergleich zu Konkurrenzprodukten), aber es gibt keinen Grund, sich auszuruhen und abzuwarten, bis das Kind das nächste Mal in den Brunnen geworfen wurde.

Wobei die Neuentwicklungen sich bei der 07.19 nach meinem Eindruck auf das Notwendige beschränken (um weiterhin "modern" zu bleiben - durchaus auch beim Angebot "zusätzlicher" Sicherheit) und ich die Punkte so zusammenfassen würde:

• DNS over TLS
• SRTP/SIPS (für ausgewählte Anbieter)
• WPA3
• CardDAV-Support
• SMB2/SMB3-Support
• Mehrsprachigkeit

Der Rest sind für mich Detailverbesserungen bzw. (überfällige) Nacharbeiten bei bereits umgesetzten Features ... interessant finde ich allerdings die Entwicklung, die vor 14 Tagen einsetzte (oder zumindest da das erste Mal ans "Licht der Öffentlichkeit" trat).

Das Zusammenlegen der "rein deutschen" und der internationalen Firmware-Versionen spart sicherlich auch bei AVM etwas Aufwand ein (von (automatisierten) Builds bis hin zur Manpower) und sorgt nicht nur bei den Kunden (die dann nicht länger mit verwirrenden Unterschieden in den Versionsnummern konfrontiert werden oder sich als Käufer der internationalen Modelle ärgern, daß sie "links liegengelassen werden") für mehr Übersichtlichkeit.

------------------------------------------------------------------------------------------------------------------------

Aber für die zusätzliche Sicherheit in Form von verschlüsselten Übertragungen braucht man eben auch zusätzliche Ressourcen oder doch den Hardware-Support in den SoCs (deren Hersteller bauen den ja auch nicht ein, obwohl es gar keinen richtigen Bedarf dafür gibt oder damit die Router-Hersteller diese Einheiten dann brachliegen lassen) und auch wenn weder DNS noch SIP oder RTP jetzt wirklich "große Datenmengen" produzieren, kann das bei SMB3 mit Encryption schon ganz anders aussehen ... und das unterstützt der SMB-Server offensichtlich auch (für SMB3-Compliance muß er das m.W. auch), denn mein Zugriffsversuch mit "smbclient -e -S required ..." auf eine 7490 mit 07.19 funktioniert (zunächst einmal) problemlos und das zeigt dann, daß hier Verschlüsselung erfolgreich ausgehandelt wurde:

vidar:/tmp/mget $ smbclient -U xxx -S required -e //fb7490/fb7490
Enter xxx/xxx's password:
Try "help" to get a list of possible commands.
smb: \> cd system/FB7490/firmware/
smb: \system\FB7490\firmware\> l *.image
  FRITZ.Box_7490_Labor.113.07.08-64272.image      N 33054720  Wed Dec 19 06:57:26 2018
  FRITZ.Box_7490_Labor.113.06.69-40416.image      N 26931200  Fri Jul 29 14:41:30 2016
  FRITZ.Box_7490_Labor.113.06.55-33668.image      N 25907200  Sun Jul  3 22:57:05 2016
  FRITZ.Box_7490_Labor.113.06.69-41137.image      N 26992640  Sat Sep 17 12:20:47 2016
  FRITZ.Box_7490-07.12.image          N 33228800  Wed Nov  6 22:56:44 2019
  FRITZ.Box_7490_Labor.113.06.51-32297.image      N 25733120  Sat Jun  4 17:17:56 2016
  FRITZ.Box_7490.113.06.51.image      N 25733120  Thu Feb  4 21:30:07 2016
  FRITZ.Box_7490_Labor.113.06.51-32225.image      N 25733120  Sat Jan 23 06:27:55 2016
  FRITZ.Box_7490.en-de-es-it-fr-pl.113.07.01.image      N 34048000  Thu Oct  4 18:21:56 2018
  FRITZ.Box_7490_Labor.113.06.69-41049.image      N 26982400  Sat Sep 10 15:49:13 2016
  FRITZ.Box_7490.113.06.93.image      N 27514880  Sat Sep 15 01:50:35 2018
  FRITZ.Box_7490_Labor.113.06.69-40766.image      N 26849280  Fri Aug 19 19:15:27 2016
  FRITZ.Box_7490-07.08-65155-Inhaus.image      N 33105920  Fri Feb  1 11:34:50 2019
  FRITZ.Box_7490_LabBETA.113.06.69-42111.image      N 27033600  Sun Nov 20 04:18:58 2016
  FRITZ.Box_7490_LabBETA.113.06.69-41875.image      N 27023360  Fri Nov  4 17:47:05 2016
  FRITZ.Box_7490_LabBETA.113.06.69-42246.image      N 27054080  Sun Nov 27 07:48:32 2016
  FRITZ.Box_7490_Labor.113.06.55-33192.image      N 25876480  Mon May 30 12:18:24 2016
  FRITZ.Box_7490_LabBETA.113.06.69-42372.image      N 27043840  Fri Dec  2 17:55:10 2016
  FRITZ.Box_7490_Labor.113.06.55-33529.image      N 25907200  Tue Jun 21 01:53:53 2016
  FRITZ.Box_7490.113.06.69-41123.image      N 27197440  Thu Sep 15 20:25:56 2016
  FRITZ.Box_7490-07.08-66226-LabBETA.image      N 33269760  Tue Mar  5 21:05:33 2019
  FRITZ.Box_7490_Labor.113.06.69-40520.image      N 26920960  Thu Aug  4 19:40:25 2016
  FRITZ.Box_7490_Labor.06.98-48630.image      N 28129280  Thu Dec 28 17:02:10 2017
  FRITZ.Box_7490.113.06.80.image      N 27054080  Mon Jan 23 18:35:00 2017
  FRITZ.Box_7490.113.06.69-41091.image      N 27207680  Wed Sep 14 14:18:57 2016
  FRITZ.Box_7490_Labor.113.06.55-33361.image      N 25907200  Sat Jun  4 06:32:38 2016
  FRITZ.Box_7490_LabBETA.113.06.69-41222.image      N 26992640  Sun Oct  2 17:20:39 2016
  FRITZ.Box_7490_Labor.113.06.69-40929.image      N 26869760  Fri Sep  9 08:53:53 2016
  FRITZ.Box_7490_BETA.113.07.03-65299.image      N 33310720  Thu Jan  1 01:40:27 1970
  FRITZ.Box_7490_Labor.113.06.55-33566.image      N 25907200  Thu Jun 23 17:58:27 2016
  FRITZ.Box_7490_LabBETA.113.06.69-41457.image      N 27013120  Wed Oct  5 17:11:15 2016
  FRITZ.Box_7490.113.07.01.image      N 33310720  Fri Sep 14 18:10:01 2018
  FRITZ.Box_7490-07.19-73513-Labor.image      N 35624960  Thu Nov 21 11:00:00 2019
  FRITZ.Box_7490.113.06.60.image      N 25907200  Wed Jul  6 22:46:21 2016
  FRITZ.Box_7490-07.08-66264-Inhaus.image      N 33515520  Tue Mar  5 21:06:36 2019
  FRITZ.Box_7490-07.19-72263-Inhaus.image      N 35440640  Thu Oct 17 01:34:44 2019
  FRITZ.Box_7490_LabBETA.113.06.36-31540.image      N 26050560  Mon Oct 12 14:41:11 2015
  FRITZ.Box_7490_BETA.113.06.35-30999_bkb.image      N 26634240  Thu Aug  6 12:32:34 2015
  FRITZ.Box_7490.113.06.30.image      N 24494080  Sun Feb  7 18:26:02 2016
  FRITZ.Box_7490_LabBETA.113.06.69-41556.image      N 27002880  Sat Oct 15 12:31:53 2016
  FRITZ.Box_7490_LabBETA.113.06.88-45942.image      N 27412480  Thu Aug 17 12:03:18 2017
  FRITZ.Box_7490_LabBETA.113.06.69-41670.image      N 26951680  Fri Nov  4 17:45:51 2016
  FRITZ.Box_7490_LabBETA.113.06.69-41137.image      N 26992640  Sat Sep 17 12:13:51 2016
  FRITZ.Box_7490-07.08-65776-LabBETA.image      N 33249280  Thu Feb 28 22:25:45 2019

                59162852 blocks of size 4096. 34034995 blocks available
smb: \system\FB7490\firmware\>

Ich nehme für Tests nun mal lieber den "smbclient" (Version 4.10.5-git.105.2bd98587873SUSE-oS15.5-x86_64 im Moment, falls das wichtig sein sollte), als irgendein Windows-System, weil das viel weniger parametrierbar und deutlich weniger "auskunftsfreudig" im Bezug auf die Details aufgetretener Fehler ist ... und die gibt es dann auch (zumindest bei Benutzung von ebendiesem "smbclient"-Aufruf - mit Verschlüsselung und Signieren - bei Übertragung einer Datei) umgehend:

smb: \system\FB7490\firmware\> get FRITZ.Box_7490-07.12.image
parallel_read returned NT_STATUS_IO_TIMEOUT
getting file \system\FB7490\firmware\FRITZ.Box_7490-07.12.image of size 33228800 as FRITZ.Box_7490-07.12.image smb2cli_req_compound_submit: Insufficient credits. 0 available, 1 needed
smb: \system\FB7490\firmware\> smb2cli_req_compound_submit: Insufficient credits. 0 available, 1 needed
smb2cli_req_compound_submit: Insufficient credits. 0 available, 1 needed
[...]
smb2cli_req_compound_submit: Insufficient credits. 0 available, 1 needed
^C

Dabei werden dann auch (unabhängig von der gewählten Ausgangsdatei) genau dieselben Datenmengen übertragen:

vidar:/tmp/mget $ ls -l *.image
-rw-r--r-- 1 peh users 1703936 Dec 23 13:19 FRITZ.Box_7490-07.12.image
-rw-r--r-- 1 peh users 1703936 Dec 23 13:16 FRITZ.Box_7490_Labor.113.07.08-64272.image

und schon diese ~1,5 MB (viel mehr ist das nicht) schaffen es dann, bei der 7490 einen der beiden Cores für längere Zeit (>20 Sekunden) in die "Sättigung" zu treiben:

Mem: 230480K used, 11664K free, 3616K shrd, 5720K buff, 139620K cached
CPU0:  40% usr  58% sys   0% nic   0% idle   0% io   0% irq   0% sirq
CPU1:   1% usr   1% sys   0% nic  96% idle   0% io   0% irq   0% sirq
Load average: 2.31 2.25 2.17 2/153 19021
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
18103  2243 root     R    39496  16%   0  51% nqcs
19018 18954 root     R     1768   1%   1   1% {exe} top
13157     1 root     S     7520   3%   1   0% dsld -i -n
3799     1 root     S     5276   2%   1   0% wland -B
[...]

So sieht das im Detail aus, was sich - aus einem top -d 1 >/var/tmp/top.log per grep "% nqcs" /var/tmp/top.log herausgefiltert - so darstellt:

root@fb7490:~ $ grep "% nqcs" /var/tmp/top.log
18103  2243 root     S    39496  16%   0   0% nqcs
18103  2243 root     S    39496  16%   0   0% nqcs
18103  2243 root     D    39496  16%   0  11% nqcs
18103  2243 root     R    39496  16%   0  46% nqcs
18103  2243 root     R    39496  16%   0  50% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  50% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  50% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  50% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     R    39496  16%   0  51% nqcs
18103  2243 root     S    39496  16%   0  43% nqcs
18103  2243 root     S    39496  16%   1   0% nqcs
18103  2243 root     S    39496  16%   1   0% nqcs

oder - als "Gesamtauslastung" über alles - dann so:

CPU:   8% usr   4% sys   0% nic  88% idle   0% io   0% irq   0% sirq
CPU:   1% usr   0% sys   0% nic  97% idle   0% io   0% irq   0% sirq
CPU:  10% usr   3% sys   0% nic  77% idle   8% io   0% irq   0% sirq
CPU:  24% usr  25% sys   0% nic  46% idle   3% io   0% irq   0% sirq
CPU:  22% usr  31% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  23% usr  30% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  21% usr  32% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  20% usr  34% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  24% usr  29% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  17% usr  37% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  24% usr  29% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  18% usr  35% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  20% usr  33% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  22% usr  32% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  17% usr  36% sys   0% nic  46% idle   0% io   0% irq   0% sirq
CPU:  26% usr  28% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  17% usr  37% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  21% usr  32% sys   0% nic  46% idle   0% io   0% irq   0% sirq
CPU:  22% usr  32% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  19% usr  34% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  22% usr  32% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  17% usr  37% sys   0% nic  44% idle   0% io   0% irq   0% sirq
CPU:  23% usr  30% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  21% usr  33% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  16% usr  38% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  27% usr  26% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  20% usr  34% sys   0% nic  45% idle   0% io   0% irq   0% sirq
CPU:  13% usr  32% sys   0% nic  54% idle   0% io   0% irq   0% sirq
CPU:   0% usr   1% sys   0% nic  97% idle   0% io   0% irq   0% sirq
CPU:   0% usr   1% sys   0% nic  97% idle   0% io   0% irq   0% sirq

(entscheidend ist hier weniger die Verteilung der CPU-Nutzung als vielmehr die "freie Zeit" unter "idle" - das ist ja die Summe beider Cores der 7490).

Zwar klappt die Dateiübertragung mit Windows (hier konkret mit Windows 7) dennoch, da ist der Client aber auch schwerer dazu zu bewegen, nur eine verschlüsselte Verbindung zum Server zu akzeptieren. Es kann also durchaus sein, daß die von mir beobachteten Probleme (obendrein noch mit der 73513 und nicht der letzten Laborversion) nur mit "smbclient" und/oder nur mit verschlüsselten (SMB3-)Verbindungen auftreten ... nur sind sie eben da und theoretisch könnte sie auch jeder SMB-Client im Netz verursachen.

Immerhin funktioniert auch mit "smbget" (das ist praktisch ein "wget" für SMB) der Download von der 7490 ... nur sieht das dann, wenn man verschlüsselt und unverschlüsselt vergleicht, so aus:

vidar:/tmp/mget $ time smbget -U xxx -v -o test.image smb://fb7490/fb7490/system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.51-32225.image
Password for [xxx] connecting to //fb7490/fb7490:
Using workgroup XXX, user xxx
smb://fb7490/fb7490/system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.51-32225.image
Downloaded 24.54MB in 7 seconds

real    0m6.905s
user    0m0.120s
sys     0m0.211s
vidar:/tmp/mget $ time smbget -e -U xxx -v -o test_enc.image smb://fb7490/fb7490/system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.51-32225.image
Password for [xxx] connecting to //fb7490/fb7490:
Using workgroup XXX, user xxx
smb://fb7490/fb7490/system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.51-32225.image
Downloaded 24.54MB in 311 seconds

real    5m10.548s
user    0m11.144s
sys     0m0.362s
vidar:/tmp/mget $

Ich bin vor Lachen fast vom Stuhl gefallen ... da tröpfeln die Daten dann mit ~80 KB/s aus der Box. Ich wollte zwar den "nqcs" stressen, um vielleicht mal einen Absturz zu provozieren, aber doch nicht meine Geduld auf die Probe stellen.

Nun hat die 7490 zwar keinen (mir bekannten) Hardware-Support für Crypto-Operationen, aber ich wäre mehr als erstaunt, wenn das Ergebnis bei der 7590 tatsächlich (sehr viel) besser wäre - denn nach der "top"-Ausgabe zu urteilen, erfolgt da die Verschlüsselung der Daten auch im "userland"-Daemon "nqcs" und offenbar auch nur in einem einzigen Thread, wie die Anzeige für den zweiten Core der 7490 zeigt. Daß MT (Multithreading) bei Encryption nicht einfach ist, wenn nachfolgende Runden auf den Ergebnissen vorhergehender aufbauen, habe ich schon bei manchem Anlass konstatiert, wenn sich jemand über die geringe (Gesamt-)Auslastung seiner Box bei VPN-Verbindungen wunderte.

Wenn das dann am Ende nicht mehr wirklich performant ist, ist das jedenfalls kaum verwunderlich ... auch dieses wieder (in meinen Augen zumindest) ein Argument dafür, auf SMB-Support im FRITZ!OS gänzlich zu verzichten.

Ohne Gegenmaßnahmen (rlimits, affinity, priority) kann sich dann schon eine SMB3-Verbindung zum DoS-Angriff auf andere Tasks ausweiten - es steht ja praktisch nur noch ein einzelner Core (bei der 7490) zur Verfügung und jetzt stelle man sich noch eine Datenübertragung per VPN parallel dazu vor, die den anderen Core (da erscheint die Last ja unter "sirq", weil die Verschlüsselung wohl im Rahmen der IRQ-Behandlung erfolgt) auslastet.

Was AVM da mit AppArmor veranstaltet, um dem ggf. schon entgegenzuwirken, habe ich noch nicht versucht zu ergründen ... vielleicht schränkt AVM den Prozess tatsächlich schon ein, wobei das Ergebnis oben den Stand aus der 73513 auch mit AppArmor wiedergibt und sich solche Beschränkungen dann auch schon bemerkbar machen sollten. Außerdem ist AppArmor eigentlich eher nicht zum Limitieren von Ressourcenverbrauch gedacht und andere Limits für den "nqcs" kann ich - zumindest auf den ersten Blick - auch nicht erkennen.

Vergleicht man nämlich den Download genau derselben Datei über "wget" mit den SMB3-Ergebnissen, ergibt sich folgendes Bild (ich habe hier einfach eine Freigabe verwendet - damit ist der Test zwar nicht 100% "wahrheitsgetreu", weil die Daten jetzt über den WAN-Stack gehen, aber für den Vergleich sollte es hinreichend genau sein):

vidar:/tmp/mget $ time wget --no-check-certificate -O test_wget_enc.image https://192.168.xxx.xxx:<port>/nas/filelink.lua?id=<anydata>
--2019-12-23 14:23:10--  https://192.168.[...]/nas/filelink.lua?id=[...]
Connecting to 192.168.[...]... connected.
WARNING: cannot verify 192.168.[...]'s certificate, issued by ‘CN=<unknown_box>.myfritz.net’:
  Self-signed certificate encountered.
    WARNING: certificate common name <unknown_box>.myfritz.net’ doesn't match requested host name ‘192.168.xxx.xxx’.
HTTP request sent, awaiting response... 200 OK
Length: 25733120 (25M) [application/octet-stream]
Saving to: ‘test_wget_enc.image’

test_wget_enc.image                                         100%[======================>]  24.54M   692KB/s    in 36s

2019-12-23 14:23:47 (690 KB/s) - ‘test_wget_enc.image’ saved [25733120/25733120]

real    0m37.026s
user    0m0.600s
sys     0m0.637s

Das ist schon mal um eine Zehnerpotenz schneller als verschlüsseltes SMB3 - aber hier macht die Frage "WAN oder LAN?" dann tatsächlich auch wieder einen Unterschied:

vidar:/tmp/mget $ time wget --no-check-certificate -O test_wget_enc_lan.image https://192.168.178.1/nas/filelink.lua?id=<anydata>
--2019-12-23 14:28:32--  https://192.168.178.1/nas/filelink.lua?id=<anydata>
Connecting to 192.168.178.1:443... connected.
WARNING: cannot verify 192.168.178.1's certificate, issued by ‘CN=<unknown_host>.myfritz.net’:
  Self-signed certificate encountered.
    WARNING: certificate common name ‘<unknown_host>.myfritz.net’ doesn't match requested host name ‘192.168.178.1’.
HTTP request sent, awaiting response... 200 OK
Length: 25733120 (25M) [application/octet-stream]
Saving to: ‘test_wget_enc_lan.image’

test_wget_enc_lan.image                                     100%[=======================>]  24.54M  2.36MB/s    in 10s

2019-12-23 14:28:43 (2.40 MB/s) - ‘test_wget_enc_lan.image’ saved [25733120/25733120]

real    0m10.815s
user    0m0.531s
sys     0m0.376s

Mit einem "Aufschlag" von rund 200% gegenüber einer unverschlüsselten HTTP-Verbindung:

vidar:/tmp/mget $ time wget -O test_wget_lan.image http://192.168.178.1/nas/filelink.lua?id=<anydata>
--2019-12-23 14:34:01--  http://192.168.178.1/nas/filelink.lua?id=<anydata>
Connecting to 192.168.178.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25733120 (25M) [application/octet-stream]
Saving to: ‘test_wget_lan.image’

test_wget_lan.image                                         100%[=======================>]  24.54M  7.50MB/s    in 3.3s

2019-12-23 14:34:04 (7.52 MB/s) - ‘test_wget_lan.image’ saved [25733120/25733120]

real    0m3.500s
user    0m0.134s
sys     0m0.516s

(3,5 s vs. 10,8 s) ist das zwar immer noch heftig, was hier "Sicherheit" bei der Datenübertragung kostet, aber das ist praktisch nichts im Vergleich zur derzeitigen SMB3-Implementierung, die auch unverschlüsselt doppelt so lange braucht, wie die Übertragung derselben Datei über HTTP (und WebDAV ist praktisch auch nur HTTP, ggf. mit TLS).

 

[sonyKatze]

dot_ca_root.pem

1. Könntest Du diese Datei irgendwo posten (oder kurz erklären wie man an die ran kommt)?
2. Hast Du schon rausgefunden, welche Zertifikate für SIP-over-TLS greifen?

 

[NDiIPP]

(oder kurz erklären wie man an die ran kommt)

Aktuelle Labor- oder Inhaus-Firmware (für die 7490 oder 7590) herunterladen und entpacken (nicht nur die Image-Datei, welche ein TAR-Archiv ist, sondern auch das darin enthaltene firmware.image unter ./var/tmp/). Entpacken ist bspw. mit fwmod aus Freetz möglich oder auch mit den YourFritz-Tools von @PeterPawn (https://github.com/PeterPawn/yf_bin).

Zu finden sein sollte die Datei dann vermutlich unter "./etc/default.Fritz_Box_[HWRevison]/[Branding]" (also bspw. "./etc/default.Fritz_Box_HW226/avm").

 

[PeterPawn]

Da sich seitens AVM bisher nicht gerührt hat bei der Frage der Bereitstellung von OSS-Paketen für die veröffentlichten Labor-Versionen (ich hatte das am 10.12.2019 per E-Mail erbeten, s.o.), habe ich soeben noch einmal (ebenfalls noch per E-Mail) nachgehakt.

Sollte jemand Zeit und Muße haben und ebenfalls an den Quellen interessiert sein (ich denke mal, es wird wenig Begeisterung (bzw. wenige Begeisterte, die das auch machen könnten) geben, die notwendigen Infos wieder durch Reverse-Engineering zu ermitteln - zumal das bei den Kernel-Quellen für die 7590 kaum machbar wäre ... die Konfiguration der uClibc-ng für die 7490 könnte man notfalls auf diesem Wege noch herleiten, aber auch das ist Aufwand, der nicht notwendig ist und den erst einmal jemand betreiben müßte), wäre es vielleicht hilfreich, wenn auch andere IPPF-Leser bei AVM ([email protected] ist die offziell dafür vorgesehene Adresse, lt. der "license.txt" von AVM) danach fragen könnten.

Je eher diese Pakete zur Verfügung stehen, desto eher wird auch die Nutzung von Freetz (zumindest der Toolchain und damit auch von anderen Binaries, die mit der Toolchain erstellt werden können) mit dieser Labor-Reihe möglich werden. Es gäbe zwar (für die 7490) wie erwähnt auch noch Alternativen, aber diese sind eben mit zusätzlichem Aufwand verbunden und die Bereitstellung dieser Pakete ist keine "Gnade" seitens AVM, sondern eine klare Verpflichtung, die sich aus den Lizenzbestimmungen ergibt.

AVM versucht ja offensichtlich schon an genug Punkten, auf Software umzustellen, die sie nicht länger zur Veröffentlichung der verwendeten Original-Quellen inkl. der eigenen Änderungen daran verpflichtet (es ist ja schon einigermaßen auffällig, wenn sich neue Entwicklungen bei AVM immer auf Software unter MIT-Lizenz stützen, selbst wenn es besser geeignete und besser getestete GPL-Alternativen gäbe) ... bis das aber "vollbracht" ist, sollte "die Community" auch von ihrem Recht auf Freigabe dieser Informationen (was wird verwendet, mit welchen Einstellungen wird das beim Build konfiguriert, was hat AVM da an eigenen Änderungen vorgenommen) Gebrauch machen - denn genau das ist es, was die Väter dieser Lizenzbestimmungen im Sinn hatten bei deren Entwurf und das wissen und wollen die "Verwender" dieser Lizenz (für die eigene Software) ebenfalls.

 

[NDiIPP]

Auch wenn es hier vielleicht ein wenig OT ist, aber es besteht meiner Ansicht nach, vorausgesetzt ich habe da nichts übersehen, (u.a.) auch ein wenig Nachholbedarf bei den IPQ-Modellen (Repeater 1200 und 3000, Fritzbox 4040, 7520 und 7530). Das neueste Quelltextpaket stammt da wohl von der 7530 für die FRITZ!OS-Version 7.03. Zwar gibt es für die IPQ-Modelle (noch) keine öffentlichen 07.19er Beta-Versionen aber es fehlen bisher bereits die Quelltextpakete für alle FRITZ!OS Versionen >=07.10 auf osp.avm.de (und da ist man mittlerweile auch schon bei Ver. 07.14 angekommen).

 

[Chatty]

Wäre prima, wenn jemand ein Mail wie die folgende vorformulieren könnte:

Hallo AVM,
bitte die Quelltexte für die folgenden Boxen zur Verfügung stellen:

• 113.07.12
• 113.07.19
• ...

Es ist doch Blödsinn, wenn jeder immer nur seinen kleinen Teil anfragt. Eine vollständige Liste und der "Angriff" kann losgehen. Schlimm genug, dass man überhaupt jedes Mal für jede Box, jede neue Version usw. anfragen muss und dann Monate bis Jahre warten muss.

 

[PeterPawn]

Dafür erwecken individuelle Anfragen aber eben auch genau nicht diesen Eindruck eines "Angriffs" (und so will ich meine Aufforderung auch nicht verstanden wissen).

Es ist nur für die Leute, die eigene Programme laufen lassen wollen/müssen, im Moment mal wieder nicht ohne weiteres möglich, eine der Labor-Versionen zu verwenden (nicht mal die der 7490, wo der Kernel noch derselbe ist), weil die C-Libraries nicht zueinander passen. Und weil ich auch keinen Bock habe, die Konfiguration für die uClibc-ng 1.0.30 irgendwie selbst zusammenzustellen - die bisher verwendete 1.0.14 ist knapp vier Jahre alt (April 2016) und zwischen der und der neuen 1.0.30 (die ist vom April 2018) liegen auch wieder zwei Jahre und 400 Commits. Sich da durchzugraben und zu raten, welche hinzugekommene Einstellung AVM da nun gewählt haben mag für die eigene Version, ist einfach verschenkte Zeit und nur der letzte Notnagel, falls sich AVM tatsächlich weigern sollte, die Pakete herauszugeben.

Die früher mal zum Ausdruck gebrachte Ansicht, man müsse das erst für Release-Versionen machen (ich müßte aber den heise.de-Beitrag erst wieder raussuchen, wo der AVM-Sprecher dann - subtil formuliert - feststellt, daß AVM für jede Release-Version auch die OSS-Pakete bereitstellen würde und wo der Interviewer wohl vergessen hatte, die Frage zu stellen, wie man sich das für Labor-Versionen konkret vorstellen müsse), hatte zwischendrin ja auch schon mal ein paar Risse bekommen, als man z.B. die Quellen für die Labor-Version 113.06.10-27498 veröffentlichte.

In meiner "Standardumgebung" wird jedenfalls z.B. der Suchpfad für die Libraries über "LD_LIBRARY_PATH" auf die gemounteten Erweiterungen ausgedehnt und wenn man beim Start irgendeines AVM-Programms die falsche (weil alte) C-Library dort zuerst drin hat, knallt's gleich mal mit einem Segmentation-Fault. Jedesmal beim Start eines AVM-Programms diese Environment-Variable zu überschreiben, kann auch nicht der Weisheit letzter Schluß sein und geht mir auf die Eier - angepaßte Erweiterungspakete für die neue C-Library brauchen die richtige Konfiguration.

==============================================================

Da wohl kein FRITZ!Box-Besitzer eine "ganze Liste" von Boxen besitzt und schon gar nicht mehrere immer dieselben, würde ich als AVM auch einer "vorgefertigten Mail" weniger Aufmerksamkeit schenken und daß AVM die Quellen tatsächlich immer erst auf Aufforderung und nicht "pro-aktiv" herausgibt, ist eine Erfahrung, die wir in den letzten Jahren ständig gemacht haben. Die Lizenzbedingungen verpflichten auch nicht zu einer aktiven Herausgabe/Bereitstellung, aber die Anfrage war m.E. auch deutlich und dann besteht durchaus diese Pflicht. Wenn AVM sich (bei unterstelltem Desinteresse "da draußen") die Arbeit der Paketierung für eine Version nicht machen will, verstehe ich das sogar ... wobei man sich mit ein paar Skripten sicherlich auch dieses Zusammenstellen so weit automatisieren könnte, daß da nicht jedesmal ein Mitarbeiter einen ganzen Tag dran sitzt und einen Rechner dafür, sollte man problemlos "abstellen" können (wobei das CI-/CD-System für die Images ja wohl auch automatisiert ist und für Tests gibt es wohl auch eine skriptbare Container-Umgebung mit Namen "Layla").

Da würde ich jetzt jedenfalls keine generelle Änderung der "Politik" erwarten und bei den von mir oben erbetenen Anfragen - auch nach dem OSS-Paket für die Labor-Version - erhoffe ich mir eher die Erkenntnis bei AVM, daß es doch nicht nur zwei, drei Kunden sind, die an diesen Dateien ein Interesse haben und die man daher auch getrost ignorieren kann. Letztlich bringt die zeitnahe Veröffentlichung des Pakets - selbst für eine Labor-Version - auch den Projekten rund um die FRITZ!Boxen etwas ... bisher hat sich während einer Labor-Reihe am Kernel oder der C-Library eigentlich nie etwas Substantielles im Nachhinein noch geändert - mal abgesehen von notwendigen Fehlerkorrekturen. Damit steht zu erwarten, daß man mit dem Paket für die Labor-Version auch den Vorlauf erreichen kann, der bei der Veröffentlichung einer Release-Version eine (ebenfalls zeitnahe) Unterstützung dieser neuen Version erst ermöglicht.

Im Moment sieht das - wenn man mal die Analogie zu MS und den Beta-Versionen für Windows zieht - so aus, daß die ganzen Hersteller rundherum zwar feststellen können, ob ihre eigenen Programme mit der neuen Version funktionieren würden (bzw. daß sie es eben nicht tun) und trotzdem müssen sie bis zum Erscheinen der Release-Version warten, bevor sie ihre eigenen Programme anpassen können, weil MS ihnen keine weiteren Infos, was sich nun genau geändert hat, überläßt. Das kann nicht im Sinne des Erfinders (und der FRITZ!Box-Besitzer, die nach wie vor an Modifikationen und Projekten wie Freetz (oder Ableger) interessiert sind) sein und da steht man als Einzelner mit der Aufforderung zur Bereitstellung der Pakete vielleicht eher auf verlorenem Posten, denn als "Gruppe" (so klein sie auch sein mag).