Wahl der Programmiersprache bestimmt IT-Sicherheit nicht

NSA warnt vor Speicherfehlern und ignoriert dabei den Großteil anderer Sicherheitslücken

Speicherabbild eines komprimierten Programms (Bild: 2024, DeepSec GmbH)

Wien (pts010/15.11.2024/09:05)

Es gibt über 900 klar klassifizierte Defekte in Softwareapplikationen. Ein Teil davon geht auf Speicherfehler zurück, wo Code falsch auf Speicherbereiche zugreift und Folgefehler zu Abstürzen oder weiteren Effekten führen können. Die US-amerikanische National Security Agency (NSA) hat 2022 vor dem Einsatz der Programmiersprachen C und C++ gewarnt, um Speicherfehler zu vermeiden. Die Empfehlung ist die Verwendung von anderen Programmiersprachen, die diese Fehler verhindern. Diese Empfehlung geht an der Realität vorbei, da diese Probleme in modernem korrekten C++ Code aufgrund der Sprachspezifikation nicht mehr vorkommen können. Darüber hinaus ignoriert der Vorschlag der NSA bereits existierenden Code, der gut getestet und produktionsreif ist, und viel gefährlichere Defekte, die in allen Programmiersprachen weiterhin möglich sind.

Modernes C++

Die Programmiersprache C++ wurde schon 1978 publiziert und hat sich seither stetig weiter entwickelt. Seit 2011 wird alle drei Jahre eine Spezifikation der Sprache festgelegt. Der Standard C++11 von 2011 markiert gleichzeitig den Beginn von modernem C++, weil Lücken in der Sprachdefinition beseitigt wurden. Verwendet man alle Elemente der Standards C++14 und später, so hat korrekter C++ Code weder Speicherfehler noch unbestimmtes Verhalten. Das mag arrogant klingen, aber alle Programmiersprachen haben jeweils eine Sprachdefinition, welche festlegt wie sich der Code verhält. Der einzige Unterschied zwischen C++ und anderen Sprachen sind die minimalen Prüfungen in der Laufzeitumgebung, weil die Compiler keine impliziten, und damit unsichtbaren, Mechanismen einbauen. Teilweise haben die von der NSA vorgeschlagenen Programmiersprachen jedoch einen speziellen unsicheren Modus, der Überprüfungen während der Ausführung verhindern kann. Solche Methoden werden oft für spezielle Probleme oder Systemprogrammierung verwendet.

Code mit Sicherheitsschwachstellen hält sich in der Regel nicht an Vorgaben. Die Gründe können das Alter oder fehlende Kenntnisse der Programmiersprache im Bezug zu Sicherheit sein. Speziell alter Code muss meist an die modernen Sprachstandards angepasst werden. Geschieht dies nicht, so werden Defekte versteckt mitgeschleppt. Diese Problem findet sich in allen Applikationen einer bestimmten Größe und entsteht im Laufe der Zeit. Softwareentwicklung muss diese Schwächen immer berücksichtigen.

Viele weitere Fehlerklassen als Gefahr

Unsicherer Code lässt sich in jeder Programmiersprache implementieren. Das Open Web Application Security Project (OWASP) stellt unregelmäßig eine Liste der häufigsten Fehler in Webapplikationen zusammen. In dieser Liste finden sich die von der NSA beschworenen Speicherfehler nicht. Stattdessen sind fehlende Zugriffsbeschränkungen und Injektionsattacken die größten Gefahren. Die darunterliegenden Fehlerklassifikationen sind oft mit fehlenden oder fehlerhaften Überprüfungen von Daten verbunden, die ein Client an den Webserver sendet. Im Gegensatz zu fehlerhaften Speicherzugriffen sind diese Defekte im Einklang mit den Spezifikationen der verwendeten Programmiersprachen. Der Wechsel auf andere Programmiersprachen bringt daher nicht die erhofften Vorteile im Bereich der Sicherheit. Letztlich bringen fehlendes Grundverständnis für Konzepte sicheren Programmierens und Nachlässigkeiten eine Applikation zu Fall. Möchte man hier Verbesserungen durchführen, so ist ein viel grundsätzlicherer Ansatz zu verfolgen.

Die Konzepte Secure Coding und Secure Design lassen sich auf alle Programmiersprachen gleichermaßen anwenden. Es gibt keine Entwicklungswerkzeuge, die zuverlässig und vollständig Programmierfehler erfassen und darauf hinweisen können. Die Ursache liegt immer am Mangel von kognitiven Prozessen, denn Werkzeuge denken nicht. Dies gilt insbesondere für die aktuell als "Künstliche Intelligenz" vermarkteten Algorithmen. Simulationen und Tests können helfen, aber sie sind letztlich auch von Developern erdacht und denken nicht wie Angreifende. Darüber hinaus geben Secure Coding und Secure Design Prinzipien vor, die man im jeweiligen Ökosystem der Entwicklungsumgebung umsetzen muss. Nicht alles davon lässt sich automatisieren.

Alter Code ist nicht notwendigerweise unsicher

In Medien, die über Softwareentwicklung schreiben, liest man oft über die "Programmiersprache der Woche". Sie wird ganz ähnlich wie ein saisonales Kochrezept beworben. Je nach Stimmung und Jahreszeit soll man eine ganz bestimmte Sprache lernen und fortan allen Code darin schreiben. Dieser Ansatz geht völlig an der Realität vorbei, denn die Softwareentwicklung versucht das ständige Neuschreiben von Code in der Regel zu vermeiden. Einmal gelöste Probleme werden in Bibliotheken oder Modulen gesammelt, damit man auf gut getesteten Code zurückgreifen kann. Daher ist alter Code nicht automatisch unsicher. Es hängt davon ab wie er entwickelt bzw. getestet wurde und ob es noch Unterstützung sowie Sicherheitsupdates gibt. Große Gefahr geht von Code aus, der oft geändert oder neu geschrieben wird.

Diese Aussage gilt auch für Standardbibliotheken, die Teil einer Programmiersprache sind. Gerade bei jungen Sprachen merkt man an den publizierten Sicherheitsdefekten, dass bestehende Lösung neu implementiert werden und damit wieder am Anfang der Entwicklung beginnen. Diesen Effekt kann man selbst an als sicher beworbenen Programmiersprachen wie Rust bemerken. Ein Wechsel auf eine neue Entwicklungsumgebung muss daher wohlüberlegt sein.

Secure Coding und Design

Zur diesjährigen DeepSec Konferenz werden die sematicon AG und die DeepSec gemeinsam illustrieren wie man Secure Design und Secure Coding im eigenen Softwareentwicklungsprozess beginnen, verbessern und kontinuierlich umsetzen kann. Dazu wird es Vorträge und Diskussionen geben, die Beispiele aus Produktivumgebungen geben. Technologisch werden IT- und OT-Systeme behandelt. Die sematicon AG bringt zusätzlich Spezialwissen aus der Entwicklung von Embedded Systems mit. Diese Beiträge finden in der technischen Vortragsreihe statt, die nicht als Stream zur Verfügung steht und nicht aufgezeichnet wird.

Programme und Buchung

Die DeepSec 2024-Konferenztage sind am 21. und 22. November. Die DeepSec-Trainings finden an den zwei vorangehenden Tagen, dem 19. und 20. November statt. Alle Trainings (bis auf angekündigte Ausnahmen) und Vorträge sind als Präsenzveranstaltung gedacht, können aber im Bedarfsfall teilweise oder komplett virtuell stattfinden. Für registrierte Teilnehmer und Teilnehmerinnen wird es einen Stream der Vorträge auf unserer Internetplattform geben.

Die DeepINTEL Security Intelligence Konferenz findet am 20. November statt. Da es sich um eine geschlossene Veranstaltung handelt, bitten wir um direkte Anfragen zum Programm an unsere Kontaktadressen. Wir stellen dafür starke Ende-zu-Ende Verschlüsselung bei Kommunikation zur Verfügung: https://deepsec.net/contact.html

Tickets für die DeepSec Konferenz und die Trainings können Sie jederzeit online unter dem Link https://deepsec.net/register.html bestellen. Ermäßigungscodes von Sponsoren stehen Ihnen zur Verfügung. Bei Interesse melden Sie sich bitte unter deepsec@deepsec.net. Bitte beachten Sie, dass wir wegen der Planungssicherheit auf rechtzeitige Ticketbestellungen angewiesen sind.

Aussender:	DeepSec GmbH
Ansprechpartner:	René Pfeiffer
Tel.:	+43 676 56 26 390
E-Mail:	deepsec@deepsec.net
Website:	deepsec.net/