70% der Sicherheitsprobleme in Chromium werden durch Speicherfehler verursacht

Die Entwickler des Chromium-Projekts analysierten 912 gefährliche und kritische Schwachstellen wurden in stabilen Versionen von Chrome seit 2015 identifiziert. Es wurde festgestellt, dass 70% davon durch unsicheren Umgang mit dem Speicher (Pointer-Fehler im C/C++-Code) verursacht wurden. Die Hälfte dieser Probleme (36,1%) entstand durch Zugriffe auf einen Puffer nach der Freigabe des zugehörigen Speichers (Use-after-free).

Bei der Entwicklung von Chromium wurde ursprünglich vorgesehen,, dass im Code Fehler nicht ausgeschlossen sind. Daher wurde stark auf den Einsatz von Sandbox-Isolierung gesetzt, um die Auswirkungen von Schwachstellen zu begrenzen. Mittlerweile haben die Möglichkeiten zur Anwendung dieser Technologie ihre Grenzen erreicht, und eine weitere Zerlegung in Prozesse ist aus Ressourcensicht wenig sinnvoll.

Zur Unterstützung der Sicherheit des Codesystems verwendet Google auch die "Zwei-Regel"», wonach jeder hinzugefügte Code nicht mehr als unter zwei von drei Bedingungen fallen darf: Umgang mit nicht validierten Eingaben, Verwendung einer unsicheren Programmiersprache (C/C++) und Ausführung mit erhöhten Rechten. Daraus folgt, dass Code zur Verarbeitung externer Daten entweder auf minimale Rechte (isoliert) beschränkt oder in einer sicheren Programmiersprache geschrieben sein muss.

Um die Sicherheit des Codes weiter zu erhöhen, wurde ein Projekt zur Vermeidung von Speicherfehlern im Code gestartet. Es werden drei Hauptansätze verfolgt: Erstellung von C++-Bibliotheken mit Funktionen für einen sicheren Umgang mit Speicher, Erweiterung des Anwendungsbereichs von Garbage Collectors, Anwendung von Hardware-Schutzmechanismen MTE (Memory Tagging Extension) und das Schreiben von Komponenten in Sprachen, die einen sicheren Umgang mit Speicher gewährleisten (Java, Kotlin, JavaScript, Rust, Swift).

Es wird erwartet, dass die Arbeit in zwei Richtungen fokussiert wird:

• Eine signifikante Veränderung im C++-Entwicklungsprozess, die möglicherweise negative Auswirkungen auf die Leistung hat (zusätzliche Grenzüberprüfungen und Garbage Collection). Anstelle von raw-Pointern wird empfohlen, im Code den Typ MiraclePtr, der es ermöglicht, exploitable use-after-free-Fehler in nicht sicherheitsrelevante Abstürze zu verwandeln, ohne spürbare negative Auswirkungen auf die Leistung, den Speicherverbrauch und die Stabilität.
• Die Verwendung von Sprachen, die für die Durchführung geschützter Speicherüberprüfungen zur Kompilierzeit ausgelegt sind (das wird negative Auswirkungen auf die Leistung vermeiden, die mit solchen Überprüfungen zur Laufzeit des Codes verbunden sind, führt jedoch zu zusätzlichen Kosten für die Integration von Code in der neuen Sprache mit C++).

Die Verwendung von Bibliotheken für einen sicheren Umgang mit Speicher ist der einfachste, aber auch weniger effektive Weg. Die Neuschreibung des Codes in Rust wird als der effizienteste, jedoch auch sehr kostspielige Weg angesehen.

Quelle: opennet.ru