Jenseits von C

Seit Jahrzehnten sind C und seine direkten Nachfolger die bevorzugten Programmiersprachen für die Systemprogrammierung. Als C Anfang der 1970er-Jahre entwickelt wurde, war es ein bedeutender Fortschritt gegenüber der Assemblersprache. Fünfzig Jahre später können wir es besser.

Computersicherheit war 1970 und noch viele Jahre danach für die meisten Menschen kein Thema. Die erste große Sicherheitslücke im Internet trat erst viele Jahre später, im Jahr 1988, auf. Sie wurde als „Internetwurm“ bekannt und nutzte einen Pufferüberlauf aus, bei dem auf ein Array im Speicher außerhalb seiner Grenzen zugegriffen wurde.

In der C-Sprachfamilie, zu der auch C++ gehört, werden die Grenzen von Arrays nicht überprüft. Es liegt in der Verantwortung des Programmierers, sicherzustellen, dass korrekt auf das Array zugegriffen wird. Pufferüberläufe treten daher häufig auf. Schlimmer noch: Es ist leicht, absichtlich einen Pufferüberlauf herbeizuführen und dadurch auf Speicherbereiche zuzugreifen, auf die man keinen Zugriff haben sollte.

Ein Pufferüberlauf ist nur ein Beispiel für Speicherunsicherheit. Weitere verwandte Beispiele sind Zeigerarithmetik und hängende Zeiger (auch bekannt als Use-after-free-Fehler). Heute gibt es viele Programmiersprachen, die mit unterschiedlichen Techniken gewährleisten, dass jedes in diesen Sprachen geschriebene Programm frei von Speichersicherheitsproblemen ist. Die C-Sprachfamilie bietet keine solche Garantie; Speichersicherheit war nie ein Entwicklungsziel dieser Sprachen.

Etwa 70 % der Sicherheitslücken sind auf Verstöße gegen die Speichersicherheit zurückzuführen. Diese Aussage wird durch eine überwältigende Datenlage gestützt. Auf mangelnde Speichersicherheit entfallen:

• 67 % der offengelegten und in freier Wildbahn entdeckten ausgenutzten Sicherheitslücken (laut einer Schätzung von Google Project Zero 2021).
• 90 % der Android-Sicherheitslücken (laut Google). Zwar ist dieser Anteil in letzter Zeit dank des Einsatzes von Rust gesunken, doch 89 % der aus der Ferne ausnutzbaren Sicherheitslücken sind nach wie vor auf mangelnde Speichersicherheit zurückzuführen.
• 70 % der Sicherheitslücken in Microsoft-Produkten (laut Microsoft).
• Die meisten der jüngsten von Apple behobenen Sicherheitslücken (in Catalina, Big Sur, Monterey, Safari, iOS, tvOS, watchOS).

Im Juli 2022 waren 5/6 der in Chrome 103.0.5060.134 behobenen Sicherheitslücken auf Probleme mit der Speichersicherheit zurückzuführen. Es liegt auf der Hand, dass die Beseitigung von Fehlern bei der Speichersicherheit enorm hilfreich wäre. Die Branche weiß seit vielen Jahren, wie sich dies erreichen lässt: durch den Einsatz speichersicherer Programmiersprachen. In der Vergangenheit waren die damit verbundenen Leistungseinbußen stets das Problem. Aufgrund der Bedeutung der Speichersicherheit wird an neuen Strategien gearbeitet, um sie ohne den herkömmlichen Mehraufwand zu gewährleisten. Heute wissen wir, wie sich Fehler bei der Speichersicherheit mit geringen oder ganz ohne Laufzeitkosten vermeiden lassen. Sprachen wie Rust nutzen Innovationen beim Entwurf von Typsystemen, um Speichersicherheit ohne kostspielige Laufzeitunterstützung zu gewährleisten.

Daraus ergibt sich eine unausweichliche Schlussfolgerung: Es sollte kein neuer systemnaher Code mehr in C/C++ (oder allgemeiner in nicht speichersicheren Sprachen) geschrieben werden.

Dies ist kein Aufruf, bestehenden Code in großem Umfang und wahllos neu zu schreiben. Bestehende Software zu ersetzen ist kostspielig und nicht ohne Risiken. Die Branche muss jedoch aufhören, das Problem zu verschärfen, indem sie bestehende Codebasen um weiteren nicht speichersicheren Code ergänzt. Bei bestehendem Code sollte die Neuentwicklung der sensibelsten Komponenten Vorrang haben: Komponenten, die für die Validierung oder Verarbeitung nicht vertrauenswürdiger Benutzereingaben zuständig sind, die in einem privilegierten Kontext ausgeführt werden, die außerhalb einer Sandbox laufen usw.

Diese Position ist zwar weit verbreitet, wird von einigen jedoch nach wie vor kontrovers gesehen. Im Folgenden finden Sie einige der häufig vorgebrachten Argumente für die Beibehaltung des Status quo sowie unsere Antworten darauf.

• Fehler sind nicht auf Programmiersprachen beschränkt.
  • Die meisten Sicherheitslücken entstehen durch Fehler bei der Speichersicherheit. In speichersicheren Sprachen wie Rust können solche Fehler nicht auftreten. Daher verhindert die Verwendung einer speichersicheren Sprache von vornherein die Entstehung der meisten Sicherheitslücken.
• Code-Reviews werden Fehler aufdecken.
  • Studien zeigen, dass Code-Reviews zwar Verbesserungen bewirken können, dabei aber häufig viele Probleme übersehen werden; sie finden ganz sicher nicht alles.
• Unsichere Module machen das Ganze hinfällig.
  • Unsicherer Code wird ausdrücklich auf sehr kleine Codeabschnitte begrenzt, sodass die Ressourcen gezielt für seine Validierung eingesetzt werden können.
• Die Implementierung einer speichersicheren Sprache könnte fehlerhaft sein.
  • Das stimmt, aber die Wahrscheinlichkeit dafür ist wesentlich geringer. Compiler sind relativ klein und werden gründlich getestet. Außerdem behebt die Korrektur eines Compilers automatisch den Fehler in allen damit kompilierten Programmen, anstatt nur einen Fehler in einem einzelnen Programm zu beheben.
• Nur unerfahrene oder unfähige Programmierer machen solche Fehler.
  • Im Gegenteil: Die obigen Daten stammen aus großen Systemprojekten wie dem Chrome-Browser und den Betriebssystemen Windows und macOS. An diesen Projekten arbeiten einige der kompetentesten und erfahrensten Entwickler der Branche, und dennoch treten auch dort Probleme mit der Speichersicherheit auf.
• Diese Probleme lassen sich durch die Einhaltung bewährter Verfahren vermeiden.
  • Siehe oben. Die genannten Teams arbeiten nach äußerst strengen Standards und setzen die besten verfügbaren Tools ein.
• Es ist nicht praktikabel, den gesamten Code neu zu schreiben.
  • Niemand plädiert dafür, den gesamten Code vollständig neu zu schreiben. Stattdessen wird ein Ansatz empfohlen, der sich auf zentrale Elemente konzentriert (hohe Berechtigungen, große Angriffsfläche, entscheidend für Sicherheitsgarantien) und neuen Code in einer speichersicheren Sprache entwickelt.
• Die Leistung ist unzureichend.
  • Die Performance von Rust ist in etwa mit der von C/C++ vergleichbar. Geringfügige Unterschiede rechtfertigen keine Sicherheitsrisiken. Es gibt zudem Situationen, in denen Rust-Programme schneller sein können.
• Speichersichere Programmiersprachen für die Systemprogrammierung wie Rust sind noch zu neu.
  • Rust hält Einzug in den Linux-Kernel.
  • Große Teile von Webbrowsern wie Firefox sind in Rust geschrieben.
  • Google hat Android um riesige Mengen an Rust-Code erweitert – ohne eine einzige Sicherheitslücke.
• Es gibt noch andere Lösungen wie statische Analyse, Fuzzing und Sandboxing.
  • Sicherheit erfordert einen mehrschichtigen Ansatz.
  • Sandboxing hat seine Grenzen.
  • Selbst die besten modernen C++-Praktiken können die Flut an Sicherheitslücken nicht eindämmen.

Siehe „Quantifizierung von Speichersicherheitsmängeln und Reaktionen darauf“ für eine ausführliche Erörterung der oben genannten Punkte.

Trotz der Einwände gewinnen die notwendigen Veränderungen zunehmend an Dynamik. So werden beispielsweise umfangreiche Investitionen in die Open Source Software Security Foundation (unterstützt von der Linux Foundation) getätigt. Speichersicherheit wurde in Berichten des US-Senats und von der NSA thematisiert. Consumer Reports arbeitet zudem daran, die verschiedenen Anreize zu ermitteln, die diese Entwicklung beschleunigen könnten, und gibt dazu eine Reihe von Empfehlungen für Unternehmen und staatliche Behörden.

Zusammenfassend:

Die Bedeutung der Informationstechnik für die Gesellschaft ist in den vergangenen fünfzig Jahren enorm gewachsen. Auch die Bedrohungslage für unsere IT-Infrastruktur hat sich in den letzten Jahrzehnten grundlegend verändert. Die Programmiersprachen, mit denen wir unsere IT-Systeme entwickeln, haben sich jedoch nicht entsprechend weiterentwickelt. Mangelnde Speichersicherheit ist die mit Abstand größte Einzelursache für Sicherheitslücken in Software. Dies ist nicht auf eine bestimmte Art von Software beschränkt: Überall dort, wo nicht speichersichere Programmiersprachen zum Einsatz kommen, treten zahlreiche Probleme mit der Speichersicherheit auf. Und rein zahlenmäßig reicht keine andere Schwachstellenklasse auch nur annähernd daran heran.

Wir verfügen nun über die Mittel, dieses wachsende Problem anzugehen, und es ist entscheidend, dass wir als Branche entsprechend handeln. Glücklicherweise wächst das Bewusstsein für die Situation, doch das Problem ist dringlich und es bleibt keine Zeit zu verlieren.