Deweloperzy projektu Chromium Zidentyfikowano 912 niebezpiecznych i krytycznych luk w stabilnych wydaniach Chrome od 2015 roku i stwierdzono, że 70% z nich było spowodowanych niebezpiecznym zarządzaniem pamięcią (błędami związanymi z wskaźnikami w kodzie C/C++). Połowa z tych problemów (36,1%) wynikała z odwołań do bufora po zwolnieniu związanej z nim pamięci (use-after-free).
Podczas projektowania Chromium pierwotnie , że w kodzie mogą występować błędy, dlatego duży nacisk kładziono na zastosowanie izolacji sandboxowej w celu ograniczenia skutków wystąpienia luk. Obecnie możliwości wdrożenia tej technologii osiągnęły swoje granice, a dalsze rozdzielanie na procesy jest nieuzasadnione ze względu na zużycie zasobów.
Aby utrzymać bezpieczeństwo bazy kodu, Google stosuje również „“, według której każdy dodawany kod musi spełniać nie więcej niż dwa z trzech warunków: praca z niezaufanymi danymi wejściowymi, użycie niebezpiecznego języka programowania (C/C++) oraz wykonywanie z podwyższonymi uprawnieniami. Z tej zasady wynika, że kod do obsługi danych zewnętrznych musi być albo ograniczony do minimalnych uprawnień (izolowany), albo napisany w bezpiecznym języku programowania.
Aby dodatkowo wzmocnić bezpieczeństwo bazy kodu, uruchomiono projekt mający na celu zapobieganie występowaniu błędów zarządzania pamięcią w bazie kodu. Wyróżnia się trzy główne podejścia: tworzenie bibliotek C++ z funkcjami bezpiecznego zarządzania pamięcią oraz rozszerzenie zastosowania zbieracza śmieci, zastosowanie mechanizmów ochrony sprzętowej (Memory Tagging Extension) oraz pisanie komponentów w językach zapewniających bezpieczne zarządzanie pamięcią (Java, Kotlin, JavaScript, Rust, Swift).
Oczekuje się, że prace będą skoncentrowane na dwóch kierunkach:
- Znacząca zmiana w procesie rozwoju w C++, która może negatywnie wpłynąć na wydajność (dodatkowe sprawdzenia granic i zbieranie śmieci). Zamiast wskaźników raw proponuje się użycie w kodzie typu , który pozwala zredukować exploitable błędy klasy use-after-free do niegroźnych awarii, bez znaczącego negatywnego wpływu na wydajność, zużycie pamięci i stabilność.
- Wykorzystanie języków zaprojektowanych do przeprowadzania sprawdzania bezpiecznej obsługi pamięci podczas kompilacji (pozwoli to wyeliminować negatywny wpływ na wydajność, typowy dla takich sprawdzeń podczas wykonywania kodu, ale wiąże się z dodatkowymi kosztami organizacji interakcji kodu w nowym języku z kodem w C++).
Użycie bibliotek do bezpiecznej obsługi pamięci jest najprostszym, ale też mniej wydajnym rozwiązaniem. Przepisanie kodu w Rust jest oceniane jako najbardziej efektywne, ale również bardzo kosztowne podejście.
Źródło: opennet.ru
