Stagefright: Der Exploit, der Android veränderte

Eine der Stärken von Android ist in erster Linie sein Open-Source-Charakter, der es den Beteiligten ermöglicht, das Betriebssystem auf eine Art und Weise zu teilen, zu modifizieren und weiterzuverbreiten, die ihren jeweiligen Bedürfnissen entspricht. Doch gerade dieser Vorteil der Open Source wirkt wie ein zweischneidiges Schwert, wenn es um die Themen Malware und Sicherheit geht. Es ist einfacher, Fehler zu finden und zu beheben, wenn Sie viele kompetente Mitwirkende an einem Projekt haben, deren Quellcode frei verfügbar ist. Die Behebung des Problems auf der Ebene der Quelle führt jedoch häufig nicht dazu, dass das Problem in den Händen des Endverbrauchers behoben wird. Daher ist Android nicht die erste Wahl, wenn es um die Auswahl eines Betriebssystems für datensensible Unternehmensanforderungen geht.

Auf der Google I/O 2014 gab Google mit der Einführung von den ersten Anstoß für ein sichereres und unternehmensfreundlicheres Ökosystem Android For Work-Programm. Android For Work hat einen Twin-Profile-Ansatz für Unternehmensanforderungen übernommen, bei dem IT-Administratoren ein Profil erstellen können Unterschiedliche Benutzerprofile für Mitarbeiter – eines konzentriert sich auf die Arbeit, während die anderen Profile den Mitarbeitern vorbehalten sind verwenden. Durch den Einsatz hardwarebasierter Verschlüsselung und vom Administrator verwalteter Richtlinien blieben geschäftliche und persönliche Daten getrennt und sicher. In der Folge erhielt Android For Work in den späteren Monaten mehr Aufmerksamkeit, wobei der Schwerpunkt auf der Sicherheit des Geräts vor Malware lag. Google hatte das auch geplant Aktivieren Sie die vollständige Geräteverschlüsselung für alle Geräte Diese sollten standardmäßig mit Android Lollipop veröffentlicht werden, wurden jedoch aufgrund von Leistungsproblemen verworfen, da die Implementierung für OEMs optional war.

Der Vorstoß für ein sicheres Android ist nicht ausschließlich das Werk von Google, da Samsung dabei eine ziemlich wichtige Rolle gespielt hat KNOX-Beiträge zu AOSP, was letztendlich verstärktes Android For Work. Allerdings deuten die jüngsten Sicherheitslücken und Schwachstellen in Android darauf hin, dass es eine schwierige Aufgabe wird, wenn es um die Popularität bei der Einführung in Unternehmen geht. Ein typisches Beispiel ist die jüngste Stagefright-Sicherheitslücke.

Inhalt:

• Was ist Lampenfieber?
• Wie ernst ist Lampenfieber?
• Was unterscheidet Stagefright von anderen „massiven Schwachstellen“?
• Das Update-Dilemma
• Android, Post-Stagefright
• Schlussbemerkungen

Was ist Lampenfieber?

Einfach ausgedrückt handelt es sich bei Stagefright um einen Exploit, der die Codebibliothek für die Medienwiedergabe in Android nutzt libstagefright. Mithilfe der libstagefright-Engine wird Code ausgeführt, der in Form eines Schadvideos per MMS empfangen wird, so dass für einen erfolgreichen Angriff lediglich die Mobilfunknummer des Opfers erforderlich ist.

Wir haben uns an unseren internen Experten, XDA Senior Recognized Developer und Developer Admin, gewandt pulser_g2 um eine genauere Erklärung zu geben.

"Während ich dies schreibe, sollte der [Stagefright]-Exploit bei BlackHat erklärt werden [Verknüpfung], obwohl noch keine Folien oder Whitepaper-Details verfügbar sind.

Deshalb gebe ich diese Erklärung eher als grobe Vorstellung davon, was vor sich geht, und nicht als sehr ausführliche Erklärung mit voller Genauigkeit usw.

Es gibt eine Reihe verschiedener Bugs, aus denen Stagefright besteht, und diese haben ihren eigenen CVE [Häufige Schwachstellen und Gefährdungen] Nummern zur Nachverfolgung:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Leider sind die verfügbaren Patches nicht direkt mit jedem CVE verknüpft (wie es sein sollte), daher ist die Erklärung etwas kompliziert.

1. [CVE-2015-1538]

Im MPEG4-Verarbeitungscode ist der 3GPP-Metadaten-Verarbeitungscode (der Inhalt, der das Format und andere zusätzliche Informationen beschreibt, wenn ein Video im 3GPP-Format vorliegt) fehlerhaft. Metadaten wurden nicht abgelehnt, wenn die Daten übermäßig groß waren, sondern es wurde nur geprüft, ob sie zu klein waren. Dies bedeutete, dass es einem Angreifer möglich war, eine „veränderte“ oder „beschädigte“ Datei zu erstellen, die einen längeren Metadatenabschnitt hätte, als sie sollte.

Eine der großen Herausforderungen beim Schreiben von Code für den Umgang mit „nicht vertrauenswürdigen“ Daten (z. B. von einem Benutzer oder von einem anderen Ort außerhalb Ihres Codes) ist der Umgang mit Daten variabler Länge. Videos sind ein perfektes Beispiel dafür. Die Software muss den Speicher dynamisch zuweisen, je nachdem, was gerade passiert.

In diesem Fall wird ein Puffer als Zeiger auf einen Speicher erstellt, aber die Länge des Arrays, auf das er zeigt, war ein Element zu kurz. Die Metadaten wurden dann in dieses Array eingelesen, und es war möglich, dass der letzte Eintrag in diesem Array nicht „null“ (oder Null) war. Es ist wichtig, dass das letzte Element im Array Null ist, da die Software so mitteilt, dass das Array fertig ist. Durch die Möglichkeit, den letzten Wert ungleich Null zu machen (da das Array möglicherweise ein Element zu klein war), könnte der Schadcode von einem anderen Teil des Codes gelesen werden und zu viele Daten einlesen. Anstatt am Ende dieses Werts anzuhalten, könnte es mit dem Lesen in andere Daten fortfahren, die es nicht lesen sollte.

(Bezug: OmniROM Gerrit)

2. [CVE-2015-1539]

Die kürzestmögliche „Größe“ der Metadaten sollte 6 Byte betragen, da es sich um einen UTF-16-String handelt. Der Code nimmt die ganzzahlige Wertgröße und subtrahiert 6 davon. Wenn dieser Wert kleiner als 6 wäre, würde die Subtraktion „unterlaufen“ und umlaufen, und wir würden am Ende eine sehr große Zahl erhalten. Stellen Sie sich vor, Sie könnten beispielsweise nur von 0 bis 65535 zählen. Wenn Sie die Zahl 4 nehmen und 6 subtrahieren, können Sie nicht unter Null gehen. Sie gehen also zurück zu 65535 und zählen von dort aus. Genau das passiert hier!

Wenn eine Länge von weniger als 6 empfangen wurde, konnte es dazu kommen, dass Frames falsch dekodiert wurden, da die Der Byteswap-Prozess verwendet die Variable len16, deren Wert aus einer Berechnung erhalten wird, beginnend mit (Größe 6). Dies könnte dazu führen, dass ein viel größerer Austauschvorgang als beabsichtigt stattfindet, wodurch sich die Werte in den Frame-Daten auf unerwartete Weise ändern würden.

(Bezug: OmniROM Gerrit)

3. [CVE-2015-3824]

Ein großes Problem! Das ist böse. Es gibt das genaue Gegenteil dieses letzten Problems – einen Ganzzahlüberlauf, bei dem eine Ganzzahl „zu groß“ werden kann. Wenn Sie (zum Beispiel) 65535 erreichen und nicht weiter zählen können, würden Sie herumrollen und als nächstes zu 0 gehen!

Wenn Sie auf dieser Grundlage Speicher zuweisen (was Stagefright tut!), würde am Ende viel zu wenig Speicher im Array zugewiesen sein. Wenn dort Daten abgelegt würden, würden möglicherweise nicht verwandte Daten mit Daten überschrieben, die der böswillige Dateiersteller kontrolliert habe.

(Bezug: OmniROM Gerrit)

4. [CVE-2015-3826]

Wieder ein böses Ding! Dem letzten sehr ähnlich – ein weiterer Ganzzahlüberlauf, bei dem ein Array (das als Puffer verwendet wird) zu klein gemacht würde. Dadurch könnte nicht verwandter Speicher überschrieben werden, was wiederum schlecht ist. Jemand, der Daten in den Speicher schreiben kann, kann andere Daten beschädigen, die nichts miteinander zu tun haben, und dies möglicherweise dazu verwenden, dass Code, den er kontrolliert, von Ihrem Telefon ausgeführt wird.

(Bezug: OmniROM Gerrit)

5. [CVE-2015-3827]

Ganz ähnlich wie diese letzten. Beim Überspringen von Speicher wird eine Variable verwendet, die bei einer Subtraktion (wie oben) negativ gemacht werden kann. Dies würde zu einer sehr großen „Sprung“-Länge führen, einen Puffer überlaufen lassen und Zugriff auf Speicher ermöglichen, auf den nicht zugegriffen werden sollte.

(Bezug: OmniROM Gerrit)

Es gibt auch einige (potenziell) damit zusammenhängende Korrekturen, die es offenbar auch in [Android] 5.1 geschafft haben.

(Bezug: OmniROM Gerrit)

Dadurch werden Überprüfungen hinzugefügt, um Probleme mit einem früheren Sicherheitsupdate zu verhindern und Grenzüberprüfungen hinzuzufügen, die selbst überlaufen können. In C werden Zahlen, die als vorzeichenbehaftete Ganzzahl dargestellt werden können, als vorzeichenbehaftete Ganzzahl gespeichert. Ansonsten bleiben sie im Betrieb unverändert. Bei diesen Prüfungen hätten einige Ganzzahlen mit Vorzeichen (statt ohne Vorzeichen) versehen werden können, was später ihren Maximalwert verringern und einen Überlauf ermöglichen würde.

(Bezug: OmniROM Gerrit)

Einige weitere ganzzahlige Unterläufe (bei denen die Zahlen zu niedrig sind und dann eine Subtraktion für diese Zahlen durchgeführt wird, wodurch sie negativ werden). Dies wiederum führt eher zu einer großen als zu einer kleinen Zahl, und das verursacht die gleichen Probleme wie oben.

(Bezug: OmniROM Gerrit)

Und zum Schluss noch ein ganzzahliger Überlauf. Wie zuvor, wird es bald woanders verwendet und könnte überlaufen.

(Bezug: OmniROM Gerrit)"

Wie ernst ist Lampenfieber?

Gemäß der Blogeintrag Der Stagefright-Exploit, der vom Mutterforschungsunternehmen Zimperium Research Labs veröffentlicht wurde, legt potenzielle Risiken offen 95 % der Android-Geräte – etwa 950 Millionen – sind von dieser Sicherheitslücke betroffen, da sie Geräte mit Android 2.2 und 2.2 betrifft hoch. Erschwerend kommt hinzu, dass Geräte vor Jelly Bean 4.3 dem „größten Risiko“ ausgesetzt sind, da diese keine ausreichenden Abhilfemaßnahmen gegen diesen Exploit enthalten.

Bezüglich des Schadens, den Stagefright anrichten könnte, bemerkte pulser_g2:

[blockquote author="pulser_g2"]"An sich würde Stagefright dem Systembenutzer Zugriff auf das Telefon gewähren. Sie müssten jedoch ASLR (Adressraum-Layout-Randomisierung) umgehen, um es tatsächlich zu missbrauchen. Ob dies erreicht wurde, ist derzeit nicht bekannt. Dieser Exploit ermöglicht die Ausführung von „beliebigem Code“ auf Ihrem Gerät als System- oder Medienbenutzer. Diese haben Zugriff auf Audio und Kamera des Geräts, und der Systembenutzer ist ein großartiger Ort, um einen Root-Exploit zu starten. Erinnern Sie sich an all die erstaunlichen Root-Exploits, mit denen Sie Ihr Telefon gerootet haben?

Diese könnten möglicherweise stillschweigend verwendet werden, um Root auf Ihrem Gerät zu erlangen! Wer root hat, besitzt das Telefon. Sie müssten SELinux umgehen, aber TowelRoot hat das geschafft, und PingPong hat es auch geschafft. Sobald sie root sind, steht ihnen alles auf Ihrem Telefon offen. Nachrichten, Schlüssel usw.“[/blockquote]Im schlimmsten Fall ist lediglich eine MMS erforderlich, um Code zu übermitteln und diesen Exploit auszulösen. Der Benutzer Es ist nicht einmal erforderlich, die Nachricht zu öffnen da viele Messaging-Apps MMS vorverarbeiten, bevor der Benutzer mit ihnen interagiert. Dies unterscheidet sich von Spear-Phishing-Angriffen, da der Benutzer von einem erfolgreichen Angriff überhaupt nichts mitbekommt und alle aktuellen und zukünftigen Daten auf dem Telefon gefährdet werden.

Was unterscheidet Stagefright von anderen „massiven Schwachstellen“?

„Alle Schwachstellen stellen ein gewisses Risiko für Benutzer dar. Dieses ist besonders riskant, denn wenn jemand einen Weg findet, es aus der Ferne anzugreifen (was der Fall ist). möglich, wenn ein Weg gefunden wird, ASLR zu umgehen), könnte es ausgelöst werden, bevor Sie überhaupt merken, dass Sie unter Druck stehen Attacke"

Ältere Exploits wie Android Installer Hijacking, FakeID sowie Root-Exploits wie TowelRoot und PingPong erfordern irgendwann eine Benutzerinteraktion, um ausgeführt zu werden. Obwohl es sich immer noch um „Ausbeutungen“ handelt, da bei böswilliger Verwendung viel Schaden entstehen kann, bleibt die Tatsache bestehen, dass Stagefright Theoretisch benötigt das Opfer nur die Mobiltelefonnummer, um sein Telefon in einen Trojaner zu verwandeln, und erfährt daher in letzter Zeit große Aufmerksamkeit Tage.

Allerdings ist Android diesem Exploit nicht völlig ausgeliefert. Der leitende Ingenieur für Android-Sicherheit, Adrian Ludwig, ging in einem auf einige Bedenken ein Google+ Beitrag:

[blockquote author="Adrian Ludwig"]"Es gibt eine weitverbreitete, irrige Annahme, dass jeder Softwarefehler in eine Sicherheitslücke umgewandelt werden kann. Tatsächlich sind die meisten Fehler nicht ausnutzbar und es gibt viele Dinge, die Android getan hat, um diese Chancen zu verbessern ...

Nachfolgend finden Sie eine Liste einiger Technologien, die seit Ice Cream Sandwich (Android 4.0) eingeführt wurden Hier. Die bekannteste davon heißt Address Space Layout Randomization (ASLR) und wurde vollständig fertiggestellt in Android 4.1 mit Unterstützung für PIE (Position Independent Executables) und ist jetzt auf über 85 % von Android verfügbar Geräte. Diese Technologie macht es für einen Angreifer schwieriger, den Speicherort des Codes zu erraten, der für die Erstellung eines erfolgreichen Exploits erforderlich ist ...

Wir haben nicht bei ASLR aufgehört, sondern auch NX, FortifySource, Read-Only-Relocations, Stack Canaries und mehr hinzugefügt.“[/blockquote]

Dennoch lässt sich nach wie vor nicht leugnen, dass Stagefright eine ernste Angelegenheit für die Zukunft von Android ist und daher von den beteiligten Stakeholdern ernst genommen wird. Stagefright hob auch die weißen Elefanten im Raum hervor – das Problem der Fragmentierung und der Tatsache, dass Aktualisierungen endlich den Verbraucher erreichen.

Das Update-Dilemma

Apropos Updates: Es ist gut zu sehen, dass OEMs die Verantwortung für die Sicherheit der Benutzer übernehmen, wie viele es versprochen haben Verbessern Sie den Update-Prozess speziell für die Integration von Sicherheitsfixes und Patches für Exploits wie Stagefright.

Als eines der ersten Unternehmen, das eine offizielle Stellungnahme veröffentlichte, hat Google zugesagt monatliche Sicherheitsupdates (zusätzlich zu den geplanten Betriebssystem- und Plattform-Updates) für die meisten seiner Nexus-Geräte, einschließlich des fast drei Jahre alten Nexus 4. Auch Samsung folgte diesem Beispiel und kündigte an, mit Netzbetreibern und Partnern an der Implementierung eines zu arbeiten monatliches Sicherheitsupdateprogramm Es konnten jedoch keine Angaben zu den Geräten und Zeitleistendetails dieser Implementierung gemacht werden. Das ist interessant, da darin ein „Fast-Track“-Ansatz für Sicherheitsupdates in Zusammenarbeit mit Netzbetreibern erwähnt wird, damit wir dies tun können Erwarten Sie häufigere Updates (wenn auch sicherheitsbasiert, aber hoffentlich werden dadurch auch Firmware-Upgrades beschleunigt) auf dem Mobilfunkanbieter Geräte.

Zu den weiteren OEMs, die sich dem Rudel anschließen, gehört auch LG, das mitmachen wird monatliche Sicherheitsupdates. Motorola hat das ebenfalls angekündigt Liste der Geräte, die aktualisiert werden mit Stagefright-Korrekturen, und die Liste umfasst fast alle Geräte, die das Unternehmen seit 2013 hergestellt hat. Sony hat das auch gesagt Seine Geräte werden die Patches bald erhalten zu.

Ausnahmsweise stellen auch die Netzbetreiber Updates bereit. Sprint hat eine Stellungnahme abgegeben dass einige Geräte bereits den Stagefright-Patch erhalten haben und das Update für weitere Geräte geplant ist. Auch AT&T ist diesem Beispiel gefolgt indem Sie den Patch auf einigen Geräten veröffentlichen. Verizon hat ebenfalls Patches veröffentlicht, allerdings handelt es sich dabei um einen langsamen Rollout, bei dem High-End-Smartphones wie das Galaxy S6 Edge und Note 4 Vorrang haben. Das T-Mobile Note 4 erhielt ebenfalls ein Stagefright-Patch-Update.

Als Endbenutzer können Sie einige Vorsichtsmaßnahmen ergreifen, um das Risiko eines Angriffs zu verringern. Deaktivieren Sie zunächst den automatischen Abruf von MMS-Nachrichten in den Messaging-Apps auf Ihrem Telefon. Dies sollte die Fälle unter Kontrolle halten, in denen keine Benutzerinteraktion erforderlich war, damit der Exploit funktioniert. Achten Sie danach darauf, das Herunterladen von Medien aus MMS-Nachrichten aus unbekannten und nicht vertrauenswürdigen Quellen zu vermeiden.

Als XDA-Power-User können Sie das auch Nehmen Sie Änderungen an Ihrer Build-Requisite vor, um Stagefright zu deaktivieren. Dies ist kein vollständiger und sicherer Weg, sich vor Stagefright zu schützen, aber Sie können Ihre Chancen nutzen, um die Wahrscheinlichkeit eines erfolgreichen Angriffs zu verringern, wenn Sie auf einem älteren Android-Build feststecken. Es gibt auch benutzerdefinierte ROM-Lösungen, bei denen die meisten Quellen regelmäßig mit AOSP synchronisieren und daher die Stagefright-Korrekturen enthalten. Wenn Sie ein AOSP-basiertes ROM verwenden, wird dringend empfohlen, auf eine neuere Version des ROM zu aktualisieren, die die Stagefright-Patches enthält. Sie können verwenden diese App um zu prüfen, ob Ihr aktueller Daily Driver von Stagefright betroffen ist.

Android, Post-Stagefright

Stagefright war nichts anderes als ein Weckruf gegenüber Android und seinem Problem der Fragmentierung und Updates. Es verdeutlicht, dass es keinen klaren Mechanismus gibt, mit dem solche kritischen Korrekturen zeitnah auf zahlreichen Geräten bereitgestellt werden können. Während OEMs versuchen, Patches für Geräte bereitzustellen, ist die harte Wahrheit, dass die meisten dieser Korrekturen nur auf aktuelle Flaggschiffe beschränkt sein werden. Andere Nicht-Flaggschiffe und ältere Geräte, geschweige denn von kleineren OEMs, werden weiterhin Stagefright ausgesetzt sein.

Dieser Exploit hat einen Lichtblick: Es hat die Aufmerksamkeit erneut auf den Update-Prozess von Android gelenkt und ihn in ein Licht gerückt, das nicht so viele zukünftige Unternehmen dazu bewegen wird, Android für den Unternehmenseinsatz einzuführen. Während Google auf eine stärkere Akzeptanz in Unternehmen hinarbeitet, wird das Unternehmen gezwungen sein, seine Update-Strategie und den Grad der Kontrolle, den es den OEMs gewährt, zu überdenken.

Da die Markteinführung von Android M immer näher rückt, wäre es keine Überraschung, wenn Google sich dafür entscheiden würde, immer mehr Komponenten von AOSP zugunsten seines Play-Services-Pakets abzuspalten. Schließlich ist dies ein Bereich, über den Google weiterhin die volle Kontrolle behält, wenn ein Gerät mit dem Google Play Store ausgeliefert werden soll. Das hat seine eigenen Nachteile in Form des Ersetzens von Open-Source-Bereichen durch Close-Source-Wände.

Bei Spekulationen über die Zukunft von Android besteht eine (sehr geringe) Möglichkeit, dass Google auch die Änderungen, die OEMs an AOSP vornehmen können, einschränkt. Mit dem RRO-Framework Da es in Android M in einem funktionsfähigen Zustand vorhanden ist, könnte Google OEMs einschränken, nur kosmetische Änderungen in Form von RRO-Skins vorzunehmen. Dies sollte eine schnellere Bereitstellung von Updates ermöglichen, würde jedoch dazu führen, dass OEMs die Möglichkeit verwehrt wird, Android vollständig anzupassen.

Ein weiterer möglicher Weg wäre, dies für alle im Lieferumfang enthaltenen Geräte verbindlich vorzuschreiben Google Play Store, um garantierte Sicherheitsupdates für einen festgelegten Zeitraum, möglicherweise zwei, zu erhalten Jahre. Das Play Services-Framework könnte verwendet werden, um zu prüfen, ob wichtige Sicherheitsupdates und -patches vorhanden sind, wobei der Zugriff auf den Play Store im Falle einer Nichteinhaltung widerrufen wird.

Schlussbemerkungen

Dies ist bestenfalls noch Spekulation, da es keine elegante Möglichkeit gibt, dieses Problem zu beheben. Abgesehen von einem sehr totalitären Ansatz wird es immer einige Mängel bei der Reichweite von Lösungen geben. Aufgrund der großen Anzahl an Android-Geräten wäre es eine gigantische Aufgabe, den Sicherheitsstatus jedes einzelnen Geräts im Auge zu behalten. Das Gebot der Stunde ist ein Umdenken bei der Art und Weise, wie Android-Updates durchgeführt werden, da die aktuelle Art und Weise sicherlich nicht die beste ist. Wir bei XDA Developers hoffen, dass Android weiterhin seinen Open-Source-Wurzeln treu bleibt und gleichzeitig mit den Closed-Source-Plänen von Google zusammenarbeitet.

Ist Ihr Telefon anfällig für Stagefright? Glauben Sie, dass Ihr Telefon jemals einen Stagefright-Patch erhalten wird? Lass es uns unten in den Kommentaren wissen!