Der Drang nach sicheren Programmiersprachen

Im Dezember 2023 haben Sicherheitsbehörden aus fünf Regionen, darunter Nordamerika, Europa und der Südpazifik, ein Dokument veröffentlicht, in dem die Führungskräfte von Softwareunternehmen aufgefordert werden, die Sicherheit der von ihnen erstellten Software in die eigenen Hände zu nehmen. Das wurde im Februar 2024 vom Weissen Haus unterstrichen, als sie einen Cybersecurity-Plan veröffentlichten. In diesem Artikel schauen wir uns die sicheren Programmiersprachen an, die in diesen Dokumenten erwähnt werden, vergleichen ihre Sicherheit mit Erlang und Elixir und führen ein neues Konzept ein, das als unsichere Impedanz bekannt ist.

#Die Notwendigkeit sicherer Programmiersprachen

Die Sicherheitsbehörden haben erklärt, dass selbst erfahrene Entwickler Bugs einführen können, die zu erheblichen Sicherheitslücken führen. Sie empfehlen den Unternehmen, sich von dem zu verabschieden, was sie als speicherunsichere Sprachen bezeichnen, und hin zu dem, was sie als Speicher-sichere Sprachen (MSLs) betrachten. Diese Behörden betonen, dass alle Softwarehersteller, nicht nur die, die Software verkaufen, Pläne entwickeln und veröffentlichen sollten, um zu zeigen, wie sie die Verantwortung für die Sicherheit ihrer Produkte übernehmen.

Der Bericht behauptet, dass viele Programmiersprachen als "sicher" gelten, sie aber dennoch unsicheren Code zulassen können. Wenn unsicherer Code verwendet wird, wird die Sicherheit des Produkts gefährdet. Das führt zur Idee der unsicheren Impedanz, die hilft zu bewerten, wie leicht unsicherer Code in verschiedenen Programmiersprachen geschrieben werden kann.

#Definition der unsicheren Impedanz

Unsichere Impedanz bezieht sich auf das Mass an Schwierigkeiten, dem ein Programmierer gegenübersteht, wenn er versucht, unsicheren Code in einer Programmiersprache zu schreiben. Sprachen mit hoher unsicherer Impedanz machen es schwieriger, unsicheren Code zu schreiben, während Sprachen mit niedriger unsicherer Impedanz es einfacher machen. Dieses Konzept kann sowohl technischen Experten als auch Führungskräften helfen, sichere Programmiersprachen auszuwählen und ihre Sicherheitspläne zu entwickeln.

#Sicher durch Design und Sicher standardmässig

Im Jahr 2023 haben dreizehn globale Sicherheitsbehörden umrissen, was sie als "sicher durch Design" und "sicher standardmässig" erachten. Damit ein Technologieprodukt sicher durch Design ist, muss es effektiv gegen unbefugten Zugriff geschützt sein. Sicher standardmässig bedeutet, dass das Produkt gegen gängige Ausnutzungstechniken robust sein sollte, ohne zusätzliche Kosten zu verursachen.

Wenn wir uns Programmiersprachen ansehen, können wir sie in diesen Begriffen kategorisieren. Sprachen, die von Natur aus gegen Schwachstellen schützen, gelten als sicher standardmässig. Viele gängige Programmiersprachen erlauben jedoch das Schreiben von unsicherem Code und kommen dabei zu kurz.

#Häufige Sicherheitsprobleme im Speicher

Es gibt zwei Haupttypen von Speicheranfälligkeiten: räumliche und temporale.

• Räumliche Anfälligkeiten entstehen durch die Art und Weise, wie Speicherorte verwendet werden.
• Temporale Anfälligkeiten treten aufgrund von Timing-Problemen auf, die zu Speicherfehlern führen können.

Hier sind einige Beispiele:

Räumliche Speicherprobleme:

• Buffer Overflow
• Array-Index ausserhalb der Grenzen

Temporale Speicherprobleme:

• Verwendung nach Freigabe
• Speicherlecks

Sicherheitsbehörden haben mehrere Sprachen in ihre Liste der speichersicheren Sprachen aufgenommen, darunter C, Go, Java, Python, Rust und Swift. Allerdings ist keine dieser Sprachen sicher standardmässig, da sie das Schreiben von unsicherem Code zulassen.

#Bewertung von unsicherem Code in gängigen Sprachen

Jede Programmiersprache hat Regeln bezüglich unsicherem Code.

1. C Sprache: C erlaubt unsicheren Code ohne klare Hinweise, dass der Code unsicher ist, was das Schreiben sehr einfach macht.

2. Go: In Go kann ein Programmierer unsichere Zeiger ohne visuelle Warnung erstellen. Während das unsichere Paket von Go als Option existiert, ist seine Verwendung nicht erforderlich.

3. Java: Java erlaubt unsicheren Code über seine Native Interface (JNI). Sobald unsicherer Code ausgeführt wird, gibt es keinen klaren Hinweis darauf, dass unsicheres Verhalten auftritt.

4. Python: Mit der ctypes-Bibliothek kann Python mit unsicherem Code aus anderen Sprachen interagieren. Das Fehlen direkter Indikatoren kann zu Sicherheitsproblemen führen.

5. Rust: Rust enthält ein unsicheres Schlüsselwort, um unsicheren Code hervorzuheben, lässt jedoch unsichere Operationen im selben Speicherbereich wie sicheren Code zu.

6. Swift: Swift hat klare Indikatoren für unsicheren Code, aber das verhindert nicht, dass unsichere Aktionen beim Interagieren mit anderen Sprachen stattfinden.

#Wie sich Erlang und Elixir abheben

Erlang und Elixir sind einzigartig, da sie auf der BEAM-virtuellen Maschine laufen. Diese Umgebung hat ihre Anfälligkeiten, aber beide Sprachen erlauben die direkte Verwendung von Zeigern nicht, was häufige Speicherprobleme erheblich reduziert. Sie sind darauf ausgelegt, sicher standardmässig zu sein, können jedoch immer noch durch die Verwendung von Native Implemented Functions (NIFs) gefährdet werden.

#Einführung des Unsicheren Akzeptanzprozesses (UAP)

Um sicherere Softwarepraktiken zu fördern, schlagen wir einen Unsicheren Akzeptanzprozess (UAP) für Unternehmen vor. Dieser Prozess sollte die Hindernisse für die Verwendung von unsicherem Code überwinden, indem er Folgendes verlangt:

• Begründung für die Notwendigkeit eines NIF.
• Eine Beschreibung der Sicherheitsrisiken, die mit der NIF-Implementierung einhergehen.
• Quellcode für die vorgeschlagenen unsicheren Funktionen.
• Nachweise, die zeigen, dass der NIF kein unsicheres Verhalten einführt.
• Vorgeschlagene Geschwindigkeitsvorteile durch die Verwendung des NIF.
• Alternative Lösungen, die ohne NIFs funktionieren könnten.

Der UAP sollte verhindern, dass Entwickler unabhängig unsicheren Code in Anwendungen hinzufügen. Er sollte eine gründliche Bewertung und Skepsis gegenüber der Hinzufügung von NIFs verlangen.

#Auf dem Weg zu sichererer Software

Jedes System, ob auf einer sicheren standardmässigen Sprache wie Erlang oder Elixir basierend, läuft Gefahr, angegriffen zu werden, wenn unsicherer Code eingeführt wird. Historisch gesehen haben viele Organisationen die Benutzerfreundlichkeit von unsicherem Code priorisiert, um Leistungsbeschränkungen zu überwinden oder bestehenden Code wiederzuverwenden. In der heutigen Welt, in der Sicherheit zunehmend von Bedeutung ist, ist es jedoch wichtig, Sicherheit über Geschwindigkeit zu priorisieren.

Die mit unsicherem Code verbundenen Risiken sind erheblich, wobei viele Vorfälle, wie die Heartbleed-Sicherheitsanfälligkeit in OpenSSL, aufzeigen, wie gefährlich solche Praktiken sein können. Organisationen müssen sich an diese Realität anpassen und unsicheren Code wo immer möglich eliminieren.

#Zukünftige Forschung und Richtungen

Weitere Untersuchungen sind notwendig, um die Möglichkeiten, wie Programmiersprachen sicher standardmässig sein können, vollständig zu verstehen und zu verbessern. Die Forschung sollte auch Metriken untersuchen, um die unsichere Impedanz zu messen und verschiedene Programmiersprachen rigoroser zu bewerten.

Zusammenfassend liegt die Zukunft der Software-Sicherheit in der Kombination aus sicheren Sprachen und robusten Geschäftspraktiken. Indem Organisationen den Schwerpunkt auf unsichere Akzeptanzprozesse legen, können sie ein sichereres Programmierumfeld fördern. Dieser Ansatz kommt jedem zugute und stellt sicher, dass die Softwareentwicklung Sicherheit und Widerstandsfähigkeit angesichts wachsender Bedrohungen priorisiert.