Ich habe mit dem heise.de-Artikel nur insoweit zu tun, als daß ich ihn gelesen habe und (auch wenn ich zuvor schon einige Veränderungen im SIP-Registrar und -Client bemerkt hatte und die hier wohl auch mal erwähnte) mit dem Heap-Overflow habe ich absolut nichts zu schaffen.
Ich war heute vormittag nur ohnehin gerade dabei, einige der von mir an AVM gemeldeten Probleme "abzuschließen" im GitHub-Repository, indem ich ein paar Informationen ergänzte ... da schneite dann auch gg. 14:00 Uhr diese Meldung von heise.de herein. Da ich ja auch den PoC für den DoS-Angriff vor etwas mehr als einer Woche vervollständigt hatte und da heute die letzten Worte in der README.md für diesen Fall ergänzt hatte, war ich zuerst (von der reinen "headline") auch etwas überrascht und recht erleichtert, als ich dann las, daß es definitiv um ein vollkommen anderes Problem ging - ich wollte mit dem DoS ja keinen richtigen Staub aufwirbeln.
Daß eine FRITZ!Box (bzw. einige Daemons) auch mit anderen "malformed packets" abgeschossen werden könnte(n), ist nun nicht so überraschend (s. mein abschließender Beitrag
hier) ... eher schon die Tatsache, daß da jemand sich die Arbeit machte, einen Exploit zu bauen, der (vermutlich, ich kenne auch nur dieses eine Bild von der Linux-Konsole im "reibuntu", wo offenbar ein Python-Skript ausgeführt wurde) für ein bestimmtes Modell mit einer bestimmten Firmware-Version funktioniert.
Schon der unterschiedliche Ausstattungsgrad der verschiedenen Modelle i.V.m. den tatsächlich vom Benutzer genutzten Diensten dürfte zu einer recht abwechslungsreichen Aufteilung des Speichers in einer FRITZ!Box führen und vermutlich auch zu einer abweichenden "Auslastung" des Heaps in den AVM-Daemons. Ich denke auch nicht, daß da irgendwelche Bibliotheken oder Programme an fixe Adressen geladen werden, da müßten sich - zumindest nach meinem Verständnis der Speicherverwaltung bei MIPS mit MMU - auch unterschiedliche Ladeadressen ergeben ... für die Kernel könnte das - dank des "avm_kernel_config" mit fester Größe und (per Modell) wechselndem Inhalt - sogar noch einheitlich sein über mehrere Modelle bei identischem Chipsatz. Aber trotzdem ist es schon recht aufwändig, da einen entsprechenden Exploit zu basteln und wie es um dessen "Wiederverwendbarkeit" steht, möchte ich lieber nicht wissen - Hut ab vor demjenigen, der sich da diese Arbeit machte (ich lese den heise.de-Artikel so, daß es drei Leute zusammen taten - die meisten können sich vermutlich gar nicht vorstellen, wie aufwändig (und bei Fehlschlägen auch frustrierend) solche Suchen sind und erst recht die Entwicklung passender Exploits, solange man die originalen Quellen nicht hat).
Schaut man sich dieses Bild der Linux-Konsole bei heise.de an, würde ich (reine Spekulation meinerseits, durch nichts als die Ausschriften "gedeckt") vermuten, daß da irgendwo fertiger Maschinencode implantiert wurde (als Payload in dem fraglichen Paket) und dieser im Anschluß "angesprungen" wird, weil irgendeine Return-Adresse einer aufgerufenen Funktion auf dem Heap überschrieben wurde. Dieser Code baut dann wohl eine TCP-Verbindung zu einer (festen?) Adresse auf (oder öffnet wirklich eine "reverse shell", wobei eine komplette "Behandlung" einer TCP-Verbindung einiges an Code erfordert oder zumindest erfordern kann) und führt dann ein "uname -a" und ein "id" aus, deren Ausgabe er über die Verbindung schickt.
Wenn das nicht die Reaktion auf vom (lokalen Python-)Exploit gesendete Kommandos ist (dann liefe auf der Box eine Shell mit entsprechendem Remote-Zugriff und AVM würde wohl kaum - oder zumindest hoffentlich nicht - von "bei kundenüblichem Einsatz der Produkte praktisch unmöglich" sprechen), dann dürfte das also irgendein "execve"-Aufruf für die Shell mit dieser (recht kurzen) Kommandozeile sein. So etwas kann man dann sicherlich entsprechend vorbereiten für ein Modell und/oder eine bestimmte Version ... aber so etwas "on the fly" auf einer Box mit wechselnder Konfiguration zu realisieren (schon die Änderung der Anzahl der eingerichteten Rufnummern und/oder Telefoniegeräte
könnte eine Verschiebung der Lage des Buffers auf dem Heap nach sich ziehen), ist dann schon ziemlich schwer - selbst wenn das alles mit relativer Adressierung arbeiten sollte. Aber wie gesagt ... alles reine Spekulation meinerseits.
Das gilt am Ende auch für meine "Behauptung" in #1, daß das Problem im SIP-Parser stecken würde. Wie komme ich dazu? Bei der ganzen VoIP-Geschichte gibt es ja (vor der "Annahme" eines Anrufs, wo dann ggf. noch RTP mit ins Boot kommt) eigentlich nur eine rein textbasierte Kommunikation zwischen den Partnern ... der eine sendet eine SIP-Message und der andere antwortet ihm darauf.
Nun gibt es bei dieser ganzen Kommunikation mit Texten (aka "Zeichenketten") ja eigentlich keine großartigen Längenangaben für irgendwelche Inhalte ... mit einer entscheidenden Ausnahme (ich tippe einfach, daß hier auch die Ursache des Problems lag und es von AVM beim "Härten" des Parsers quasi nebenbei beseitigt wurde): Die Header-Daten so eines Requests (siehe
RFC 3261, "Content-Length") können die Länge des "Körpers" so einer SIP-Nachricht enthalten. Reserviert jetzt der Empfänger seinen "Empfangspuffer" nur in einer Länge, die der Absender dort angegeben hat und werden dann im Nachhinein doch mehr Daten empfangen und im Puffer abgelegt, schreibt so ein Zugriff schon mal über das Ende eines solchen Puffers hinaus - man sollte sich grundsätzlich bei von außen manipulierbaren Daten nicht ausschließlich auf die Angaben des "Absenders" verlassen. Zumindest wäre das die erste Stelle, an der ich so einen Heap-Overflow jetzt vermuten würde ... ansonsten gibt es m.W. bei der VoIP-Kommunikation (außerhalb eines Anrufs, d.h. ohne einen aktiven Media-Stream) praktisch keine "Längenangaben" für irgendwelche Daten, die der Absender fehlerhaft machen könnte - daher auch meine Annahme zur betroffenen Stelle, wobei man nun noch diskutieren kann, ob der Empfang so einer SIP-Message schon zu deren "Analyse" (aka Parsen bzw. "Zerlegen") gehört oder noch zum "Netzwerk-Stack".
Je nachdem, was sich nun "hinter" diesem reservierten Platz für den Puffer befand, muß man sich als der Angreifer etwas ausdenken, wie man diese zuviel geschriebenen Daten jetzt so "einbindet", daß daraus nicht nur ein simpler Absturz resultiert, sondern wirklich die Ausführung eingeschleusten (Maschinen-)Codes. Bei halbwegs modernen Prozessoren kann man auch nicht einfach irgendwelchen Code auf dem Heap ablegen und den dann dort ausführen ... auch bei einem VR9-Prozessor sollte eigentlich ein entsprechendes Flag in der MMU dafür sorgen, daß dort abgelegter Inhalt erst einmal "not executable" ist.
Damit muß man das dann erst noch an eine andere Stelle kopieren (wo es "executable" wäre) oder man sucht sich aus "Versatzstücken" in existierenden Code-Segmenten durch passende Aufrufe und Rücksprünge einen benutzbaren Programmablauf zusammen. Das braucht also in der Regel einen sehr speziell aufgebauten "Inhalt" (im Body der gesendeten SIP-Message), der an die Stelle, wo das System eine Rücksprungadresse erwartet, dann auch etwas schreibt, was wirklich "angesprungen" werden kann und nicht einfach nur zu einem Absturz des Prozesses führt.
Das ist also richtig Arbeit (und ich meine richtig "richtig"), so einen Exploit zusammenzustellen ... trotzdem steht es für mich außer Frage, daß so eine Lücke gefixt werden muß (hier ist sie es ja wohl schon) - egal wie einfach oder wie schwer es nun sein mag, sie für das externe Einschleusen von Code zu benutzen. Da
kann es doch gar keine Diskussion geben ... höchstens noch um die Bewertung der Schwere einer solchen Lücke und einer solchen geht AVM (nach meiner Erfahrung zumindest) ohnehin eher aus dem Weg.
- - - Aktualisiert - - -
PS: Ehe jetzt jemand mit mir diskutieren will (es gibt ja solche Kandidaten und manchmal mache auch ich selbst solchen Quatsch), was der Unterschied zwischen "heap" und "stack" ist und wo man eine Rücksprungadresse speichern müßte und wie die diversen Techniken an dieser Stelle funktionieren (die Box macht z.B. m.W. kein ASLR) ... das ist (absichtlich) vereinfacht, mir sind die Unterschiede bewußt und auch die Probleme dabei bekannt. Das sollte aber nur "das Prinzip" sein und keine Anleitung, wie so etwas funktioniert.
