Rust ist zum fünften Mal die beliebteste Programmiersprache. Ist sie unser neuer Sicherheitsretter?

In den letzten Jahren scheint es, als könnten Softwareentwickler auf der ganzen Welt gar nicht genug von Rust bekommen. Diese relativ neue Systemprogrammiersprache, die von Mozilla entwickelt wurde, hat die Herzen der Stack-Overflow-Community erobert – und da diese Gruppe nicht gerade dafür bekannt ist, sich leicht beeindrucken zu lassen, sollten wir alle aufhorchen, wenn sie eine Sprache fünf Jahre in Folge zur „beliebtesten Programmiersprache“ wählt.

Die Programmiersprache Rust integriert bekannte und funktionale Elemente gängiger Sprachen und folgt einer anderen Philosophie, die Komplexität eliminiert und gleichzeitig Leistung und Sicherheit bietet. Die Lernkurve ist steil, und viele Entwickler haben noch nicht die Gelegenheit, intensiv damit zu arbeiten – nur 5,1 % der Befragten auf Stack Overflow nutzen sie regelmäßig. Dennoch lässt sich nicht leugnen, dass es eine spannende Sprache ist, die deutlich mehr Sicherheit bietet als ihre Vorgänger wie C und C++. Eine breite Einführung erfordert jedoch einen Wandel, sowohl im Verhalten als auch in der Technologie... aber aktuell zieht sie die Aufmerksamkeit der Entwickler auf theoretischer Ebene stark auf sich.  

... aber Moment, wir müssen noch einen weiteren Punkt beleuchten: Es ist wichtig zu beachten, dass Rust eine Programmiersprache ist, die Speichersicherheit priorisiert und Sicherheitslücken beseitigt, die mit gängigen Problemen der Speicherverwaltung verbunden sind. Das ist zwar ein großer Fortschritt (und erspart AppSec-Teams zweifellos so manche Kopfschmerzen), aber es sind nicht die einzigen Herausforderungen für sicheren Code, denen wir gegenüberstehen.

Was genau verhindert Rust? Und wo sind wir in der Sicherheitslandschaft immer noch angreifbar? Lassen Sie uns das neueste Programmier-Einhorn genauer unter die Lupe nehmen:

Die neue Grenze der modernen, speichersicheren Systemprogrammierung

Das Forschungs- und Entwicklungsteam von Mozilla hat an einigen unglaublichen Projekten gearbeitet, und die Investition in die Rust-Programmierung als Open-Source-Wegbereiter ist da keine Ausnahme. Ihr Einführungsvideo gibt einen Einblick in ihre Philosophie, wobei ein zentrales Thema deutlich wird: Der aktuelle Ansatz zur Softwaresicherheit ist fehlerhaft, und Rust wurde entwickelt, um einen Großteil dieses Problems zu lösen.

Das klingt zu einfach, besonders angesichts der massiven Datenpannen, die wir fast täglich erleben – wie das kürzlich bekannt gewordene, erschreckende Versäumnis bei EasyJet. Millionen von Datensätzen werden regelmäßig kompromittiert, fast immer durch Schwachstellen in Webanwendungen, falsche Sicherheitskonfigurationen oder Phishing-Angriffe. Sprachen wie C++ existieren seit Jahrzehnten, doch das war nicht genug Zeit für Entwickler, um sie so zu beherrschen, dass sie durchgängig Best Practices für sicheren Code umsetzen. Warum sollte Rust anders sein? Neue Sprachen gab es schon früher, und keine hat es geschafft, gängige Schwachstellen auszumerzen oder sicherzustellen, dass jeder geschriebene Code beim Kompilieren magisch perfekt ist.

So einfach das Konzept auch sein mag, manchmal sind es die einfachen Antworten, die komplexe Fragen lösen. Rust ist in jeder Hinsicht eine Revolution in der speichersicheren Systemprogrammierung, die ihre Versprechen in vielerlei Hinsicht einhält... und sie rettet definitiv Entwickler, die dazu neigen, Fehler einzubauen, die unentdeckt zu großen Problemen führen können. Java, C, C++ und selbst neuere Sprachen wie Kotlin und Golang bleiben für Entwickler, die sich der Sicherheitsaspekte nicht bewusst sind, ziemlich unnachgiebig. Bei diesen gibt es keine integrierten Warnungen, keine Anzeichen dafür, dass das großartige Feature, das gerade kompiliert wurde, ein Sicherheitsrisiko unter der Haube verbirgt.

Lassen Sie uns also tiefer graben:

Was macht Rust so sicher?

Normalerweise hat ein Entwickler das primäre Ziel, Features zu bauen und sicherzustellen, dass sie funktional und benutzerfreundlich sind – vielleicht sogar Dinge, auf die man stolz ist und die man gerne im Lebenslauf präsentieren möchte. Es ist völlig normal, dass ein Entwickler großartige Software erstellt, sie veröffentlicht und zum nächsten großen Projekt übergeht. An diesem Punkt prüfen Sicherheitsteams auf Schwachstellen, und falls welche gefunden werden, könnte die „fertige“ Anwendung zur Fehlerbehebung an das Team zurückgehen. Das Problem kann einfach sein oder den Rahmen dessen sprengen, was ein Entwickler vernünftigerweise beheben kann.

Das Problem ist, dass die Sicherheitslücken oberflächlich betrachtet gar nicht erkennbar waren. Wenn Scans, Tests und manuelle Code-Reviews sie nicht finden, kann ein Angreifer dieses kleine Zeitfenster potenziell nutzen, um die Schwachstelle auszunutzen.

Rust versucht nun, viele Schwachstellen gar nicht erst in den Code gelangen zu lassen: Es lässt sich schlichtweg nicht kompilieren, wenn Syntaxfehler oder andere speicherbezogene Sicherheitslücken vorliegen, die während des gesamten SDLC zu Produktionsproblemen führen würden. Dies ist speichersichere Programmierung durch Design, die sicherstellt, dass kein Zugriff auf ungültigen Speicher möglich ist (egal, wie die Software ausgeführt wird). Und da 70 % aller Sicherheitslücken das Ergebnis von Problemen bei der Speicherverwaltung sind, ist dies eine beachtliche Leistung.

Rust erkennt und verhindert:

• Buffer Overflow
• Use-after-free
• Double-free
• Null-Pointer-Dereferenzierung
• Verwendung von nicht initialisiertem Speicher

Wenn wir einen Rust-Code-Schnipsel mit C++ vergleichen, wird deutlich, dass einer von beiden standardmäßig sicher ist. Sehen Sie sich dieses Beispiel für einen Buffer-Overflow-Fehler an:

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // Pufferüberlauf, da b länger als a ist
std::cout << a << "; " << b << std::endl;
}

Vs.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust gibt eine Sicherheitswarnung aus und bricht zur Laufzeit ab, sobald die Funktion copy_from_slice erreicht wird, um einen Pufferüberlauf zu verhindern – allerdings nicht zur Kompilierzeit.

In diesem Sinne ist es eine Sprache, die einen „linksseitigen“ Ansatz verfolgt. Sie hebt Fehler hervor und zwingt Entwickler dazu, Code auf die richtige Weise zu schreiben, um speicherbezogene Sicherheitslücken zu vermeiden. Das Einhalten von Fristen hängt also davon ab, dass der Programmierer aufmerksam bleibt, Fehler behebt und den vorgegebenen Weg konsequent verfolgt.

Der Ansatz dieser Sprache wirkt simpel, doch es war eine beachtliche Leistung, diese mächtige Logik so umzusetzen – und sie hält, was sie verspricht. Aus Sicherheitsperspektive ist Rust ein riesiger Fortschritt... wenn es nur mehr Leute nutzen würden. Unternehmen wie Dropbox setzen es bereits in großem Stil ein, was sehr erfreulich ist. Doch es gibt weitere Aspekte zu bedenken, bevor wir vorschnell schlussfolgern, dass nur die Verbreitung uns von einer sichereren Zukunft trennt.

Die Rust-Abrechnung.

Es gibt ein paar kleine (okay, große) Probleme: Die Programmierung in Rust bietet mehr Spielraum für Fehler, als es zunächst scheint. Sie wird nicht die entscheidenden OWASP Top 10-Schwachstellen beheben, die weiterhin zu Sicherheitsverletzungen, Verzögerungen und einer allgemeinen Kultur unsicherer Codierung führen. Zudem gibt es eine Art Engel-Teufel-Dynamik, besser bekannt als: Safe Rust vs. Unsafe Rust.
‍

Wie in der offiziellen Dokumentation erläutert, ist Safe Rust die „wahre“ Form von Rust. Unsafe Rust enthält Funktionen, die als „definitiv nicht sicher“ eingestuft werden, obwohl sie manchmal notwendig sind – etwa bei der Integration mit anderen Sprachen. Doch selbst bei Unsafe Rust ist die Liste der zusätzlichen Funktionen begrenzt. In Unsafe Rust ist es innerhalb von „unsafe“-Blöcken möglich:

• Rohe Zeiger (raw pointers) zu dereferenzieren
• Unsichere Funktionen aufzurufen (einschließlich C-Funktionen, Compiler-Intrinsics und dem rohen Allokator)
• Unsichere Traits zu implementieren
• Statische Variablen zu verändern
• Auf Felder von Unions zuzugreifen.

Selbst im sogenannten „unsicheren“ Modus funktioniert eine der Superkräfte von Rust weiterhin: der „Borrow Checker“. Er verhindert durch statische Codeanalyse im Allgemeinen Speicherprobleme, Kollisionen bei parallelen Berechnungen und viele andere Fehler. Diese Analyse greift auch innerhalb eines „unsafe“-Blocks – es erfordert lediglich deutlich mehr Aufwand, unsichere Konstrukte zu schreiben, ohne dass der Compiler in bestimmten Situationen korrigierend eingreift.

Für die meisten erfahrenen Entwickler scheint das kein großes Problem zu sein – schließlich sind wir dafür bekannt, zu tüfteln, um das Beste aus unseren Anwendungen herauszuholen und ausgefallenere Funktionen zu nutzen. Doch es öffnet potenziell ein schwarzes Loch, das zu schwerwiegenden Fehlkonfigurationen und Sicherheitslücken führen kann: undefiniertes Verhalten. Die Programmierung in Rust (selbst bei unsicherer Verwendung) schränkt die Möglichkeiten für Schwachstellen im Vergleich zu C oder C++ gut ein, aber das Auslösen von undefiniertem Verhalten bleibt ein Risiko.

Ist dies das Ende der Abhängigkeit von entwicklergesteuerter sicherer Programmierung?

Erinnern Sie sich, als ich sagte, Rust habe Komponenten bekannter Sprachen? Eine der größten Sicherheitsschwachstellen von Rust ist, dass es eben Komponenten bekannter Sprachen enthält – nämlich C.

Rust ist zwar eine „sichere Programmiersprache“, aber auch hier kann der Faktor Mensch alles zunichtemachen. Entwickler können den Code so anpassen, dass er ohne Fehlermeldungen läuft (ein attraktives Angebot, da dies mehr Möglichkeiten freischaltet). Im Grunde können Entwickler selbst im sicheren Zustand so „unsicher“ agieren, wie sie möchten, da sie eine Schutzschicht haben, bevor die Dinge völlig aus dem Ruder laufen.

Beide oben genannten Szenarien werden gefährlicher, je tiefer man einsteigt, denn die Ergebnisse von Rust ähneln denen von Scan-Tools. So wie es kein „Schweizer Taschenmesser“ unter den SAST/DAST/RAST/IAST-Tools gibt, das jede Schwachstelle, jeden Angriffsvektor und jedes Problem erkennt, so ist es auch bei Rust. Selbst mit Rust können einige Schwachstellen recht leicht eingeschleust werden.

Das Risiko von undefiniertem Verhalten bei der Ausführung von Unsafe Rust kann zu Integer-Überläufen führen. Generell verhindern selbst sichere Konfigurationen keine menschlichen Fehler bei Sicherheitskonfigurationen, Geschäftslogik oder der Verwendung von Komponenten mit bekannten Schwachstellen. Diese Probleme stellen eine reale Bedrohung dar, wenn sie nicht gepatcht werden. In einer „als sicher angenommenen“ Umgebung wie Rust kann dies sogar zu einer gewissen Selbstgefälligkeit führen, wenn ein Programmierer glaubt, dass alle kritischen Probleme ohnehin erkannt werden.

Ich empfinde Rust wie einen Programmiermentor – einen erfahrenen Ingenieur, der sich die Zeit nimmt, mit einem weniger erfahrenen Entwickler zusammenzuarbeiten, dessen Arbeit zu prüfen, auf potenzielle Fehler hinzuweisen, Effizienz zu steigern und in manchen Fällen sicherzustellen, dass der Code erst kompiliert wird, wenn er korrekt ist. Dennoch ist es für Rust-Programmierer weitaus besser, die Theorie zu beherrschen und sich selbst zu Best Practices zu verpflichten, denn der Mentor könnte sich eines Tages zurückziehen, und man möchte nicht hilflos zurückbleiben.

Bereit, gängige Rust-Schwachstellen sofort zu finden und zu beheben? Spielen Sie die Challenge.