Bromite: Verwenden Sie Patches des AndroidHardening-Projekts

Ich habe diese Patches noch einmal überprüft, die meisten davon sind in anderen Patchsets enthalten, die von Bromite verwendet werden, oder mit anderen Patches bedeckt; Die 64-Bit-Patches (1. und 2.) sind keine gute Idee, und es wird auf dem Issue Tracker erklärt, warum.

Was diesen Patches im Allgemeinen fehlt, ist eine Begründung für die Änderungen, da es nur eine Betreffzeile gibt.

Ich habe 5 für eine mögliche Aufnahme in die nächste Veröffentlichung ausgewählt, obwohl die Auswirkungen minimal sind.

Behoben in 71.0.3578.132 (noch nicht veröffentlicht).

Der Großteil der Änderungen ist dort derzeit nicht enthalten, da sie nicht für die neuesten Versionen aktualisiert werden. Es enthält derzeit nicht die letzte Härtung, und vieles davon wird auch außerhalb des Repositorys über die gehärtete Toolchain und das Basisbetriebssystem durchgeführt. Es ist vorerst nur ein Platzhalter mit minimalen Änderungen. Das Deaktivieren von Feldversuchen reduziert die Invasivität der für die Grundlagen erforderlichen Änderungen erheblich, da das Festlegen von Standardoptionen tatsächlich richtig funktioniert und eine Reihe fragwürdiger Dinge nie aktiviert werden.

Der Grund für die Bevorzugung von 64-Bit-Prozessen ist die Bereitstellung wesentlich besserer Exploit-Abwehrmaßnahmen auf Kosten einer geringfügig höheren Speicherauslastung. Zusätzlich zu den Standardminderungen ermöglicht es auch die Verwendung von https://github.com/AndroidHardening/hardened_malloc, das vom Basisbetriebssystem bereitgestellt wird.

Ohne den gehärteten Allocator, libc-Änderungen und Toolchain-Änderungen ist es offensichtlich nicht dasselbe.

Der Großteil der Änderungen ist dort derzeit nicht enthalten, da sie nicht für die neuesten Versionen aktualisiert werden. Es enthält derzeit nicht die letzte Härtung, und vieles davon wird auch außerhalb des Repositorys über die gehärtete Toolchain und das Basisbetriebssystem durchgeführt. Es ist vorerst nur ein Platzhalter mit minimalen Änderungen.

Danke für die Erklärung @thestinger; Mein einziger Verbesserungsvorschlag wäre, die Git-Commit-Nachricht mit einer Begründung für die Patch-Änderungen zu erweitern.

Ich habe derzeit nicht vor, wegen des damit verbundenen Mehraufwands auf eine gehärtete Toolchain umzusteigen; Außerdem wird die Standard-Toolchain derzeit (hoffentlich auch auf Sicherheitsprobleme) auf den von Chrome/Chromium verwendeten Android-Versionen getestet, und ich halte das für einen Vorteil.

Gibt es einen anderen Speicherort für die neuesten Chromium-Patches, den man sich ansehen sollte? (Angesichts der Tatsache, dass einige / die meisten von ihnen nur mit einem gehärteten Kernel / einer gehärteten Toolchain sinnvoll sein könnten).

Der Grund für die Bevorzugung von 64-Bit-Prozessen ist die Bereitstellung wesentlich besserer Exploit-Abwehrmaßnahmen auf Kosten einer geringfügig höheren Speicherauslastung. Zusätzlich zu den Standardminderungen ermöglicht es auch die Verwendung von https://github.com/AndroidHardening/hardened_malloc, das vom Basisbetriebssystem bereitgestellt wird.

Ohne den gehärteten Allocator, libc-Änderungen und Toolchain-Änderungen ist es offensichtlich nicht dasselbe.

Glauben Sie, dass dieser Patch auf nicht gehärtetem Android von Nutzen sein könnte? Würde ein 64-Bit-Prozess beispielsweise, wenn er mit dem Standard-Chromium-SDK und der Standard-Toolchain kompiliert wurde, von besseren Exploit-Abwehren auf beispielsweise ARM64 profitieren?

Für die Aufzeichnungen sind die Patches, die beim Schließen dieses Problems enthalten waren, hier: https://github.com/bromite/bromite/commit/d5dede3dfac5b3cf553a326808d3a66dc65fdb8a

(Andere Patches waren bereits vorhanden, andere nicht zutreffend)

-fwrapv und -fstack-protector-strong funktionieren bereits mit der standardmäßigen Chromium-Toolchain, daher hinken ihre TODOs jetzt etwas hinterher (jemand könnte einen Upstream-Patch vorschlagen); damals nahm ich mir einige Zeit, um den Unterschied zwischen --param=ssp-buffer-size=4 , -fstack-protector-strong und -fstack-protector-all zu studieren, interessante Lektüre.

Ich habe derzeit nicht vor, wegen des damit verbundenen Mehraufwands auf eine gehärtete Toolchain umzusteigen; Außerdem wird die Standard-Toolchain derzeit (hoffentlich auch auf Sicherheitsprobleme) auf den von Chrome/Chromium verwendeten Android-Versionen getestet, und ich halte das für einen Vorteil.

Ich verwende die offiziell getesteten Toolchains mit Härtung, also gibt es eine für Android und eine für Chromium. Einige davon beinhalten benutzerdefinierte Patches, während andere Teile jetzt zurückportiert oder einfach mit benutzerdefinierten Kompilierungsschaltern aktiviert werden können. Sie sind kurz davor, eine Teilmenge von CFI auf Android standardmäßig zu aktivieren, wie auf x86_64-Linux, aber ansonsten muss sie nachgeschaltet aktiviert werden.

Glauben Sie, dass dieser Patch auf nicht gehärtetem Android von Nutzen sein könnte? Würde ein 64-Bit-Prozess beispielsweise, wenn er mit dem Standard-Chromium-SDK und der Standard-Toolchain kompiliert wurde, von besseren Exploit-Abwehren auf beispielsweise ARM64 profitieren?

Es bietet ASLR mit hoher Entropie (24-Bit bis 32-Bit, je nachdem, ob der Kernel Seitentabellen mit 3 oder 4 Ebenen anstelle von 16-Bit für 32-Bit-Prozesse verwendet), Stack-Canaries mit hoher Entropie (56/64-Bit statt 24/32-Bit, je nachdem, ob ein Null-Byte verwendet wird) und auch Features wie Pointer-Authentifizierung und Memory-Tagging, wenn diese in Zukunft zur Verfügung gestellt werden.

Der Grund, warum sie begannen, 32-Bit-Prozesse zu bevorzugen, ist, Speicher zu sparen, zumal die Einsparung von Speicher es möglich macht, feinkörnigeres Sandboxing zu verwenden. Da ich weiß, dass die Geräte, die ich anvisiere, über viel Speicher verfügen, ist es kein Problem, für diese Prozesse einen um etwa 10 % höheren Speicherverbrauch zu haben.

Ebenso ist es möglich, die Funktion „Strenge Site-Isolierung“ zu aktivieren, um eine wesentlich bessere Sandboxing-Funktion zu erzielen und jede Site voneinander zu isolieren, anstatt nur den Inhalt als Ganzes vom System zu isolieren. Die Kosten sind eine erhöhte Speicherauslastung und können für einige Websites, die sehr viel Iframes verwenden, erheblich sein. Ich werde dies wahrscheinlich in naher Zukunft standardmäßig aktivieren, genau wie ich die WebView-Sandbox ein paar Jahre vor ihrer standardmäßigen Auslieferung aktiviert habe.

-fwrapv und -fstack-protector-strong funktionieren bereits mit der standardmäßigen Chromium-Toolchain, daher hinken ihre TODOs jetzt etwas hinterher (jemand könnte einen Upstream-Patch vorschlagen); Damals nahm ich mir einige Zeit, um den Unterschied zwischen --param=ssp-buffer-size=4, -fstack-protector-strong und -fstack-protector-all zu studieren, interessante Lektüre.

Sie verwenden -fstack-protector-strong auf ChromeOS, aber noch nicht auf anderen Plattformen, da die Aktivierung einer Option abgelehnt wird, was zu ~ 1-2% geringerer Leistung und ~ 2-3% größeren Binärdateien führt. Die Größenzunahme bei Android ist ihnen sehr wichtig, da einige Geräte nur sehr wenig Speicherplatz haben. Das bedeutet auch eine geringfügig höhere Speicher-/Cache-Nutzung, jedoch nicht um die vollen 2-3%.

Die Verwendung von -fwrapv (insbesondere nur dann, wenn die Prüfung auf Überlauf mit Vorzeichen ganzer Zahlen nicht verwendet wird - da dies überschrieben wird und dazu führt, dass keine Prüfungen durchgeführt werden) ist nur gesunder Menschenverstand, da es die Möglichkeit eliminiert, dass Sicherheitsschwachstellen durch Optimierungen eingeführt werden, die auf undefinierten Vorzeichenüberläufen basieren. Das ist schon einmal passiert, und diese Optimierungen summieren sich nicht einmal zu einer Leistungssteigerung von 0,1% für diese Art von Software. Es lohnt sich nicht, es zu haben. Der Linux-Kernel übergibt -fwrapv und auch -fno-strict-aliasing, um diese gefährlichen Optimierungen zu deaktivieren (da es so viel falschen Code gibt, den sie knacken können). Tatsächlich ist es einfach, auf Dutzende von bekannten Beispielen für ungültigen Code zu verweisen, der möglicherweise durch diese Optimierungen beschädigt werden könnte. Ich glaube nicht, dass es für Projekte akzeptabel ist, Optimierungen zu verwenden, von denen bekannt ist , dass sie mit einer Menge Code in ihrem Baum beschädigt werden. Sie haben sich kaum Mühe gegeben, die bekannten Fälle auch nur zu beheben. Chromium hat Blacklists für UBsan für 'False Positives' (von denen keines wirklich False Positives ist, sondern eher "undefiniert, aber kein Fehler, der darüber hinaus möglicherweise durch Optimierungen oder sogar Codegenerierung ohne sie gebrochen wird") und auch für Komponenten, die zu voll davon sind Bugs für sie, die sich derzeit damit beschäftigen wollen. Dazu gehören eine Reihe von signierten Überlaufproblemen (es gibt leider keine Erkennung von Aliasing-Verstößen, die ziemlich häufig sind, aber nicht so häufig).

Außerdem bedeutet die Verwendung von 64-Bit, dass ein gehärteter Allocator wie https://github.com/AndroidHardening/hardened_malloc , der den 64-Bit-Adressraum nutzt, transparent verwendet wird, wenn er im Betriebssystem vorhanden ist. Also gerade jetzt, wenn es auf den AndroidHardening-Versionen läuft.

Es gibt andere verschiedene Härtungsfunktionen, die ebenfalls exklusiv für 64-Bit verfügbar sein werden, einschließlich der kommenden hardwarebasierten Pointer-Authentifizierung (ARMv8.3), Memory Tagging (ARMv8.5) und Branch Target Indicator-Funktionen (ARMv8.5).

https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf

Das Speicher-Tagging muss in erster Linie von Speicherzuordnern implementiert werden, einschließlich des System-Taggings in der libc und der verschiedenen in Chromium. Es gibt einen Abschnitt über einen großartigen Ansatz zur Verwendung in meiner README-Datei für den Allocator:

https://github.com/AndroidHardening/hardened_malloc#memory -tagging

Es fügt Tags zu den oberen Bits von Zeigern und ein Zeiger kann nur mit dem entsprechenden Tag zugewiesen, um Zugriffsspeicher verwendet werden , so ist es , dass die linearen Überlauf auf dem Heap garantiert zusammen gefangen werden , mit Garantie , dass die Verwendung-after-free innerhalb eines gefangen eine bestimmte Anzahl von Wiederverwendungen von Zuweisungsschlitzen (nach 15-16 Verwendungen für verschiedene Zuweisungen wird das Tag auf denselben Wert zurückgesetzt). Es bietet auch eine gute Chance, andere willkürliche Formen der Heap-Korruption zu erkennen. Die Verwendung innerhalb eines Speicherzuordners ist in Bezug auf die Gesamtleistung nahezu kostenlos. Vielleicht 1-2% Leistungskosten für eine größere Verbesserung. Compiler können es auch zum Schutz auf dem Stack verwenden, aber das ist wesentlich teurer.

Die Zielindikatoren für Zweigstellen sind nahezu kostenlos (wahrscheinlich unter 0,1 % der Gesamtkosten) und liefern grobkörnige CFI-Vorwärtstrends (indirekte Anrufe) als Basiswert. Clang-basiertes CFI ist viel besser, aber es ist schön, etwas zu haben, das universell ohne Kompatibilitäts- oder Leistungsprobleme angewendet werden kann. Die Aktivierung von Clang CFI ist ein langsamer und mühsamer Prozess, da alle Fehler mit undefiniertem Code in der Software behoben werden müssen.

Die Pointer-Authentifizierung ist viel weniger zwingend, da der primäre Anwendungsfall der Schutz von Rücksendeadressen ist und es bessere Ansätze gibt. Es ist eine Form des schwachen probabilistischen Rückwärts-Edge-CFI. Schöner wäre ein deterministischer Schutz und idealerweise ein vollständig präziser Schutz, wie zum Beispiel der Schutz, der von einem hardwarebasierten Shadow-Stack bereitgestellt wird.

Ich verwende die offiziell getesteten Toolchains mit Härtung, also gibt es eine für Android und eine für Chromium. Einige davon beinhalten benutzerdefinierte Patches, während andere Teile jetzt zurückportiert oder einfach mit benutzerdefinierten Kompilierungsschaltern aktiviert werden können.

@thestinger Ich konnte die für das AndroidHardening-Projekt verwendete Chromium-Toolchain nicht finden; Ich verwende derzeit die von Chromium vorgeschlagene Toolchain (https://chromium.googlesource.com/chromium/src/build/+/refs/heads/master/install-build-deps-android.sh), wenn Sie weitere Details mitteilen könnten /patches über die gehärtete Toolchain für Chromium Ich könnte eine Integration in Betracht ziehen.

Sie sind kurz davor, eine Teilmenge von CFI auf Android standardmäßig zu aktivieren, wie auf x86_64-Linux, aber ansonsten muss sie nachgeschaltet aktiviert werden.

https://bugs.chromium.org/p/chromium/issues/detail?id=469376

Es scheint aufgrund eines nicht öffentlichen Fehlers blockiert zu sein.

Ebenso ist es möglich, die Funktion „Strenge Site-Isolierung“ zu aktivieren, um eine wesentlich bessere Sandboxing-Funktion zu erzielen und jede Site voneinander zu isolieren, anstatt nur den Inhalt als Ganzes vom System zu isolieren. Die Kosten sind eine erhöhte Speicherauslastung und können für einige Websites, die sehr viel Iframes verwenden, _erheblich_ sein. Ich werde dies wahrscheinlich in naher Zukunft standardmäßig aktivieren, genau wie ich die WebView-Sandbox ein paar Jahre vor ihrer standardmäßigen Auslieferung aktiviert habe.

Es heißt jetzt --site-per-process (siehe https://bugs.chromium.org/p/chromium/issues/detail?id=497306); Ich habe auch gerade überprüft, ob es eine Option gibt, es nur für Geräte mit einer bestimmten Speicherkapazität zu aktivieren ( kSitePerProcessOnlyForHighMemoryClients , mit einer Standardeinstellung von 1024 MB), und obwohl es nicht so ist, weniger Sicherheit für Geräte mit geringerer Leistung bereitzustellen gute Praxis Ich erwäge, diese beiden Funktionen zu aktivieren.

Dazu gehören eine Reihe von signierten Überlaufproblemen (es gibt leider keine Erkennung von Aliasing-Verstößen, die ziemlich häufig sind, aber nicht _so_ üblich).

Wie ich verstehe, ermöglicht Ihr Patch -fwrapv nur für Nicht-UBSan, einen vernünftigen Kompromiss bei diesen "bekannten Problemen" der Chromium- (und/oder Komponenten-) Codebasis einzugehen?

Danke übrigens für die ausführliche Erklärung; Ich werde es dem fwrapv-Patch hinzufügen, das in

Außerdem bedeutet die Verwendung von 64-Bit, dass ein gehärteter Allocator wie https://github.com/AndroidHardening/hardened_malloc , der den 64-Bit-Adressraum nutzt, _transparent_ verwendet wird, wenn er im Betriebssystem vorhanden ist. Also gerade jetzt, wenn es auf den AndroidHardening-Versionen läuft.

Es gibt andere verschiedene Härtungsfunktionen, die ebenfalls exklusiv für 64-Bit verfügbar sein werden, einschließlich der kommenden hardwarebasierten Pointer-Authentifizierung (ARMv8.3), Memory Tagging (ARMv8.5) und Branch Target Indicator-Funktionen (ARMv8.5).

https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf

Das Speicher-Tagging muss in erster Linie von Speicherzuordnern implementiert werden, einschließlich des System-Taggings in der libc und der verschiedenen in Chromium. Es gibt einen Abschnitt über einen großartigen Ansatz zur Verwendung in meiner README-Datei für den Allocator:

https://github.com/AndroidHardening/hardened_malloc#memory -tagging

Danke für diese Links, sehr interessant; Ich hatte irgendwie erwartet, dass diese Technologie auf den Markt kommt, da ich im Laufe der Jahre ähnliche Lösungen in der Intel-Welt gesehen habe.

Was die Änderungen an Bromite angeht, ist der Umfang der Umstellung von 32bit auf 64bit einfach auf das WebView beschränkt, da ich seit einiger Zeit kein Monochrome-Release mehr baue. Ich bin mir der Popularität des Bromite SystemWebview zum Einbetten in andere ROMs bewusst, daher frage ich mich, ob diese Änderung sich negativ auf die aktuelle Benutzerbasis auswirken würde (und ich habe keine Zahlen abgesehen von Ihren Eingaben dazu); da die meisten Benutzer kein gehärtetes ROM verwenden (soweit ich weiß), würden sie nur von einer höheren Entropie in ASLR und Stack Canaries profitieren; selbst für diese kleine Verbesserung wäre ich geneigt, sie zu aktivieren.

Außerdem gibt es jetzt ein dediziertes Ziel für 64-Bit-Monochrom: https://github.com/chromium/chromium/commit/9cd17206b085f0ddd8b1911770377453339b6791

Aber kein solches Ziel für den Webview allein?

https://github.com/AndroidHardening/hardened_malloc#memory -tagging

Es fügt Tags zu den oberen Bits von Zeigern hinzu und ein Zeiger kann nur verwendet werden, um auf den Speicher zuzugreifen, wenn das entsprechende Tag zugewiesen ist, so dass es _garantiert_, dass lineare Überläufe auf dem Heap abgefangen werden und gleichzeitig garantiert wird, dass use-after-free innerhalb von a . abgefangen wird eine bestimmte Anzahl von Wiederverwendungen von Zuweisungsschlitzen (nach 15-16 Verwendungen für verschiedene Zuweisungen wird das Tag auf denselben Wert zurückgesetzt). Es bietet auch eine gute Chance, andere willkürliche Formen der Heap-Korruption zu erkennen. Die Verwendung innerhalb eines Speicherzuordners ist in Bezug auf die Gesamtleistung nahezu kostenlos. Vielleicht 1-2% Leistungskosten für eine größere Verbesserung. Compiler können es auch zum Schutz auf dem Stack verwenden, aber das ist wesentlich teurer.

Die Zielindikatoren für Zweigstellen sind nahezu kostenlos (wahrscheinlich unter 0,1 % der Gesamtkosten) und liefern grobkörnige CFI-Vorwärtstrends (indirekte Anrufe) als Basiswert. Clang-basiertes CFI ist viel besser, aber es ist schön, etwas zu haben, das universell ohne Kompatibilitäts- oder Leistungsprobleme angewendet werden kann. Die Aktivierung von Clang CFI ist ein langsamer und mühsamer Prozess, da alle Fehler mit undefiniertem Code in der Software behoben werden müssen.

@thestinger haben Sie in Erwägung gezogen, einen Teil dieser Arbeit Project Zero in Kontakt stehen oder standen?
Ich würde mir gehärtete Speicherzuweisungen als heißes Thema vorstellen, das von Android-Kernentwicklern, dem Android-Sicherheitsteam, den Fuchsia-Teams und den Project Zero-Mitarbeitern diskutiert / diskutiert wird.

@thestinger Ich konnte die für das AndroidHardening-Projekt verwendete Chromium-Toolchain nicht finden; Ich verwende derzeit die von Chromium vorgeschlagene Toolchain (https://chromium.googlesource.com/chromium/src/build/+/refs/heads/master/install-build-deps-android.sh), wenn Sie weitere Details mitteilen könnten /patches über die gehärtete Toolchain für Chromium Ich könnte eine Integration in Betracht ziehen.

Der Großteil meiner Arbeit wurde noch nicht für die aktuellen Versionen von Chromium und Android wiederhergestellt. Ich teste einige meiner früheren Toolchain-Härtung lokal, aber sie wird noch nicht für meine öffentlichen Veröffentlichungen verwendet. Die meisten meiner Änderungen befinden sich noch in alten Tags auf https://github.com/AndroidHardeningArchive (nur eine Teilmenge war in der neuesten Oreo-Version der alten Inkarnation meiner Arbeit) oder in lokalen Zweigen / Tags.

Ich bin mir nicht sicher, inwieweit Sie wissen, was passiert ist, als mein Geschäftspartner die vorherige Inkarnation des Projekts langsam korrumpierte und von den Open-Source-Wurzeln entfernte, bevor er sich schließlich entschied, mich komplett zu verarschen. Ich mache es jetzt alleine mit der ausdrücklichen Entscheidung, nie ein Geschäft in diesem Umfang zu engagieren. Es werden meine Projekte sein, ohne dass viel Vertrauen oder Verantwortung in andere Menschen gelegt wird. Ich arbeite daran, Gelder für die Projekte zu bekommen und das Entwicklungsteam über mich hinaus zu erweitern, da es sich um ein sehr breites Projekt mit vielen Bereichen handelt, die tiefe, komplexe Arbeit erfordern. Es wird jedoch viel anders sein als zuvor, mit allem, was permissiv lizenziert (MIT) ist, außer dem Kernel, der GPL2 sein muss, und die Unternehmen, die beteiligt sind, vom Projekt fernhalten und ihm in keiner Weise erheblichen Schaden zufügen können darüber hinaus, Ressourcen oder Entwicklungszeit nicht mehr beizusteuern. Dies alles bedeutet jedoch, dass die Arbeit um viele Jahre zurückversetzt wurde und ich viel Zeit brauche, um langsam die gleichen Veränderungen wie zuvor zusammenzufügen.

Die Hauptmerkmale sind eine bessere Implementierung eines Stack-Canaries und eine Funktion zum Nullinitialisieren aller nicht initialisierten lokalen Variablen.

Die verbesserten Stack-Canarys funktionieren, indem sie ein XOR des Zufallswerts für den Canary mit der Rücksendeadresse durchführen, bevor der Canary-Wert geschrieben wird. Bevor der Canary-Wert überprüft und zurückgegeben wird, führt es das XOR erneut durch, sodass der Canary nicht übereinstimmt, wenn der Rückgabewert während des Funktionsaufrufs überschrieben wurde. Auf arm / arm64 funktioniert der Rückgabezeigerschutz auch besser als x86, da sie ein Linkregister verwenden, sodass die Rückgabeadresse nach dieser Überprüfung, aber vor der Rückkehr nicht von einem anderen Thread überschrieben werden kann (ein winziges Zeitfenster, aber es existiert auf x86 und kann über ein Rennen von anderen Threads ausgenutzt werden, mit einer ausreichenden Erfolgsaussicht, damit es zuverlässig funktioniert, solange der Angriff mit einer angemessenen Geschwindigkeit wiederholt werden kann). Ich habe nicht vor, dies vorzuladen, da es schwierig wäre und es bessere Ansätze wie Shadow-Stacks gibt, idealerweise mit Hardware-Unterstützung, um Umgehungen zu vermeiden. Eine frühe Version davon wurde unter https://gist.github.com/thestinger/b8502a881d871fbc75d91bc00576157b veröffentlicht, aber seitdem wesentlich verbessert, insbesondere für arm64. Ich habe es jedoch noch nicht auf die neueren LLVM-Versionen portiert, die von den aktuellen Versionen von LLVM und Android verwendet werden.

Ich habe mitgeholfen, die Null-Initialisierungsfunktion voranzutreiben, die stromaufwärts in LLVM implementiert wird, und das war erfolgreich. In Zukunft wird es in der Standard-Chromium-Toolchain verfügbar sein und muss nur in ihrer Build-Konfiguration aktiviert werden.

Es scheint aufgrund eines nicht öffentlichen Fehlers blockiert zu sein.

Bei den Blockern handelt es sich im Allgemeinen um gefundene Fehler, daher handelt es sich manchmal um Sicherheitsprobleme, die immer nicht öffentlich sind, bis sie dazu kommen, sie zu öffnen, was sie manchmal vergessen. Sie haben manchmal aus anderen Gründen nicht öffentliche Probleme, insbesondere solche, die mit neuen Android-Versionen verbunden sind, da sie in der Vergangenheit lange versucht haben, sie geheim zu halten, aber ich glaube nicht, dass dies hier der Fall ist.

Es heißt jetzt --site-per-process (siehe https://bugs.chromium.org/p/chromium/issues/detail?id=497306); Ich habe auch gerade überprüft, ob es eine Option gibt, es nur für Geräte mit einer bestimmten Speichermenge zu aktivieren (kSitePerProcessOnlyForHighMemoryClients, mit einer Standardeinstellung von 1024 MB), und obwohl es keine gute Vorgehensweise ist, weniger Sicherheit für Geräte mit geringerer Leistung bereitzustellen, ziehe ich es in Betracht beide Funktionen aktivieren.

Ja, das Prozessmodell wird Site-per-Process genannt, aber die Funktion, die die Sicherheit bietet, wird immer noch als Site-Isolation bezeichnet und Android hat immer noch "Strict Site Isolation" als chrome://flags- Eintrag.

Wie ich verstehe, ermöglicht Ihr Patch -fwrapv nur für Nicht-UBSan, einen vernünftigen Kompromiss bei diesen "bekannten Problemen" der Chromium- (und/oder Komponenten-) Codebasis einzugehen?

Danke übrigens für die ausführliche Erklärung; Ich werde es dem fwrapv-Patch hinzufügen, das in Bromite verwendet wird.

Idealerweise könnte -fwrapv immer übergeben werden, aber leider hat die Art und Weise, wie es implementiert ist, dumme Interaktionen mit anderen Schaltern. Der Grund, warum es immer noch Sinn machen würde, es zu bestehen, ist, dass sie aufgrund ihrer UBSan-Blacklists weit davon entfernt sind, eine vollständige Abdeckung zu erreichen, sodass -fwrapv immer noch besser wäre als nichts, wo es nicht verwendet wird.

Hier ist ein Beispiel für ein Programm, bei dem der Compiler das Verhalten aufgrund der Optimierung aktiv ändert, basierend auf der Annahme, dass ein vorzeichenbehafteter Integer-Überlauf garantiert nie auftritt:

#include <stdio.h>
#include <limits.h>

int x1(int x) { return (x + 1) > x; }

int x2(int x) { return (x - 1) > x; }

int x3(int x) { return (x + 1) < x; }

int x4(int x) { return (x - 1) < x; }

int main(void) {
  printf("%d %d %d %d\n", x1(INT_MAX), x2(INT_MAX), x3(INT_MAX), x4(INT_MAX));
  printf("%d %d %d %d\n", x1(INT_MIN), x2(INT_MIN), x3(INT_MIN), x4(INT_MIN));
  return 0;
}

clang -O0 p2.c && /a.out produziert:

0 0 1 1
1 1 0 0

clang -O2 p2.c && /a.out erzeugt ein anderes Ergebnis, da es auf der Grundlage der Annahme optimiert wurde, dass ein Überlauf nicht in einer Weise auftreten kann, die das Programmverhalten verändert:

1 0 0 1
1 0 0 1

Dies kann durch Entfernen falsch , aber immer noch wichtige Sicherheitskontrollen wie etwa die Überprüfung für signierten Integer - Überlauf eine Schwachstelle einführen , nachdem es aufgetreten ist schon was sehr häufig ist.

Durch Hinzufügen von -fwrapv wird ein Überlauf mit Vorzeichen definiert, wodurch das Ergebnis von -O0 unabhängig von der Optimierungsstufe konsistent bereitgestellt wird. Beachten Sie, dass es auch nicht garantiert ist, dass -O0 es nicht kaputt macht. Es funktioniert einfach nicht, für ein Beispiel wie dieses.

Nun, um zu erfahren, warum ich -fwrapv wenn UBSan verwendet wird: Da Clang den Überlauf von ganzen Zahlen mit Vorzeichen wohldefiniert macht, deaktiviert Clang die UBSan-Prüfungen auf Überlauf von ganzen Zahlen mit Vorzeichen, auch im produktionsorientierten Einfangmodus, der zum Härten verwendet wird.

Kompilieren Sie dasselbe Programm wie folgt und führen Sie es aus: clang -fsanitize=undefined p2.c && ./a.out . Es erkennt das Problem und protokolliert es, da dies der UBSan-Debugging-Modus mit einer Debugging-Laufzeit ist. Es kann über eine Umgebungsvariable auf Abbruch eingestellt werden. Wenn Sie jedoch -fwrapv als zusätzlichen Schalter übergeben, wird es klar definiert und es wird nicht abgefangen. Das macht Sinn für -fsanitize=undefined . Es macht keinen Sinn für -fsanitize=integer , das sowohl die Prüfung auf vorzeichenlose als auch vorzeichenbehaftete Ganzzahlen aktiviert. Unsigned Integer-Überlaufprüfungen sind anfangs bereits gut definiert, aber sie führen nur dann vorzeichenlose Überlaufprüfungen durch, wenn -fwrapv übergeben wird, um einen Vorzeichenüberlauf ähnlich gut definiert zu machen. Das gilt auch, wenn Sie gezielt nach -fsanitize=signed-integer-overflow fragen.

Der Produktionseinsatz der UBSan Desinfektionsmittel erfolgt wie folgt: clang -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow p2.c && ./a.out . Dadurch wird es zur Laufzeit abgefangen und die Debugging-Laufzeit vermieden, die eine Menge zusätzlicher potenziell ausnutzbarer Angriffsfläche, Komplexität und Code-Aufblähung hinzufügt.

@thestinger haben Sie in Erwägung gezogen, einen Teil dieser Arbeit
Ich würde mir gehärtete Speicherzuweisungen als heißes Thema vorstellen, das von Android-Kernentwicklern, dem Android-Sicherheitsteam, den Fuchsia-Teams und den Project Zero-Mitarbeitern diskutiert / diskutiert wird.

Ich habe in der Vergangenheit eine beträchtliche Menge vorgeschaltet, aber ich überlebe die Zeit, um es weiter zu machen. Mein Kontakt zu diversen vorgelagerten Projekten, Sicherheitsforschern bei Project Zero etc. wurde durch die Geschehnisse mit meinem ehemaligen Geschäftspartner drastisch zurückgeworfen. Er übernahm mein Twitter-Konto, das die wichtigste Art war, mit der Sicherheits-Community zu interagieren, und ich verlor den Zugriff auf meine geschäftlichen E-Mails. Er hat sogar absichtlich alle Umleitungen von den alten Repository-Standorten zu den neuen unter https://github.com/AndroidHardening und https://github.com/AndroidHardeningArchive abgebrochen, sobald er die Gelegenheit dazu hatte. Es gab auch einen Angriff auf mein Reddit-Konto, wodurch ich den Zugriff dauerhaft verlor. Sie spammten falsche Berichte von Sockpuppet-Konten und erreichten erfolgreich ein Verbot für das Posten einer öffentlichen Firmen-E-Mail-Adresse, die sie fälschlicherweise als Veröffentlichung persönlicher Informationen darstellten. Reddit hat noch auf meine Anfragen zur Überprüfung geantwortet, daher habe ich die Möglichkeit verloren, die Community dort zu moderieren und sie ordnungsgemäß in eine neue mit einem klebrigen Thread zu migrieren und die Erstellung neuer Threads zu sperren.

Er verbrachte auch viel Zeit damit, Fehlinformationen über das, was passiert ist, zu verbreiten und die Leute davon abzuhalten, mich einfach zu kontaktieren, zu wissen, was wirklich passiert ist oder sogar zu bemerken, dass sich überhaupt etwas geändert hat. Er ließ es so aussehen, als ob das Projekt ins Stocken geraten und sterben würde, anstatt es ohne die Einmischung und Beteiligung des Unternehmens fortzusetzen, das es nie besessen oder kontrolliert hatte, da es als unabhängiges Open-Source-Projekt aufgesetzt war, von dem das Unternehmen ausging unterstützen (wobei es wirklich andersherum war).

Jedenfalls ist alles um Jahre zurückgeworfen, vor allem was die Einbindung in andere Projekte und das Upstreaming der Veränderungen angeht. Viele der Änderungen müssen von Android 6 und Android 7 auf Android 9 und bald 10 portiert werden, zusammen mit einer ähnlichen Situation für Chromium. Ich habe Mühe, genug Zeit zu finden, um alles am Laufen zu halten, ohne Hilfe und nur geringe finanzielle Unterstützung. Ich mache jedoch Fortschritte bei der Wiederherstellung, wie Sie sehen können.

Die einzigen Teile meiner Arbeit, die die Katastrophe überlebten und sofort weitergingen, waren die Auditor-App für hardwarebasierte Attestierung (https://github.com/AndroidHardening/Auditor) und der optionale Remote-Attestationsdienst, mit dem sie verwendet werden kann (https: //github.com/AndroidHardening/AttestationServer), der jetzt unter https://attestation.app/ gehostet wird https://attestation.app/about und https://attestation.app/tutorial. Die Entwicklung wurde definitiv verlangsamt und gestört, aber dank dieser unabhängigen Apps konnte ich die Entwicklung fortsetzen. Die gehärtete Chromium-Arbeit ist eng mit der gehärteten Toolchain und der Arbeit des Betriebssystems verbunden und ich konnte sie nicht am Laufen halten. Es gab auch noch nie Releases außerhalb des Betriebssystems, zumal ein Teil der damit verbundenen Härtung damit zu tun hat, System-Apps (einschließlich Chromium) daran zu hindern, Code außerhalb verifizierter Partitionen über ART- und SELinux-Änderungen auszuführen.

Die Toolchain-Härtung besteht aus diesen benutzerdefinierten Funktionen (XOR-Canaries, Null-Initialisierung) zusammen mit der Aktivierung zusätzlicher Schalter (die Null-Initialisierung sollte so bald verfügbar sein) wie -fwrapv, -fstack-overflow-strong und auch die Verwendung einiger der produktionsorientierten Desinfektionsmittel im Fangmodus. Die grundlegende CFI-Funktion sollte von Google bald fertiggestellt werden, und ihre leistungsbasierten Blacklists können deaktiviert werden, um etwas Leistung für eine bessere Sicherheit zu opfern. Idealerweise könnten auch die Integer-Überlaufprüfung (zumindest Vorzeichen-Ganzzahl-Überlauf), Begrenzungsprüfung (Objektgröße, Grenzen) und andere CFI-Desinfektionsmittel (einschließlich Cast-Desinfektionsmittel) aktiviert werden. Es ist schwierig, da es so viele Fehler aufdeckt, von denen die meisten in der Praxis keine echten Sicherheitsprobleme sind grobe Blacklisting, die sie derzeit in vielen Fällen verwenden). Ich habe die Desinfektionsmittel zuvor nur in begrenztem Umfang verwendet, aber es ist schwierig zu warten. Google testet mit UBsan, und theoretisch kann es verwendet werden, aber es gibt viele subtile latente Fehler und regelmäßige Rückschritte.

Außerdem ist -fno-strict-aliasing ein ähnliches Flag wie -fwrapv einige Optimierungen deaktiviert, die oft den Code der realen Welt auf gefährliche Weise brechen, aber sie übergeben dies vorerst bereits in build/config/compiler/BUILD.gn . Es ist wichtig, dies im Auge zu behalten, falls sie den Code reparieren, der in der Praxis sehr offensichtlich bricht, und dann die Deaktivierung der Optimierung entfernen, da wahrscheinlich mehr Code vorhanden ist, der auf subtilere Weise bricht. Es ist jedoch weit weniger wahrscheinlich, dass ausnutzbare Schwachstellen verursacht werden als die Optimierungen, die auf der Annahme basieren, dass kein Vorzeichen-Integer-Überlauf auftritt, was durch -fwrapv deaktiviert wird (was es als Wrapping definiert).

@csagan5 Übrigens benötigen Sie möglicherweise https://github.com/AndroidHardening/chromium_patches/blob/pie/0005-disable-seed-based-field-trials.patch , um die lokalen Feldversuche zu deaktivieren, die einige der überschreiben interne Einstellungen. Das Übergeben von fieldtrial_testing_like_official_build = true ist wichtig und deaktiviert die Testkonfiguration, die dazu dient, den maximalen Satz experimenteller Funktionen für eine maximale Testabdeckung zu aktivieren, aber das Deaktivieren führt dazu, dass ein zufälliger Seed verwendet wird, um einen zufälligen Satz von Feldversuchen auszuwählen. Sie können in chrome://version einchecken

Ich habe auch bestätigt, dass android_64bit_browser in Chromium 73.0.3683.75 (neuester stabiler Tag für Android) ein vollständiger Ersatz für meinen 64-Bit-Monochrom-Patch ist, sodass das Build-Ziel in späteren Versionen auch ordnungsgemäß funktionieren sollte. Wie Sie jedoch erwähnt haben, wird mein Patch immer noch für das eigenständige WebView benötigt, obwohl ich dies nur für den Fall unterstütze, dass einige Organisationen benutzerdefinierte Builds ohne Chromium als Standardbrowser wünschen. Zum Beispiel möchten einige Organisationen eine gesperrte Installation nur mit ihren ausgewählten Apps und wo die Installation von Apps oder sogar das Ausführen von Code von nicht verifizierten Partitionen auf verschiedene Weise verhindert wird (über die SELinux-Richtlinie und Mount-Optionen für nativen Code und auch andere Mechanismen für interpretierte Code). In einigen dieser Fälle möchten sie keinen Browser, aber das WebView wird normalerweise immer noch für einige lokale Webinhalte und möglicherweise einige Anwendungen durch die ausgewählten Apps benötigt, sodass es nicht im Allgemeinen weggelassen werden kann.

Ich bin mir nicht sicher, inwieweit Sie wissen, was passiert ist, als mein Geschäftspartner die vorherige Inkarnation des Projekts langsam korrumpierte und von den Open-Source-Wurzeln entfernte, bevor er sich schließlich entschied, mich komplett zu verarschen. Ich mache es jetzt alleine mit der ausdrücklichen Entscheidung, nie ein Geschäft in diesem Umfang zu engagieren. Es werden meine Projekte sein, ohne dass viel Vertrauen oder Verantwortung in andere Menschen gelegt wird.

Ja, ich bin mir bewusst - obwohl ich nicht zu tief hineingelesen habe. Ich erinnere mich, dass ich ein bitteres Gefühl bei der Situation hatte und es tut mir in erster Linie leid für den menschlichen Aspekt der Situation.

Ich arbeite an der Finanzierung der Projekte

Vielleicht haben Sie Ihre Hausaufgaben diesbezüglich bereits gemacht, und abgesehen von großen öffentlichen Finanzierungspartnern könnten Sie auch Kickstarter/ BountySource in Betracht ziehen, wenn Sie dies noch nicht getan haben. Ich selbst benutze sie nicht, aber sie scheinen praktikabel zu sein.

und das Entwicklungsteam über mich hinaus zu erweitern, da es sich um ein sehr breites Projekt mit vielen Bereichen handelt, die tiefe, komplexe Arbeit erfordern.

Möglicherweise benötigen Sie dort qualifizierte Open-Source-Projekt-/Community-Management-Hilfe. Wenn die Option, selbst einer zu werden, nicht machbar ist (selbst wenn Sie qualifiziert wären, würde dies die Energie für die praktische Entwicklung verbrauchen), könnten Sie vielleicht überprüfen, ob eine dieser Qualifikationen vorhanden ist gibt es da draußen hilfe? Ich würde erwarten, dass Profis, die mit anderen mittleren/großen Open-Source-Projekten arbeiten, die idealen Kandidaten sind.

Wenn Sie über eine mögliche Zusammenarbeit sprechen möchten, können Sie mich gerne per reddit oder E-Mail kontaktieren; Ich habe möglicherweise die richtigen Integritätsanforderungen, aber andere können zu kurz kommen, einschließlich Kompetenz und Zeit.

Es wird jedoch viel anders sein als zuvor, mit allem, was permissiv lizenziert (MIT) ist, außer dem Kernel, der GPL2 sein muss, und die Unternehmen, die beteiligt sind, vom Projekt fernhalten und ihm in keiner Weise erheblichen Schaden zufügen können darüber hinaus, Ressourcen oder Entwicklungszeit nicht mehr beizusteuern.

Ich bin mir Ihrer jüngsten Verdrehungserfahrungen bewusst und möchte, dass es sich um einen isolierten Sonderfall handelt; In Zukunft liegt es an Ihnen, Methoden der Zusammenarbeit zu definieren, die Schaden vermeiden. Persönlich habe ich für dieses Projekt nur Anfragen zu Rebranding/Sponsoring/Cloud-Integrationen erhalten, die ich höflich abgelehnt habe.

Dies alles bedeutet jedoch, dass die Arbeit um viele Jahre zurückversetzt wurde und ich viel Zeit brauche, um langsam die gleichen Veränderungen wie zuvor zusammenzufügen.

Die Hauptmerkmale sind eine bessere Implementierung eines Stack-Canaries und eine Funktion zum Nullinitialisieren aller nicht initialisierten lokalen Variablen.

Die verbesserten Stack-Canarys funktionieren, indem sie ein XOR des Zufallswerts für den Canary mit der Rücksendeadresse durchführen, bevor der Canary-Wert geschrieben wird. Bevor der Canary-Wert überprüft und zurückgegeben wird, führt es das XOR erneut durch, sodass der Canary nicht übereinstimmt, wenn der Rückgabewert während des Funktionsaufrufs überschrieben wurde. Auf arm / arm64 funktioniert der Rückgabezeigerschutz auch besser als x86, da sie ein Linkregister verwenden, sodass die Rückgabeadresse nach dieser Überprüfung, aber vor der Rückkehr nicht von einem anderen Thread überschrieben werden kann (ein winziges Zeitfenster, aber es existiert auf x86 und kann über ein Rennen von anderen Threads ausgenutzt werden, mit einer ausreichenden Erfolgsaussicht, damit es zuverlässig funktioniert, solange der Angriff mit einer angemessenen Geschwindigkeit wiederholt werden kann). Ich habe nicht vor, dies vorzuladen, da es schwierig wäre und es bessere Ansätze wie Shadow-Stacks gibt, idealerweise mit Hardware-Unterstützung, um Umgehungen zu vermeiden. Eine frühe Version davon wurde unter https://gist.github.com/thestinger/b8502a881d871fbc75d91bc00576157b veröffentlicht, aber seitdem wesentlich verbessert, insbesondere für arm64. Ich habe es jedoch noch nicht auf die neueren LLVM-Versionen portiert, die von den aktuellen Versionen von LLVM und Android verwendet werden.

Ich habe mitgeholfen, die Null-Initialisierungsfunktion voranzutreiben, die stromaufwärts in LLVM implementiert wird, und das war erfolgreich. In Zukunft wird es in der Standard-Chromium-Toolchain verfügbar sein und muss nur in ihrer Build-Konfiguration aktiviert werden.

Das sieht nach wirklich coolem Zeug aus, aber ein oder zwei Stufen über meinem Niveau; Ich kann verstehen, was es tut und wie es implementiert wird, aber ich wäre nicht in der Lage, es zu überprüfen oder dazu beizutragen.
Wenn Sie alleine daran arbeiten, wäre ein weiterer Grund für das Upstreaming, dass Sie möglicherweise die verdiente Bewertung erhalten.

Ja, das Prozessmodell wird Site-per-Process genannt, aber die Funktion, die die Sicherheit bietet, wird immer noch als Site-Isolation bezeichnet und Android hat immer noch "Strict Site Isolation" als chrome://flags- Eintrag.

Ja, der Text sagt "Strict Site isolation" und ordnet enable-site-per-process :

    {"enable-site-per-process", flag_descriptions::kStrictSiteIsolationName,
     flag_descriptions::kStrictSiteIsolationDescription, kOsAndroid,
     SINGLE_VALUE_TYPE(switches::kSitePerProcess)},

Ich bestätige, dass es dasselbe ist.

Ich habe in der Vergangenheit eine beträchtliche Menge vorgeschaltet, aber ich überlebe die Zeit, um es weiter zu machen. Mein Kontakt zu diversen vorgelagerten Projekten, Sicherheitsforschern bei Project Zero etc. wurde durch die Geschehnisse mit meinem ehemaligen Geschäftspartner drastisch zurückgeworfen. Er übernahm mein Twitter-Konto, das die wichtigste Art war, mit der Sicherheits-Community zu interagieren, und ich verlor den Zugriff auf meine geschäftlichen E-Mails. Er hat sogar absichtlich alle Umleitungen von den alten Repository-Standorten zu den neuen unter https://github.com/AndroidHardening und https://github.com/AndroidHardeningArchive abgebrochen, sobald er die Gelegenheit dazu hatte.

War dies auf ein Imageproblem in der Öffentlichkeit zurückzuführen oder auf eine bloße Verwirrung über die Authentizität Ihrer Online-Identität und -Beiträge? Ich würde mir wünschen, dass Sicherheitsforscher und andere Projekte nicht die Quelle der Arbeit, sondern die Arbeit selbst so gut wie möglich beurteilen.

Es gab auch einen Angriff auf mein Reddit-Konto, wodurch ich den Zugriff dauerhaft verlor. Sie spammten falsche Berichte von Sockpuppet-Konten und erreichten erfolgreich ein Verbot für das Posten einer öffentlichen Firmen-E-Mail-Adresse, die sie fälschlicherweise als Veröffentlichung persönlicher Informationen darstellten. Reddit hat noch auf meine Anfragen zur Überprüfung geantwortet, daher habe ich die Möglichkeit verloren, die Community dort zu moderieren und sie ordnungsgemäß in eine neue mit einem klebrigen Thread zu migrieren und die Erstellung neuer Threads zu sperren.

Die im Spiel befindlichen Anreize (aus Reddit-Perspektive) werden es Ihnen schwer machen, das in irgendeiner Weise gerecht zu lösen, also würde ich diesen Aspekt zumindest vorerst aufgeben.

Er verbrachte auch viel Zeit damit, Fehlinformationen über das, was passiert ist, zu verbreiten und die Leute davon abzuhalten, mich einfach zu kontaktieren, zu wissen, was wirklich passiert ist oder sogar zu bemerken, dass sich überhaupt etwas geändert hat. Er ließ es so aussehen, als ob das Projekt ins Stocken geraten und sterben würde, anstatt es ohne die Einmischung und Beteiligung des Unternehmens weiterzuführen, das es nie besessen oder kontrolliert hatte, da es als unabhängiges Open-Source-Projekt eingerichtet wurde, das das Unternehmen _angenommen_ zu unterstützen (wobei es wirklich andersherum war).

Jedenfalls ist alles um Jahre zurückgeworfen, vor allem was die Einbindung in andere Projekte und das Upstreaming der Veränderungen angeht. Viele der Änderungen müssen von Android 6 und Android 7 auf Android 9 und bald 10 portiert werden, zusammen mit einer ähnlichen Situation für Chromium. Ich habe Mühe, genug Zeit zu finden, um alles am Laufen zu halten, ohne Hilfe und nur geringe finanzielle Unterstützung. Ich mache jedoch Fortschritte bei der Wiederherstellung, wie Sie sehen können.

Es tut mir immer noch sehr leid für den menschlichen Aspekt der ganzen Situation und zweitens für den technischen Aspekt; Ich würde wirklich hoffen, dass Sie den Schaden, den diese Situation für Sie und Ihr Vertrauen zugefügt hat, letztendlich bewältigen und verringern können.

Ich bin Ihnen sehr dankbar, dass Sie sich entschieden haben, diese Arbeit fortzusetzen – auch im Namen anderer Android-Nutzer; lass es mich wissen, wenn ich irgendwie helfen kann.

Die einzigen Teile meiner Arbeit, die die Katastrophe überlebten und sofort weitergingen, waren die Auditor-App für hardwarebasierte Attestierung (https://github.com/AndroidHardening/Auditor) und der optionale Remote-Attestationsdienst, mit dem sie verwendet werden kann (https: //github.com/AndroidHardening/AttestationServer), der jetzt unter https://attestation.app/ gehostet wird https://attestation.app/about und https://attestation.app/tutorial. Die Entwicklung wurde definitiv verlangsamt und gestört, aber dank dieser unabhängigen Apps konnte ich die Entwicklung fortsetzen. Die gehärtete Chromium-Arbeit ist eng mit der gehärteten Toolchain und der Arbeit des Betriebssystems verbunden und ich konnte sie nicht am Laufen halten. Es gab auch noch nie Releases außerhalb des Betriebssystems, zumal ein Teil der damit verbundenen Härtung damit zu tun hat, System-Apps (einschließlich Chromium) daran zu hindern, Code außerhalb verifizierter Partitionen über ART- und SELinux-Änderungen auszuführen.

Das ist alles sehr interessant und schön, aber ich kann sehen, dass es über den Browser hinausgeht, um die Sicherheit in der Tiefe zu verbinden.

Die Toolchain-Härtung besteht aus diesen benutzerdefinierten Funktionen (XOR-Canaries, Null-Initialisierung) zusammen mit der Aktivierung zusätzlicher Schalter (die Null-Initialisierung sollte so bald verfügbar sein) wie -fwrapv, -fstack-overflow-strong und auch die Verwendung einiger der produktionsorientierten Desinfektionsmittel im Fangmodus. Die grundlegende CFI-Funktion sollte von Google bald fertiggestellt werden, und ihre leistungsbasierten Blacklists können deaktiviert werden, um etwas Leistung für eine bessere Sicherheit zu opfern. Idealerweise könnten auch die Integer-Überlaufprüfung (zumindest Vorzeichen-Ganzzahl-Überlauf), Begrenzungsprüfung (Objektgröße, Grenzen) und andere CFI-Desinfektionsmittel (einschließlich Cast-Desinfektionsmittel) aktiviert werden. Es ist schwierig, da es so viele Fehler aufdeckt, von denen die meisten in der Praxis keine echten Sicherheitsprobleme sind grobe Blacklisting, die sie derzeit in vielen Fällen verwenden). Ich habe die Desinfektionsmittel zuvor nur in begrenztem Umfang verwendet, aber es ist schwierig zu warten. Google testet mit UBsan, und theoretisch kann es verwendet werden, aber es gibt viele subtile latente Fehler und regelmäßige Rückschritte.

Ich erwarte, dass die Mediatheken voll davon sind.

@csagan5 Übrigens benötigen Sie möglicherweise https://github.com/AndroidHardening/chromium_patches/blob/pie/0005-disable-seed-based-field-trials.patch , um die _local_-Feldversuche zu deaktivieren, die einige der überschreiben interne Einstellungen. Das Übergeben von fieldtrial_testing_like_official_build = true ist wichtig und deaktiviert die Testkonfiguration, die dazu dient, den maximalen Satz experimenteller Funktionen für eine maximale Testabdeckung zu aktivieren, aber das Deaktivieren führt dazu, dass ein zufälliger Seed verwendet wird, um einen zufälligen Satz von Feldversuchen auszuwählen.

Danke für die Erwähnung des Unterschieds zwischen diesen beiden; Ich denke, alle Feldversuche sind durch diesen Patch bereits blockiert? https://github.com/bromite/bromite/blob/73.0.3683.61/build/patches/Disable-fetching-of-all-field-trials.patch

Sie können in chrome://version einchecken

Keine Variationen angezeigt. Ja, ich bin mit der Festverdrahtung vertraut, ich habe selbst einiges gemacht, bevor ich entdeckte, wie Feldversuche funktionieren (aber in meinem Fall fehlte mir einfach fieldtrial_testing_like_official_build=true ).
Ich hatte mich vorher entschieden, diesen Patch nicht einzubinden, da seine Wirkung bereits anderweitig erzielt wurde, aber ich kann ihn ohne Schaden einbauen.

Ich habe auch bestätigt, dass android_64bit_browser in Chromium 73.0.3683.75 (neuester stabiler Tag für Android) ein vollständiger Ersatz für meinen 64-Bit-Monochrom-Patch ist, sodass das Build-Ziel in späteren Versionen auch ordnungsgemäß funktionieren sollte. Wie Sie jedoch erwähnt haben, wird mein Patch immer noch für das eigenständige WebView benötigt, obwohl ich dies nur für den Fall unterstütze, dass einige Organisationen benutzerdefinierte Builds ohne Chromium als Standardbrowser wünschen. Zum Beispiel möchten einige Organisationen eine gesperrte Installation nur mit ihren ausgewählten Apps und wo die Installation von Apps oder sogar das Ausführen von Code von nicht verifizierten Partitionen auf verschiedene Weise verhindert wird (über die SELinux-Richtlinie und Mount-Optionen für nativen Code und auch andere Mechanismen für interpretierte Code). In einigen dieser Fälle möchten sie keinen Browser, aber das WebView wird normalerweise immer noch für einige lokale Webinhalte und möglicherweise einige Anwendungen durch die ausgewählten Apps benötigt, sodass es nicht im Allgemeinen weggelassen werden kann.

Ich verstehe; Ich werde diesen Patch für zukünftige WebView-Builds einschließen. Meine einzige verbleibende Sorge wäre die Installationsanleitung, da es hier auf der Wiki-Seite einige von der Community beigesteuerte Anweisungen /system/app/webview/lib/arm64/ erwähnt wird.

Danke für deine ausführliche Beschreibung der Patches und des AndroidHardening-Projekts; Mir war nicht bewusst, dass Sie Ihre Arbeit dort fortsetzen (ich nehme an, die meisten Leute befinden sich nach den jüngsten Problemen, die Sie erwähnt haben, passiv im selben Schattenkegel).

Ich werde das Projekt und die URL auf der offiziellen Website und README von Bromite erwähnen.

Ich verstehe; Ich werde diesen Patch für zukünftige WebView-Builds einschließen. Meine einzige verbleibende Sorge wäre die Installationsanleitung, da es hier auf der Wiki-Seite einige von der Community beigesteuerte Anweisungen gibt (die ich selbst nicht überprüft habe) und ich frage mich, ob die beteiligten Pfade geändert werden müssen. Es scheint nicht so zu sein, da /system/app/webview/lib/arm64/ dort erwähnt wird.

Die Pfade sind die gleichen, da mit oder ohne Patch immer noch vollständige 32-Bit- und 64-Bit-WebView-Implementierungen bereitgestellt werden. Nur in Android Oreo haben sie die WebView-Sandbox standardmäßig aktiviert, so dass das Ganze vorher immer mit der Architektur der App lief, die sie nutzte und die aus Kompatibilitätsgründen zumindest außerhalb von Builds nur für moderne Releases vollständig unterstützt werden muss. Der Patch ändert die bevorzugte Renderer-Architektur nur von 32-Bit auf 64-Bit, wenn der Renderer als isolierter Prozess ausgeführt wird (standardmäßig Oreo oder höher, aber auf Nougat oder höher über Entwicklereinstellungen unterstützt, und ich habe es früher mit einigen aktiviert Downstream-Fixes, lange bevor es Standard war).

Ihre Option android_64bit_browser nimmt die gleiche Änderung für die Monochrom-Version von WebView in chrome/android/monochrome_android_manifest_jinja_variables.gni (indem sie sie nicht festlegt, wenn sie verwendet wird), ändert jedoch nicht die normale WebView-Architekturpräferenz (was schwierig ist). auf 32-Bit verdrahtet).

Danke für die Erwähnung des Unterschieds zwischen diesen beiden; Ich denke, alle Feldversuche sind durch diesen Patch bereits blockiert? https://github.com/bromite/bromite/blob/73.0.3683.61/build/patches/Disable-fetching-of-all-field-trials.patch

Ah, ja, das scheint die Effekte auf einer anderen Ebene vollständig zu deaktivieren.

@thestinger Ich habe deine Begründung zu den Patches hinzugefügt: https://github.com/bromite/bromite/commit/e7e7afdc2dc219a4416b25d22bdc599d9dc6e072

Übrigens ist ein minimaler Patch erforderlich, um 64-Bit ab Chromium v74 zu bevorzugen, da android_64bit_browser durch Build-Ziele für 64-Bit-Browser ersetzt wurde, aber sie haben es versäumt, sie für die apk-Ziele zu definieren, da sie anscheinend verwenden App-Bundles jetzt.

@thestinger Ich verwende diesen Patch immer noch, um 64-Bit für das WebView zu aktivieren . Ich kann nicht leicht erkennen, wie die Präferenz von 64-Bit für das Haupt-Chromium-APK aktiviert wird.

Müssen Sie sich einen Referenz-Patch oder eine Quellzeile ansehen?

Dies ist der Patch für Monochrome: https://github.com/GrapheneOS/chromium_patches/blob/pie/0002-use-64-bit-Monochrome-processes.patch.

Ich habe es nicht für die eigenständigen Chrome-Apks versucht, aber ich würde erwarten, dass es nur Folgendes benötigt:

if (android_64bit_target_cpu && enable_64_bit_browser) {
    is_64_bit_browser = true
}

dh wie Monochrome, aber ohne sich um die Auswahl der Einbindung von WebView kümmern zu müssen.

https://github.com/GrapheneOS/chromium_patches/blob/pie/0019-enable-strict-site-isolation-by-default-on-Android.patch ist ebenfalls wichtig und die Site-Isolierung ist überall außer Android aktiviert. Der Grund, warum es auf Android nicht standardmäßig aktiviert ist, ist die zusätzliche Speichernutzung durch die Garantie, dass jede Site in dedizierten Prozessen isoliert ist, anstatt Iframes für andere Sites im Prozess auszuführen. Es hat keinen Einfluss auf die Speichernutzung für Websites ohne Dinge wie iframes.

Die Standortisolierung ist die einzige wirkliche Abschwächung für Spectre v1. Nichts anderes funktioniert vollständig, daher gibt es eine bekannte Möglichkeit, Daten aus dem Browser zu stehlen (Sitzungen und Daten für andere Websites).

https://v8.dev/blog/spectre

@thestinger Ich verwende diesen Patch jetzt, um 64-Bit auch für ChromeModernPublic und Monochrome zu aktivieren: Es scheint, als ob Builds für die Browser-APKs standardmäßig bereits 64-Bit sind.

Für die Site-Isolierung verwende ich diesen Kompromiss: https://github.com/bromite/bromite/blob/74.0.3729.122/build/patches/Enable-site-per-process-isolation-for-devices-with-enough-memory. Patch

Es würde es bei Geräten mit genügend Speicher deaktivieren; siehe https://bugs.chromium.org/p/chromium/issues/detail?id=844118

Der Kommentar im Code, in dem das Limit von 1077 MB festgelegt ist:

  // Using 1077 rather than 1024 because 1) it helps ensure that devices with
  // exactly 1GB of RAM won't get included because of inaccuracies or off-by-one
  // errors and 2) this is the bucket boundary in Memory.Stats.Win.TotalPhys2.
  // See also https://crbug.com/844118.

Haben wir POCs für ältere Android-Versionen (die vermutlich auf Geräten mit <1077 MB RAM laufen) für Spectre v1? Ich würde im Allgemeinen nur den sichereren Ansatz aktivieren, aber ich befürchte, dass der Upstream bestätigt hat, dass der Browser auf diesen Low-End-Geräten einfach nicht verwendbar ist.

es scheint, als ob Builds für die Browser-APKs standardmäßig bereits 64-Bit sind.

Ich glaube nicht, es sei denn, ich übersehe etwas.

Ich würde im Allgemeinen nur den sichereren Ansatz aktivieren, aber ich befürchte, dass der Upstream bestätigt hat, dass der Browser auf diesen Low-End-Geräten einfach nicht verwendbar ist.

Im Allgemeinen wird es verwendbar sein, aber einige Websites mit einer großen Anzahl von iframes funktionieren möglicherweise nicht gut. Zum Beispiel wird die Verwendung von GitHub wahrscheinlich keinen zusätzlichen Speicher benötigen, da ich nirgendwo sehe, dass es Iframes verwendet.

@thestinger du hast recht, ich war verwirrt, als ich die Zweige in BUILD.gn durchgelesen habe.
Ich muss noch einen Weg finden, 64-Bit für das reguläre Browser-APK zu aktivieren, und hoffentlich wird es keine Nebenwirkungen verursachen.

Ich schließe dies vorerst; @thestinger bitte lassen Sie es mich wissen, wenn Sie neue Patches haben, ich werde mir das Repo in der Zwischenzeit