NSA rät zu Wechsel weg von C und C++

Die National Security Agency (NSA) rät mit dem Dokument „Software Memory Safety“ Entwicklern dringend, auf speichersichere Sprachen wie C#, Go, Java, Ruby, Rust und Swift umzusteigen, um ihren Code vor der Ausführung von Remotecode oder anderen Hackerangriffen zu schützen. Von den oben genannten Sprachen wird Java am häufigsten in Unternehmen und bei der Entwicklung von Android-Apps verwendet, während Swift zu den Top 10 gehört, was zum Teil auf die Entwicklung von iOS-Apps zurückzuführen ist. Und es gibt ein wachsendes Interesse an Rust als Ersatz für C und C++ in der Systemprogrammierung.

„Die NSA rät Organisationen, einen strategischen Wechsel von Programmiersprachen, die wenig oder keinen inhärenten Speicherschutz bieten, wie C/C++, zu einer speichersicheren Sprache zu erwägen, wenn dies möglich ist. Einige Beispiele für speichersichere Sprachen sind C#, Go, Java, Ruby und Swift“, so die NSA. Die Spionagebehörde beruft sich auf jüngste Untersuchungen von Google und Microsoft, wonach 70 % ihrer Sicherheitsprobleme in Chrome bzw. Windows mit dem Arbeitsspeicher zusammenhängen und viele davon auf die Verwendung von C und C++ zurückzuführen sind, die anfälliger für speicherbasierte Schwachstellen sind.

Speichersichere Sprache verwenden

„Böswillige Cyber-Akteure können diese Schwachstellen ausnutzen, um Remote-Code auszuführen oder andere nachteilige Auswirkungen zu erzielen, was oft zur Kompromittierung eines Geräts führt und der erste Schritt zu einem groß angelegten Netzwerkeinbruch sein kann“, stellt die NSA in dem Cybersecurity-Informationsblatt „Software Memory Safety“ fest. „Gängige Sprachen wie C und C++ bieten viel Freiheit und Flexibilität bei der Speicherverwaltung, verlassen sich aber stark darauf, dass der Programmierer die erforderlichen Prüfungen von Speicherverweisen durchführt.

Die Behörde empfiehlt daher, wenn möglich eine speichersichere Sprache zu verwenden, sei es für die Anwendungsentwicklung oder die Systemprogrammierung.  „Die NSA empfiehlt die Verwendung einer speichersicheren Sprache, wenn dies möglich ist“, heißt es.

Während die meisten Sicherheitsfachleute mit dieser Debatte über speichersichere Sprachen vertraut sind, sind es vielleicht nicht alle Entwickler. Vielleicht sollten sie es aber sein, da es sich um ein jahrzehntealtes Problem handelt, wie der Java-Schöpfer James Gosling kürzlich in einer Diskussion über die Entstehung von Java hervorhob. Wenn überhaupt, dann bietet das NSA-Dokument Entwicklern eine klare, leicht verständliche Erklärung der technischen Gründe für den Wechsel zu speichersicheren Sprachen. Die wahrscheinlich am meisten diskutierte Sprache in Bezug auf Speichersicherheit ist Rust, der Hauptkandidat als „Ersatz“ für C und C++.

Der Linux-Kernel hat kürzlich Rust als zweite Sprache nach C eingeführt, nach dem Android Open Source Projekt. Diese Projekte werden alten C/C++-Code nicht ersetzen, sondern Rust für neuen Code bevorzugen. Mark Russinovich, CTO von Microsoft Azure, rief kürzlich alle Entwickler dazu auf, Rust gegenüber C und C++ für alle neuen Projekte zu verwenden. „Durch die Ausnutzung dieser Art von Speicherproblemen können böswillige Akteure – die nicht an die normalen Erwartungen bei der Verwendung von Software gebunden sind – feststellen, dass sie ungewöhnliche Eingaben in das Programm eingeben können, die dazu führen, dass auf Speicher auf unerwartete Weise zugegriffen, geschrieben, zugewiesen oder freigegeben wird“, erklärt die NSA.

Einführung von Speicherfehlern in Software nicht ausgeschlossen

Aber – wie Experten in Debatten über Rust und C/C++ festgestellt haben – warnt die NSA, dass die Verwendung einer speichersicheren Sprache die Einführung von Speicherfehlern in Software nicht von vornherein ausschließt. Außerdem erlauben Sprachen oft Bibliotheken, die nicht in speichersicheren Sprachen geschrieben sind. „Selbst mit einer speichersicheren Sprache ist die Speicherverwaltung nicht völlig sicher. Die meisten speichersicheren Sprachen erkennen an, dass Software manchmal eine unsichere Speicherverwaltungsfunktion ausführen muss, um bestimmte Aufgaben zu erfüllen. Daher gibt es Klassen oder Funktionen, die als nicht speichersicherfähig erkannt werden und es dem Programmierer ermöglichen, eine potenziell unsichere Speicherverwaltungsaufgabe auszuführen“, so die NSA.

„Einige Sprachen verlangen, dass alles, was nicht speichersicherfähig ist, explizit als solches gekennzeichnet wird, um den Programmierer und alle Prüfer des Programms darauf aufmerksam zu machen, dass es unsicher ist. Speichersichere Sprachen können auch Bibliotheken verwenden, die in nicht speichersicheren Sprachen geschrieben wurden und somit unsichere Speicherfunktionen enthalten können. Obwohl diese Art der Einbindung von speicherunsicheren Mechanismen die inhärente Speichersicherheit untergräbt, helfen sie dabei, Speicherprobleme zu lokalisieren, was eine zusätzliche Prüfung dieser Codeabschnitte ermöglicht.“

Die NSA weist darauf hin, dass einige speichersichere Sprachen mit Leistungseinbußen verbunden sein können, so dass Entwickler eine neue Sprache erlernen müssen. Die NSA weist auch darauf hin, dass es Maßnahmen gibt, die Entwickler ergreifen können, um nicht speichersichere Sprachen zu härten. Das Chrome-Team von Google erforscht beispielsweise mehrere Methoden zur Härtung von C++, aber auch diese Ansätze gehen mit Leistungseinbußen einher. C++ wird auf absehbare Zeit in der Codebasis von Chrome bleiben.

Die NSA empfiehlt statische und dynamische Sicherheitstests für Anwendungen, um Speicherprobleme zu erkennen. Sie empfiehlt auch die Erforschung von Methoden zur Speicherhärtung, wie z. B. Control Flow Guard (CFG), die die Ausführung von Code einschränken. In ähnlicher Weise werden Address Space Layout Randomization (ASLR) und Data Execution Prevention (DEP) empfohlen.