Języki memory-safe: plan migracji do Rust i nie tylko

Języki memory-safe eliminują lub utrudniają całe klasy błędów: użycie pamięci po zwolnieniu, podwójne zwolnienie, dostęp poza bufor i część wyścigów danych. Nie oznacza to automatycznie bezpiecznej aplikacji, ale radykalnie zmniejsza przestrzeń, w której pojedynczy błąd może zamienić się w wykonanie kodu.

CISA i partnerzy zalecają producentom oprogramowania opracowanie planów przechodzenia na języki bezpieczne pamięciowo. Taki plan nie powinien jednak zaczynać się od przepisywania całego systemu.

Najpierw znajdź ryzyko pamięci

Zbuduj mapę komponentów napisanych w C i C++. Połącz ją z danymi o podatnościach, ekspozycji i uprawnieniach. Najwyższy priorytet mają parsery danych niezaufanych, usługi sieciowe, kodeki, sterowniki, agenty działające jako administrator oraz biblioteki współdzielone przez wiele produktów.

Przydatne pytania:

czy komponent przetwarza dane z internetu;
czy pracuje w procesie uprzywilejowanym;
jak często występują w nim błędy pamięci;
jaki jest zasięg ponownego użycia biblioteki;
czy istnieje stabilny interfejs pozwalający wymienić moduł;
czy zespół potrafi utrzymać nową technologię.

Trzy ścieżki migracji

Pierwsza to wybór języka memory-safe dla nowych usług i narzędzi. Druga polega na stopniowej wymianie najbardziej ryzykownych modułów przy zachowaniu kontrolowanej granicy FFI. Trzecia obejmuje izolację kodu, którego nie da się szybko przepisać: sandbox, separację procesu, minimalne uprawnienia i ograniczenie formatu wejścia.

Rust jest popularnym wyborem dla kodu systemowego, ale Java, C#, Go, Swift czy Kotlin także zapewniają ochronę pamięci odpowiednią dla wielu zastosowań. Decyzję należy oprzeć na środowisku wykonawczym, opóźnieniach, ekosystemie i kompetencjach, a nie modzie.

FFI pozostaje granicą zaufania

Blok unsafe w Rust nie jest błędem sam w sobie. Jest miejscem, które wymaga małej powierzchni, jawnych założeń i dodatkowego przeglądu. Waliduj długości, własność obiektów, czasy życia i błędy zwracane przez bibliotekę natywną. Uruchamiaj fuzzing po obu stronach granicy.

Migracja bez kontroli zależności może jedynie przenieść ryzyko do starej biblioteki C. Dlatego połącz ją z bezpieczeństwem łańcucha dostaw.

Jak mierzyć postęp

Mierz udział kodu narażonego na niezaufane wejście, liczbę krytycznych komponentów pozostających w językach memory-unsafe oraz odsetek nowych funkcji tworzonych w językach memory-safe. Śledź również liczbę bloków unsafe, pokrycie fuzzingiem i czas usuwania wykrytych błędów pamięci.

Dobry roadmap zawiera ownera, budżet, kamienie milowe i kryteria wycofania starego modułu. Sam procent kodu w Rust nie mówi, czy najbardziej ryzykowna ścieżka została zabezpieczona.

Plan na pierwsze 90 dni

Zidentyfikuj komponenty C/C++ i ich ekspozycję.
Wybierz jeden moduł o wysokim ryzyku i stabilnym interfejsie.
Ustal standardy FFI, unsafe, testów i zależności.
Zbuduj prototyp oraz testy równoważności.
Uruchom fuzzing i pomiar wydajności.
Wdróż etapowo z możliwością wycofania.
Zapisz wnioski i rozszerz program.

Język memory-safe jest kontrolą projektową, nie zamiennikiem modelowania zagrożeń, autoryzacji czy DevSecOps. Największą wartość daje wtedy, gdy usuwa najbardziej niebezpieczne klasy błędów z najbardziej eksponowanych komponentów.

Granica bezpiecznego i niebezpiecznego kodu

Migracja nie usuwa ryzyka automatycznie. unsafe, FFI, parsery binarne i sterowniki wymagają osobnego inwentarza, właścicieli oraz testów. Ustal małe interfejsy między starym i nowym komponentem, waliduj długości i własność pamięci po obu stronach, a fuzzing kieruj przede wszystkim na te granice.

Wybieraj komponenty na podstawie ekspozycji i historii błędów, nie mody językowej. Dobrym kandydatem jest parser danych z sieci albo usługa regularnie dotknięta błędami pamięci. Mierz udział krytycznej powierzchni wykonanej w języku memory-safe, rozmiar bloków unsafe, regresje wydajności i liczbę podatności danej klasy. Plan musi obejmować biblioteki, kompilator, szkolenie i utrzymanie.

Źródła: CISA — Eliminating Buffer Overflow Vulnerabilities, NSA — Software Memory Safety, Rust Reference.