Sicherheitsanalysten begrüßten letzte Woche eine Empfehlung der US-amerikanischen National Security Agency (NSA) für Softwareentwickler, die Einführung von Sprachen wie C#, Go, Java, Ruby, Rust und Swift in Betracht zu ziehen, um speicherbezogene Schwachstellen im Code zu reduzieren.
Die NSA beschrieb diese als „speichersichere“ Sprachen, die den Speicher automatisch als Teil der Computersprache verwalten. Sie verlassen sich nicht auf den Programmierer, um die Speichersicherheit zu implementieren, und verwenden stattdessen eine Kombination aus Kompilierzeit- und Laufzeitprüfungen, um sich vor Speicherfehlern zu schützen, sagte die NSA.
Argumente für speichersichere Sprachen
Das etwas ungewöhnliche Advisory der NSA vom 10. November wies auf weit verbreitete Sprachen wie C und C++ hin sich zu sehr auf Programmierer verlassen keine speicherbezogenen Fehler zu machen, was sie feststellte, ist nach wie vor die häufigste Ursache für Sicherheitslücken in Software. Frühere Studien – einzeln Microsoft im Jahr 2019 und ein anderer von Google im Jahr 2020 im Zusammenhang mit seinem Chrome-Browser – zum Beispiel stellten beide fest, dass 70 % der Schwachstellen Probleme mit der Speichersicherheit waren, sagte die NSA.
„Allgemein verwendete Sprachen wie C und C++ bieten viel Freiheit und Flexibilität bei der Speicherverwaltung, während sie sich stark auf den Programmierer verlassen, um die erforderlichen Überprüfungen der Speicherreferenzen durchzuführen“, sagte die NSA. Dies führt häufig zu ausnutzbaren Schwachstellen, die mit einfachen Fehlern wie Pufferüberlauffehlern, Speicherzuweisungsproblemen und Race-Conditions verbunden sind.
C#, Go, Java, Ruby, Rust, Swift und andere speichersichere Sprachen eliminieren das Risiko dieser Probleme nicht vollständig, so die NSA in ihrer Empfehlung. Die meisten von ihnen enthalten zum Beispiel mindestens einige wenige Klassen oder Funktionen, die nicht speichersicher sind und es dem Programmierer ermöglichen, eine potenziell unsichere Speicherverwaltungsfunktion auszuführen. Speichersichere Sprachen können manchmal auch Bibliotheken enthalten, die in Sprachen geschrieben sind, die potenziell unsichere Speicherfunktionen enthalten.
Aber selbst mit diesen Vorbehalten sind speichersichere Sprachen kann dazu beitragen, Schwachstellen in Software zu reduzieren resultierend aus schlechter und nachlässiger Speicherverwaltung, sagte die NSA.
Tim Mackey, leitender Sicherheitsstratege am Synopsys Cybersecurity Research Center, begrüßt die Empfehlung der NSA. Die Verwendung von speichersicheren Sprachen sollte eigentlich die Standardeinstellung für die meisten Anwendungen sein, sagt er. „Aus praktischen Gründen stellt es eine Steuer auf Innovation dar, wenn man sich darauf verlässt, dass sich Entwickler auf Speicherverwaltungsprobleme konzentrieren, anstatt coole neue Funktionen zu programmieren“, sagt er. Bei speichersicheren Programmiersprachen und zugehörigen Frameworks sind es die Autoren der Sprache, die für eine ordnungsgemäße Speicherverwaltung sorgen, und nicht die Anwendungsentwickler, sagt Mackey.
Schicht kann herausfordernd sein
Die Umstellung einer ausgereiften Softwareentwicklungsumgebung von einer Sprache auf eine andere kann schwierig sein, räumte die NSA ein. Programmierer müssen die neue Sprache lernen, und während des Prozesses werden wahrscheinlich Anfängerfehler und Effizienzeinbußen auftreten. Das Ausmaß der verfügbaren Speichersicherheit kann auch je nach Sprache erheblich variieren. Einige bieten möglicherweise nur minimale Speichersicherheit, während andere beträchtlichen Schutz in Bezug auf Speicherzugriff, -zuweisung und -verwaltung bieten.
Darüber hinaus müssen Unternehmen abwägen, wie viel Kompromiss sie zwischen Sicherheit und Leistung eingehen wollen. „Speichersicherheit kann in Bezug auf Leistung und Flexibilität kostspielig sein“, warnte die NSA. „Bei Sprachen mit einem extremen Grad an inhärentem Schutz kann aufgrund der Überprüfungen und Schutzmaßnahmen beträchtliche Arbeit erforderlich sein, um das Programm einfach zum Kompilieren zu bringen.“
Beim Versuch, eine Anwendung von einer Sprache in eine andere zu portieren, spielen unzählige Variablen eine Rolle, sagt Mike Parkin, Senior Technical Engineer bei Vulcan Cyber. „Im besten Fall ist die Umstellung einfach, und ein Unternehmen kann sie relativ problemlos bewerkstelligen“, sagt Parkin. „In anderen Fällen stützt sich die Anwendung auf Funktionen, die in der Originalsprache trivial sind, aber eine umfangreiche und teure Entwicklung erfordern, um sie in der neuen Sprache nachzubilden.“
Die Verwendung speichersicherer Sprachen ersetzt auch nicht die Notwendigkeit angemessener Softwaretests, warnt Mackey. Nur weil eine Programmiersprache speichersicher ist, bedeutet das nicht, dass die Sprache oder die darauf entwickelten Anwendungen frei von Fehlern sind.
Der Wechsel von einer Programmiersprache zu einer anderen ist ein riskantes Unterfangen, es sei denn, Sie haben Mitarbeiter, die bereits sowohl die alte als auch die neue Sprache verstehen, sagt Mackey. „Eine solche Migration wird am besten durchgeführt, wenn die Anwendung ein Hauptversions-Update durchläuft; Andernfalls besteht die Möglichkeit, dass im Rahmen der Migration unbeabsichtigt Fehler eingeführt werden“, bemerkt er.
Mackey schlägt vor, dass Unternehmen die Verwendung von Microservices in Betracht ziehen, wenn es um die Umstellung von Sprachen geht. „Bei einer Microservices-Architektur wird die Anwendung in eine Reihe von Diensten zerlegt, die containerisiert sind“, sagt Mackey. „Aus der Perspektive einer Programmiersprache gibt es nichts, was von Natur aus erfordert, dass jeder Microservice in derselben Programmiersprache programmiert wird wie andere Dienste innerhalb derselben Anwendung.“
Den Zug machen
Das zeigen aktuelle Daten von Statista Viele Entwickler verwenden bereits Sprachen, die als speichersicher gelten. Fast zwei Drittel (65.6 %) verwenden beispielsweise JavaScript, fast die Hälfte (48.06 %) Python, ein Drittel Java und fast 28 % C#. Gleichzeitig verwendet ein beträchtlicher Anteil immer noch unsichere Sprachen wie C++ (22.5 %) und C (19.25 %).
„Ich denke, dass viele Unternehmen bereits von C/C++ abgewichen sind, nicht nur wegen der Speichersicherheit, sondern auch wegen der allgemeinen Einfachheit der Entwicklung und Wartung“, sagt Johannes Ullrich, Forschungsdekan am SANS Technology Institute. „Aber es wird immer noch Legacy-Codebasen geben, die noch viele Jahre gepflegt werden müssen.“
Das Gutachten der NSA bot zu diesem Zeitpunkt wenig Einblick in die Gründe, die zu ihrer Empfehlung geführt haben könnten. Aber John Bambenek, Hauptjäger von Bedrohungen bei Netenrich, rät Organisationen, sie nicht zu ignorieren. „Speicherschwachstellen und Angriffe sind seit den 1990er Jahren weit verbreitet, daher ist dies im Allgemeinen ein guter Rat“, sagt er. „Da dies von der NSA kommt, glaube ich, dass dieser Rat zusätzliche Dringlichkeit haben sollte und von dem Wissen angetrieben wird, das sie haben und wir nicht.“
