Analitycy z zadowoleniem przyjmują rady NSA dla programistów dotyczące przyjęcia języków bezpiecznych dla pamięci

Analitycy bezpieczeństwa z zadowoleniem przyjęli w zeszłym tygodniu zalecenie amerykańskiej Agencji Bezpieczeństwa Narodowego (NSA), aby twórcy oprogramowania rozważyli przyjęcie języków takich jak C#, Go, Java, Ruby, Rust i Swift w celu zmniejszenia luk w kodzie związanych z pamięcią.

NSA określiła je jako języki „bezpieczne dla pamięci”, które automatycznie zarządzają pamięcią jako część języka komputerowego. NSA stwierdziła, że ​​nie polegają na programiście w zakresie implementacji zabezpieczeń pamięci, a zamiast tego stosują kombinację kontroli czasu kompilacji i wykonywania w celu ochrony przed błędami pamięci.

Sprawa języków bezpiecznych dla pamięci

Dość nietypowe zalecenie NSA z 10 listopada wskazywało na powszechnie używane języki, takie jak C i C++ zbytniego polegania na programistach aby nie popełniać błędów związanych z pamięcią, co, jak zauważył, nadal jest główną przyczyną luk w zabezpieczeniach oprogramowania. Poprzednie badania — jeden po drugim Microsoft w 2019 roku i inny od Google w 2020 roku związane z przeglądarką Chrome — na przykład obie wykryły 70% luk w zabezpieczeniach związanych z bezpieczeństwem pamięci, podała NSA.

„Powszechnie używane języki, takie jak C i C++, zapewniają dużą swobodę i elastyczność w zarządzaniu pamięcią, jednocześnie polegając w dużym stopniu na programiście, który przeprowadza niezbędne kontrole odwołań do pamięci” – powiedziała NSA. Często skutkuje to możliwymi do wykorzystania lukami w zabezpieczeniach związanymi z prostymi błędami, takimi jak błędy przepełnienia bufora, problemy z alokacją pamięci i warunki wyścigu.

C#, Go, Java, Ruby, Rust, Swift i inne języki bezpieczne dla pamięci nie eliminują całkowicie ryzyka tych problemów, stwierdziła NSA w swoim poradniku. Na przykład większość z nich zawiera co najmniej kilka klas lub funkcji, które nie są bezpieczne dla pamięci i umożliwiają programiście wykonanie potencjalnie niebezpiecznej funkcji zarządzania pamięcią. Języki bezpieczne dla pamięci mogą czasami zawierać również biblioteki napisane w językach, które zawierają potencjalnie niebezpieczne funkcje pamięci.

Ale nawet z tymi zastrzeżeniami, języki bezpieczne dla pamięci może pomóc zmniejszyć luki w oprogramowaniu wynikające ze złego i niedbałego zarządzania pamięcią, powiedziała NSA.

Tim Mackey, główny strateg bezpieczeństwa w Synopsys Cybersecurity Research Center, z zadowoleniem przyjmuje zalecenie NSA. Mówi, że używanie języków bezpiecznych dla pamięci powinno być w rzeczywistości domyślne dla większości aplikacji. „Z praktycznych względów poleganie na programistach, aby skupili się na kwestiach zarządzania pamięcią zamiast programowania fajnych nowych funkcji, stanowi podatek od innowacji” — mówi. W przypadku języków programowania bezpiecznych dla pamięci i związanych z nimi platform to autorzy języka zapewniają właściwe zarządzanie pamięcią, a nie twórcy aplikacji, mówi Mackey.

Zmiana może być wyzwaniem

NSA przyznała, że ​​przeniesienie dojrzałego środowiska programistycznego z jednego języka na inny może być trudne. Programiści będą musieli nauczyć się nowego języka, aw trakcie procesu prawdopodobnie wystąpią błędy początkujących i trafienia w wydajność. Zakres dostępnych zabezpieczeń pamięci może się znacznie różnić w zależności od języka. Niektóre mogą oferować jedynie minimalne zabezpieczenia pamięci, podczas gdy inne zapewniają znaczne zabezpieczenia dotyczące dostępu do pamięci, jej alokacji i zarządzania.

Ponadto organizacje będą musiały rozważyć, na jaki kompromis między bezpieczeństwem a wydajnością są gotowe. „Bezpieczeństwo pamięci może być kosztowne pod względem wydajności i elastyczności” — ostrzega NSA. „W przypadku języków o ekstremalnym poziomie naturalnej ochrony może być potrzebna znaczna praca, aby po prostu skompilować program ze względu na kontrole i zabezpieczenia”.

Podczas próby przeniesienia aplikacji z jednego języka na inny istnieje mnóstwo zmiennych, mówi Mike Parkin, starszy inżynier techniczny w Vulcan Cyber. „W najlepszym przypadku zmiana jest prosta, a organizacja może przeprowadzić ją stosunkowo bezboleśnie” — mówi Parkin. „W innych aplikacja opiera się na funkcjach, które są trywialne w oryginalnym języku, ale wymagają rozbudowanego i kosztownego rozwoju, aby odtworzyć je w nowym”.

Używanie języków bezpiecznych dla pamięci nie zastępuje również potrzeby odpowiedniego testowania oprogramowania, ostrzega Mackey. Tylko dlatego, że język programowania jest bezpieczny dla pamięci, nie oznacza, że ​​język lub opracowane na nim aplikacje są wolne od błędów.

Przejście z jednego języka programowania na inny jest ryzykowną propozycją, chyba że masz personel, który już rozumie zarówno stary, jak i nowy język, mówi Mackey. „Taką migrację najlepiej przeprowadzać, gdy aplikacja przechodzi główną aktualizację wersji; w przeciwnym razie istnieje ryzyko, że w ramach migracji zostaną wprowadzone niezamierzone błędy” — zauważa.

Mackey sugeruje, aby organizacje rozważyły ​​użycie mikrousług, jeśli chodzi o zmianę języków. „Dzięki architekturze mikrousług aplikacja jest rozkładana na zestaw usług umieszczonych w kontenerach” — mówi Mackey. „Z perspektywy języka programowania nic nie wymaga, aby każda mikrousługa była zaprogramowana w tym samym języku programowania, co inne usługi w ramach tej samej aplikacji”.

Robienie ruchu

Pokazują to najnowsze dane Statista wielu programistów już korzysta języki uważane za bezpieczne dla pamięci. Na przykład prawie dwie trzecie (65.6%) używa JavaScript, prawie połowa (48.06%) używa Pythona, jedna trzecia używa Java, a prawie 28% używa C#. Jednocześnie znaczny odsetek nadal używa niebezpiecznych języków, takich jak C++ (22.5%) i C (19.25%).

„Myślę, że wiele organizacji już odchodzi od C/C++ nie tylko ze względu na bezpieczeństwo pamięci, ale także ze względu na ogólną łatwość programowania i konserwacji” — mówi Johannes Ullrich, dziekan ds. badań w SANS Technology Institute. „Ale nadal będą istnieć starsze bazy kodu, które będą musiały być utrzymywane przez wiele lat”.

Doradca NSA oferował niewielki wgląd w to, co mogło skłonić go do wydania zalecenia w tym momencie. Ale John Bambenek, główny łowca zagrożeń w Netenrich, radzi organizacjom, aby tego nie ignorowały. „Luki w zabezpieczeniach pamięci i ataki były wszechobecne od lat 1990., więc ogólnie rzecz biorąc, jest to dobra rada” – mówi. „Biorąc to pod uwagę, ponieważ pochodzi to od NSA, uważam, że ta rada powinna być pilna i wynika z wiedzy, którą oni mają, a my nie”.