Forscher zeigt zwei OxygenOS-Versagen in OnePlus 15, die root mit lokaler App ermöglichen

Ein Sicherheitsforscher Rasmus Moorats hat gezeigt, dass ein OnePlus 15 mit der neuesten Version von OxygenOS vollständig von einer bösartigen Anwendung genommen werden kann, die der Eigentümer freiwillig installiert, auch wenn diese App keine speziellen Genehmigungen anfordert. Moorats kettete zwei Fehler in OnePluss eigener Software, um Privilegien zu erhöhen - die höchste Kontrolle auf einem Android-Handy - und veröffentlichte seine Ergebnisse am 24. September nach mehreren Monaten der Kommunikation mit dem Unternehmen. OnePlus bestätigte im Mai die Existenz der beiden Schwachstellen und erklärte, dass ähnliche Probleme mehr seiner Modelle und andere von OPPO beeinflussen, obwohl es nicht identifiziert, welche.

In technischer Hinsicht verwendet die Betriebskette zwei vorinstallierte OxygenOS-Dienste. Der erste ist AtlasService, ein Dienst, der Debugging-Daten sammelt und nach Moorats mit Root-Privilegien läuft und Anrufe von jeder Anwendung akzeptiert, ohne die Identität des Anrufers zu überprüfen. Eine eigens gebaute Anfrage erreicht ein Reinigungswerkzeug, das die von der Anwendung bereitgestellten Texte aufnimmt und ohne Sanitation in einen Systembefehl einfügt. Dieser Fehler allein gibt Root-Privilegien in einem Bereich des Systems namens Zustand; es ist eine funktionelle, aber begrenzte Wurzel. Der zweite Ausfall ist unabhängig und komplementär: ein Hardware-Service namens olc2, der eine Schnittstelle zur Ausführung von Shell-Befehlen bietet. Ihre einzige Barriere ist zu überprüfen, dass der Anrufer bereits Root-Privilegien hat. Mit der ersten Schwachstelle erhalten Sie diese Wurzel im Zustand, und mit dem zweiten führen Sie einen Befehl in einem Kontext, der Low-Level Linux Privilegien gewährt, einschließlich der Möglichkeit, Code im Kernel zu laden. Das Endergebnis ist die Systemebenensteuerung über das Gerät.

Es ist wichtig zu beachten, dass der Angriff lokal ist: benötigt, dass die schädliche Anwendung installiert und läuft auf dem Telefon; es kann nicht remote über das Internet ohne lokale Interaktion gestartet werden. Die Bedingungen für den Start der Operation sind jedoch minimal: Nach Angaben des Forschers verlangt er keine speziellen Genehmigungen oder gibt dem Benutzer eine Mitteilung, und es hat ohne Änderungen an einem seriellen Telefon gearbeitet.

Die Tatsachen, die in der Chronologie von Moorats bestätigt wurden, sind klar: Die erste Mitteilung an OnePlus war 18. April; das Unternehmen bestätigte die Mängel am 20. Mai und in dieser Mitteilung erklärte, dass es die Offenlegung kontrollieren würde und dass die Veröffentlichung ohne ihre Zustimmung rechtliche Verantwortung tragen könnte. OnePlus berichtete, dass es eine Korrektur planen würde, bat Moorats zu halten und gab ihm ein Datum, bis er nicht veröffentlicht; wenn dieses Datum kam und es keine öffentliche Anordnung, Moorats veröffentlicht am 24. September. Zum Zeitpunkt der Offenlegung gab es laut seinem Konto keinen zugewiesenen CVE oder Patch zur Verfügung. Moorats reproduzierte auch die Kette in einem OnePlus 12 Pro und schätzt, dass das Problem in der Regel OxygenOS 16 betrifft; OnePlus und OPPO teilen eine Softwarebasis, die die Abdeckung zwischen Marken erklären würde.

Was mit Sicherheit bekannt ist und was nicht ist: es wird bestätigt, dass Moorats gefunden und kombiniert zwei Fehler in OxygenOS-Dienste, die es ermöglichen, zu root zu klettern, wenn eine bösartige App installiert ist. Es wird auch bestätigt, dass OnePlus informiert wurde, die Fehler im Mai erkannt und über die Offenlegung warnte. Es wird bestätigt, dass es laut Moorats bis zum Datum seiner Veröffentlichung keinen öffentlichen Beweis für die Ausbeutung in der realen Welt gibt. Was den genauen Umfang der betroffenen Geräte und Patch-Daten betrifft, bleibt dies unsicher: OnePlus hat keine Liste von Modellen oder einen öffentlichen technischen Hinweis veröffentlicht, noch hat es einen überprüfbaren Korrekturplan zum Zeitpunkt der Offenlegung gegeben.

Die praktischen Konsequenzen für Benutzer und Administratoren sind im Bedrohungsmodell dieses Fehlers klar: Ein Angreifer muss den Besitzer nur überzeugen oder täuschen, eine Anwendung lokal zu installieren - zum Beispiel durch Sideload, ein Anhängepaket oder einen Link, um außerhalb der offiziellen Stores zu installieren - und diese App kann ruhig auf Root erhöht werden, ohne um Erlaubnis zu bitten. Mit root und der Fähigkeit, Kernelcode zu laden, kann ein Angreifer tiefe Beharrlichkeit installieren, Sicherheitskontrollen deaktivieren, Zugriffsdaten im Speicher verschlüsselt und seine Anwesenheit verbergen. In Unternehmensumgebungen, die dem Verlust der Kontrolle des Gerätes und potenziellen Zugriff auf die Systeme des Unternehmens gleichwertig sind, wenn das Telefon zur Authentifizierung oder E-Mail verwendet wird.

Die eigentliche Schwierigkeit, diesen Vektor auszunutzen, ist im ersten Schritt: die Installation der bösartigen App. Bis Lieferanten Patches veröffentlichen und bereitstellen, die praktische und effektive Verteidigung für Endbenutzer ist, die Installation von Anwendungen auf Quellen von Vertrauen zu beschränken. Vermeiden Sie Sideload, installieren Sie APKS nicht von Dritten und verwenden Sie offizielle Schutz-Shops (wie Google Play with Play Protect) deutlich reduziert das Risiko. Die von Moorats beschriebene Kette blüht nicht ohne eine lokale App installiert.

Spezifische und überprüfbare Empfehlungen für Nutzer:

1) Nicht installieren Anwendungen außerhalb offizieller Läden und, falls erforderlich, die Herkunft und Unterschrift der APK überprüfen. Deaktivieren Sie die Installation von "unbekannten Ursprüngen" in Systemeinstellungen, wenn nicht erforderlich. 2) Halten Sie USB-Debugging deaktiviert, wenn nicht aktiv verwendet und überwachen angeschlossene Geräte: offene Debugging erleichtert die Installation unerwünschter Software. 3) regelmäßig installierte Apps überprüfen (Einstellungen → Anwendungen) und entfernen Sie alles, was Sie nicht erkennen; verwenden Sie Reputationstools wie Google Play Protect. 4) Sichern und pflegen Sie ein aktuelles Bild von wichtigen Daten, falls eine Fabrikrestauration erforderlich ist. 5) Für Unternehmen: Umsetzung von MDM-Richtlinien, die die Installation von nicht genehmigten Apps blockieren und Entwicklermodi auf Unternehmensgeräten einschränken.

Für Forscher und Sicherheitsexperten führt der Fall auch zu einer Diskussion über verantwortungsvolle Offenlegungspraktiken. OnePlus erklärte, dass die endgültige Entscheidung über die Verwundbarkeitserklärung ihr entspricht - eine Position, die Moorats in seinem Austausch wiederholte und die die Gefahr rechtlicher Handlungen verursachte, wenn sie veröffentlichte - und dass europäische Normen die Annahme und Korrektur von Berichten erfordern, aber die Offenlegung von Forschern ohne Zustimmung des Herstellers nicht zulassen würden. Diese Rechtsinterpretation ist umstritten unter der Sicherheitsgemeinschaft, die oft eine koordinierte Offenlegung mit angemessenen Fristen befürwortet, wenn der Lieferant keine Patches anwendet. Zur Beratung über gute Outreach-Praktiken gibt es öffentliches Material von Agenturen wie ENISA: ENISA - Coordinated Vulnerability Disclosure, und für technische Aspekte von Android und Sicherheitsabwehr ist die offizielle Dokumentation verfügbar: Android Security - source.android.com.

Schließlich, wenn Sie denken, Ihr OnePlus oder OPPO-Gerät kann beeinträchtigt werden oder installiert zweifelhafte Anwendungen, betrachten Sie die Neuinstallation des Systems aus dem offiziellen Bild oder die Wiederherstellung von Fabrikwerten und, wenn möglich, warten auf die Anzeige des Herstellers und Patch vor der Neuinstallation von Anwendungen außerhalb des offiziellen Speichers. Es ist auch ratsam, offizielle OnePlus-Kanäle für eine Sicherheits- und Patch-Benachrichtigung im Auge zu behalten: Das Unternehmen verfügt über eine Support-Website und Sicherheitsrichtlinien, in denen Aktualisierungen und Minderungsverfahren veröffentlicht werden sollten - zum Beispiel sein Sicherheitszentrum oder technische Unterstützung - OnePlus Support und Sicherheit.

Der Fall zeigt eine wiederkehrende Realität auf Android-Geräten mit Herstellerschichten: jeder zusätzliche Code mit hohen Privilegien multipliziert die Angriffsfläche. Bis Lieferanten Korrekturen und Listen von betroffenen Modellen veröffentlichen, ist die beste Verteidigung die digitale Hygiene des Benutzers und, für Organisationen, technische Richtlinien, die Anlagen und Privilegien begrenzen.