Beseitigung von Speichersicherheitslücken an der Quelle

Die Ursachen von Speichersicherheitslücken beseitigen

Ein paradoxes Ergebnis

• Wenn die Codebasis, die in speicherunsicheren Sprachen geschrieben ist, wächst, führt die Umstellung neuer Funktionen auf speichersichere Sprachen dennoch zu einem deutlichen Rückgang von Speichersicherheitslücken
• Der Grund dafür ist, dass Schwachstellen im Lauf der Zeit exponentiell abnehmen

Mathematische Erklärung

• Die Lebensdauer von Schwachstellen folgt einer Exponentialverteilung
• Schwachstellen entstehen überwiegend in neuem Code, und mit der Zeit wird der Code sicherer
• Die Schwachstellendichte in 5 Jahre altem Code ist 3,4- bis 7,4-mal niedriger als in neuem Code

Praxisbeispiel bei Android

• Seit 2019 hat das Android-Team begonnen, neue Entwicklungen auf speichersichere Sprachen umzustellen
• Stand 2024 ist der Anteil der Speichersicherheitslücken von 76 % auf 24 % gesunken
• Mit dem Rückgang der Speichersicherheitslücken ist auch das gesamte Sicherheitsrisiko gesunken

Die Entwicklung der Strategie für Speichersicherheit

• 1. Generation: Reaktives Patchen – Schwachstellen werden entdeckt und behoben
• 2. Generation: Proaktive Abschwächung – Die Ausnutzung von Schwachstellen wird erschwert
• 3. Generation: Proaktive Schwachstellenfindung – Schwachstellen werden im Voraus aufgespürt
• 4. Generation: Hochzuverlässige Prävention – Durch die Umstellung auf speichersichere Sprachen wird die Entstehung von Schwachstellen selbst verhindert

Vorteile hochzuverlässiger Prävention

• Beendet den endlosen Wettlauf zwischen Verteidigern und Angreifern
• Erhöht die Sicherheit und senkt die Kosten durch speichersichere Sprachen
• Verbessert die Korrektheit des Codes und die Produktivität der Entwickler

Von der Erkenntnis zur Praxis

• Es ist nicht nötig, den gesamten bestehenden speicherunsicheren Code zu verwerfen oder neu zu schreiben
• Durch bessere Interoperabilität wird die Umstellung auf speichersichere Sprachen beschleunigt
• Entwicklung von Werkzeugen zur Verbesserung der Interoperabilität zwischen Rust und C++ sowie zwischen Rust und Kotlin

Die Rolle früherer Generationen

• Selektiver Einsatz von proaktiver Abschwächung und Erkennung
• Mit der Umstellung auf speichersicheren Code nimmt der Bedarf an Abschwächung und Erkennung ab

Fazit

• Der Einsatz speichersicherer Sprachen in neuem Code führt zu einem exponentiellen Rückgang von Schwachstellen
• Mehr als sechs Jahre konsistenter Ergebnisse bei Android belegen die Wirksamkeit dieses Ansatzes

Zusammenfassung von GN⁺

• Um Speichersicherheitslücken zu reduzieren, ist die Umstellung auf speichersichere Sprachen wichtig
• Am Beispiel des Android-Teams zeigt sich ein deutlicher Rückgang von Speichersicherheitslücken
• Statt einer vollständigen Neuschreibung des bestehenden Codes ist eine bessere Interoperabilität der praktikable Weg
• Der Einsatz speichersicherer Sprachen wie Rust kann Sicherheit und Produktivität gleichzeitig steigern

[GN⁺]

Hacker-News-Kommentare

• Die Umstellung neuer Entwicklung auf speichersichere Sprachen kann sinnvolle Verbesserungen bringen
  • Viel einfacher und günstiger, als alles zu portieren
• Das Diagramm im Artikel ist klar und prägnant
  • Sorgfältige Datenauswahl und Beschriftung können die beabsichtigte Aussage leicht vermitteln
• Sicherheitslücken nehmen exponentiell ab
  • Es ist wichtig, sich auf neuen Code zu konzentrieren
  • Wahllose RiiR-Projekte sind eine Verschwendung von Ressourcen
  • Die von Rust-Experten empfohlene Strategie ist am wirksamsten, um Speicherlücken zu minimieren
• Das Android-Team beobachtete, dass die Rollback-Rate von Rust-Änderungen weniger als halb so hoch ist wie bei C++
• Es gibt eine Korrelation zwischen neuem Code und Speicherlücken
  • Code im Zusammenhang mit neuen Funktionen ist stärker auf Sicherheitslücken konzentriert
  • In altem Code werden Edge Cases durch die tatsächliche Nutzung entdeckt
• Es ist schwer, pauschal zu sagen, dass neuer Code Speicherlücken verursacht
  • Es gibt Sicherheitslücken mit großer Wirkung wie den Heartbleed-Bug
• Sicherheitslücken nehmen exponentiell ab
  • Das Einstellen neuer Funktionsergänzungen könnte für die Sicherheit besser sein
  • Windows LTSC ist möglicherweise die sicherste Version
• Sicheres Coding verbessert die Korrektheit des Codes und die Produktivität der Entwickler
  • Das Finden von Bugs wird auf die Zeit vor dem Code-Check-in verlagert
  • Das Android-Team beobachtete, dass die Rollback-Rate von Rust-Änderungen weniger als halb so hoch ist wie bei C++
• Nachdem ich Rust entdeckt habe, habe ich meine Begeisterung fürs Programmieren wiedergefunden
• Als speichersichere Sprache (MSL) wird nur Rust erwähnt
  • Kotlin wurde ebenfalls erwähnt, hat aber nicht so starke Speichersicherheitsfunktionen wie Rust
• Die Lebensdauer von Sicherheitslücken ist exponentiell verteilt
  • Es ist sehr wertvoll, Speichersicherheit in neuem Code sicherzustellen
  • Auch in großen Legacy-Codebasen nützlich
• Alter Code ist möglicherweise nicht ausreichend überprüft
  • Ich prüfe in letzter Zeit häufiger aktuelle Commit-Logs
• Unterschiede bei den für Mac und Windows verwendeten Programmiersprachen
  • Mac verwendet das speichersichere Swift, Windows hauptsächlich C oder C++
• Je seltener Sicherheitslücken werden, desto wertvoller werden sie
  • Verbleibende Sicherheitslücken könnten von staatlichen Akteuren gegen hochwertige Ziele eingesetzt werden
  • Funktionen wie der Lockdown Mode von iOS könnten nötig sein
  • Sicherheitsbewusste Nutzer setzen möglicherweise ein Sicherheits-Häkchen und tauschen dafür Leistung ein
  • Erkennt Angriffe und sendet sie zur Analyse an das Sicherheitsteam
  • Sendet dem Nutzer eine Warnung und informiert ihn darüber, dass ein Angriff erkannt wurde
  • Statt die Nutzeraktivität passiv zu überwachen, wird der Nutzer benachrichtigt, wenn ein Angriff erkannt wird