Twórcy projektu Chromium W stabilnych wersjach przeglądarki Chrome od 912 roku zidentyfikowano 2015 luk wysokiego ryzyka i krytycznych i stwierdzono, że 70% z nich wynikało z braku bezpieczeństwa pamięci (błędy podczas pracy ze wskaźnikami w kodzie C/C++). Połowa tych problemów (36.1%) wynika z dostępu do bufora po zwolnieniu związanej z nim pamięci (use-after-free).
Projektując Chromium, początkowo tak było że w kodzie mogą pojawić się błędy, dlatego duży nacisk położono na zastosowanie izolacji typu sandbox w celu ograniczenia skutków podatności. Obecnie możliwości wykorzystania tej technologii osiągnęły granicę swoich możliwości i dalsza fragmentacja na procesy jest niepraktyczna z punktu widzenia zużycia zasobów.
Aby zachować bezpieczeństwo bazy kodu, Google wymusza również „„, zgodnie z którym każdy dodany kod musi spełniać nie więcej niż dwa z trzech warunków: pracę z niezweryfikowanymi danymi wejściowymi, używanie niepewnego języka programowania (C/C++) i działanie z podwyższonymi uprawnieniami. Zasada ta oznacza, że kod do przetwarzania danych zewnętrznych musi zostać albo zredukowany do minimalnych uprawnień (izolowany), albo napisany w bezpiecznym języku programowania.
Aby jeszcze bardziej zwiększyć bezpieczeństwo bazy kodu, uruchomiono projekt zapobiegający pojawianiu się błędów pamięci w bazie kodu. Istnieją trzy główne podejścia: tworzenie bibliotek C++ z funkcjami zapewniającymi bezpieczną pracę pamięci i rozszerzanie zakresu modułu zbierającego elementy bezużyteczne, z wykorzystaniem sprzętowych mechanizmów ochronnych (Memory Tagging Extension) i pisanie komponentów w językach zapewniających bezpieczną pracę z pamięcią (Java, Kotlin, JavaScript, Rust, Swift).
Oczekuje się, że prace będą skupione w dwóch obszarach:
- Znacząca zmiana w procesie rozwoju C++, która nie wyklucza negatywnego wpływu na wydajność (dodatkowe sprawdzanie granic i zbieranie śmieci). Zamiast surowych wskaźników proponuje się użycie typu , co pozwala zredukować możliwe do wykorzystania błędy powstałe po zwolnieniu do awarii, które nie stanowią zagrożenia dla bezpieczeństwa, bez zauważalnego negatywnego wpływu na wydajność, zużycie pamięci i stabilność.
- Użycie języków zaprojektowanych do przeprowadzania kontroli bezpieczeństwa pamięci w czasie kompilacji (wyeliminuje negatywny wpływ na wydajność związany z takimi kontrolami podczas wykonywania kodu, ale doprowadzi do dodatkowych kosztów organizacji interakcji kodu w nowym języku z kodem w C++).
Korzystanie z bibliotek bezpiecznych dla pamięci jest najprostszym, ale także mniej wydajnym sposobem. Przepisanie kodu w Rust jest oceniane jako najskuteczniejszy, ale i bardzo kosztowny sposób.
Źródło: opennet.ru