[Info] Keine Firmware < 06.83 verwenden, wenn neuere verfügbar ist

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
Punkte
113
Heap-Overflow im SIP-Parser, von AVM offenbar (versehentlich?) bereits gefixt ... das an vielen Stellen geänderte Verhalten des "voipd" (angefangen beim Parsen eingehender Requests bis zur Verbesserung der RFC-Konformität eigener Nachrichten) war ja bereits in einigen anderen Threads ein Thema.

https://heise.de/-3687437
 
(Kurze) Infos dazu jetzt auch bei AVM in den Sicherheits- und den Versionshinweisen.

03.03.2017 Sicherheitsverbesserungen FRITZ!OS 6.83
Vorab möchten wir uns bei P. Hämmerlein und einem weiteren Melder [1] für Ihre Meldungen bedanken.
Beschreibung
in FRITZ!OS 6.80/81 war es mit einem speziell präparierten Datenpaket und dem Zusammentreffen mehrerer Bedingungen möglich, einen Speicherüberlauf zu erzeugen. Dies wurde mit FRITZ!OS 6.83 behoben [1].
Ein von P. Hämmerlein gemeldeter Punkt wird zu einem späteren Zeitpunkt veröffentlicht.
Behoben mit
FRITZ!OS 6.83
Hinweis
[1] Betroffen waren nur Modelle mit FRITZ!OS 6.80 und 6.81
Lösung
Bitte installieren Sie die aktuelle FRITZ!OS-Version auf Ihrer FRITZ!Box.
https://avm.de/service/sicherheitsinfos-zu-updates/


19.04.2017 FRITZ!OS 6.83 erhöht Robustheit
Die aktuelle Version FRITZ!OS 6.83 verbessert eine Schwäche der älteren FRITZ!OS-Version 6.80/6.81. Unter bestimmten Voraussetzungen hätte es zum Neustart kommen können. Es ist kein Fall von Missbrauch bekannt. Die Version 6.80/6.81 wurde per Auto-Update bereits flächendeckend durch die Version 6.83 ersetzt.

https://avm.de/service/aktuelle-sicherheitshinweise/
 
Zuletzt bearbeitet:
Ist @PeterPawn nun eine der im Heise-Artikel oder in den Hinweisen namentlich genannten Personen, oder zumindest der "weitere Melder"...?
 
Nein. Im Artikel steht auch nichts von einem weiteren Melder. Ist bei dem Thema auch irrelevant.
 
Warum kommt dann @PP mit dieser Meldung als TO ?
--> github ;)

---

Aber richtig, es ist irrelevant.
Wichtiger ist es, dass bei "Suche/Tausche Firmware" die "verbotenen" Firmwares nicht gehandelt werden.
 
Zuletzt bearbeitet:
@robert_s
in #2 und somit bei AVM steht doch @PP
 
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.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,696
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.