Въпреки че над 50 % от целия  отворен код е написан на езици, които не са безопасни за паметта, като C++, едва ли скоро ще станем свидетели на мащабна промяна на базите от кодове.

Ново всеобхватно проучване разкрива нови подробности за широкото и тревожно използване на код, който не е безопасен за паметта, в големи проекти за софтуер с отворен код (OSS).

Въпреки това, шансовете, че свежият поглед върху отдавна известен проблем ще предизвика незабавни промени в софтуерния пейзаж, остават слаби, като се има предвид колко огромна, скъпа и сложна е задачата за пренаписване на кодови бази изцяло с код, безопасен за паметта.

Езиците за програмиране, които не са безопасни за паметта, като C и C++, позволяват на програмистите да имат по-пряк контрол върху функциите, свързани с паметта в кода, което често може да доведе до много често срещани проблеми със сигурността на приложенията, като препълване на буфера и грешки от типа „use-after-free“. Такива грешки представляват голяма част от всички уязвимости в съвременния приложен софтуер. За разлика от тях езиците, които са безопасни за паметта – най-често срещаните примери за това са Rust, Python, Java и Go – предлагат предпазни огради, като например вградени проверки по време на изпълнение и компилиране, за да се намалят често срещаните грешки, свързани с паметта.

Повечето проекти на OSS съдържат код, който не е безопасен за паметта

Тази седмица Агенцията за киберсигурност и инфраструктурна сигурност на САЩ (CISA) заедно с ФБР и колегите си от Австралийския център за киберсигурност и Канадския център за киберсигурност публикуваха доклад, в който обобщават резултатите от разследването си за използването на код, който не е безопасен за паметта, в OSS.

Констатациите, макар и обезпокоителни, не са съвсем неочаквани, като се имат предвид предишни данни за широкото използване на езици, които не са безопасни за паметта, в почти всички съвременни кодови бази. Петдесет и два процента от 172-те големи проекта с отворен код, които авторите на изследването са разгледали, съдържат код, написан на език, който не е безопасен за паметта. Повече от половината (55 %) от общия брой редове код във всички проекти заедно са написани на език, който не е безопасен за паметта, като най-големите проекти са най-големите виновници.

Около 95 % от общия брой редове код в Linux например са написани на език, който не е безопасен за паметта. За MySQL Server този процент е 84%, за TensorFlow – 64%, за Zephyr – 84%, а за Chromium – 51%. Средно 26% от общия брой редове код в 10-те най-големи проекта с отворен код се състоят от код, който не е безопасен за паметта. Дори проектите, написани на езици, които са безопасни за паметта, са изложени на риск от зависимости от опасни компоненти.

„Повечето от анализираните критични проекти с отворен код, дори тези, написани на езици, безопасни за паметта, потенциално съдържат уязвимости в областта на безопасността на паметта“, се отбелязва в доклада. „Това може да бъде причинено от директното използване на езици, които не са безопасни за паметта, или от външни зависимости от проекти, които използват езици, които не са безопасни за паметта.“

Освен това тенденцията – а често и необходимостта – да се деактивират функциите за безопасност на паметта, за да се спазят функционалните изисквания в приложенията, често може да неутрализира ползите от използването на езици, които иначе са безопасни за паметта.

„Тези ограничения подчертават необходимостта от постоянно усърдно използване на езици за програмиране с безопасна памет, практики за безопасно кодиране и тестване на сигурността“, отбелязват авторите на доклада.

CISA е в съответствие с предишни данни за OSS

Констатациите съответстват на многобройни предишни проучвания, които разглеждат обширните проблеми, свързани с използването на езици, които не са безопасни за паметта.

И наистина, загрижеността за повсеместното разпространение на проблема е предизвиквала призиви за промяна през годините. Най-скорошният от тях е техническият доклад на Белия дом от февруари 2024 г., в който заинтересованите страни от индустрията се призовават да се върнат към градивните елементи и да започнат отначало с използването на безопасен за паметта код във всички програми. През 2022 г. Агенцията за национална сигурност на САЩ (NSA) призова създателите на софтуер и всички организации, разработващи софтуер, да обмислят приемането на езици, безопасни за паметта, за да се намали рискът от софтуерни проблеми, свързани с управлението на паметта, в съвременните кодови бази. Непрекъснатото повдигане на  темата през годините е подтикнало към известна промяна, но повечето очакват, че ще са необходими години – ако не и десетилетия – за да се осъществи цялостно преминаване към езици за безопасно използване на паметта.

„Възприемането на код, който е безопасен за паметта, е предизвикателство, най-вече защото промяната на езика за програмиране често изисква пълно пренаписване на съществуващия код“, казва Неацун Зив, главен изпълнителен директор и съосновател на OX Security. Разходите и усилията, необходими за предприемане на такава мащабна промяна без значителни икономически стимули, вероятно ще направят всяка промяна бавен процес.

Да направим света безопасен за паметта: Огромно и сложно предизвикателство

Омхар Арасаратнам, генерален мениджър на OpenSSF, казва, че проблемите с безопасността на паметта не са специфичен проблем нито за софтуера с отворен, нито за този със затворен код. Това е проблем като цяло за целия съвременен софтуер.

„Днес има много езици, които са безопасни за паметта, като JavaScript, Python и Java, но софтуерните инженери често използват по-стари езици, които не са безопасни за паметта, като C/C++, заради производителността или достъпа до хардуера на ниско ниво“, казва той.

Освен това, макар че през последните години Rust се наложи като жизнеспособна алтернатива на C/C++ за програмиране на системи от ниско ниво, има много вградени системи и критични за безопасността приложения, за които Rust не е подходящ, добавя той.

„Макар че със сигурност е възможно да се напише код, безопасен за паметта, на език, който не е безопасен за паметта, 25 години CVE ни казват, че това е малко вероятно“, казва Арасаратнам. „Не става дума за това, че хората са лоши програмисти, но защитното писане на код, който е безопасен за паметта, на език, който не е безопасен за паметта, е много трудно“, отбелязва той. Тъй като все по-нови проекти възприемат езици, безопасни за паметта, очаквайте с течение на времето използването на езици, които не са безопасни за паметта, да намалее във всички приложения, освен в нишовите.

Тим Маки, ръководител на стратегията за риска на веригата за доставки на софтуер в Synopsys Software Integrity Group, казва, че новият доклад добре показва как някои големи софтуерни проекти с отворен код, като Kubernetes и WordPress, са създадени на език, безопасен за паметта. Според него обаче има и други въпроси, които остават неизследвани. Например би било интересно да се разбере дали в новите проекти в GitHub се използват безопасни за паметта езици и дали в по-големите проекти се използват безопасни за паметта библиотеки като зависимости.

„Можем спокойно да кажем, че осведомеността за езиците за безопасност на паметта расте, но дали расте с темпове, които биха изместили по-старите езици? Например, дали създателите на нови софтуерни решения за вграждане използват C++ или Rust и в каква степен?“