70% от проблемите с безопасността в Chromium са причинени от грешки при работа с паметта

Разработчиците на проекта Chromium анализираха 912 опасни и критични уязвимости, открити в стабилните версии на Chrome от 2015 г., и изводите, че 70% от тях са били причинени от небезопасна работа с паметта (грешки при работа с указатели в кода на C/C++). Половината от тези проблеми (36.1%) са причинени от достъпи до буфера след освобождаването на свързаната с него памет (use-after-free).

При проектирането на Chromium първоначално е заложено, че в кода не се изключва появата на грешки, затова голям акцент е поставен на прилагането на sandbox-изолация за ограничаване на последствията от проявлението на уязвимостите. В момента възможностите за прилагане на тази технология достигнаха пределите на своите възможности и по-нататъшното дробене на процесите не е целесъобразно от гледна точка на потреблението на ресурси.

За поддържане на сигурността на кодовата база Google също така прилага "правилото на двата". Това правило гласи, че всеки добавен код трябва да отговаря на не повече от две от трите условия: работа с непроверени входни данни, използване на небезопасен език за програмиране (C/C++) и изпълнение с повишени привилегии. От това правило следва, че кодът за обработка на външни данни трябва или да бъде ограничен до минимални привилегии (изолиран), или да бъде написан на безопасен език за програмиране.

За допълнително усилване на защитата на кодовата база е стартиран проект за предотвратяване на появата на грешки в работата с паметта в кодовата база. Извеждат се три основни подхода: създаване на C++ библиотеки с функции за безопасна работа с паметта и разширяване на обхвата на приложения на сборщика на боклук, прилагане на хардуерни механизми за защита MTE (Memory Tagging Extension) и писане на компоненти на езици, осигуряващи безопасна работа с паметта (Java, Kotlin, JavaScript, Rust, Swift).

Очаква се работата да бъде съсредоточена в две направления:

• Съществени промени в процеса на разработка на C++, които не изключват негативно влияние върху производителността (допълнителни проверки на граници и събиране на боклука). Вместо raw-указатели се предлага в кода да се използва типът MiraclePtr, който да намали експлоатираните грешки от класа use-after-free до неопасни сривове, без осезаемо негативно влияние върху производителността, потреблението на памет и стабилността.
• Използването на езици, проектирани да извършват проверки за безопасна работа с паметта по време на компилация (това ще изключи негативното влияние върху производителността, присъщо за подобни проверки по време на изпълнение на кода, но ще доведе до допълнителни разходи за организиране на взаимодействието на кода на новия език с кода на C++).

Използването на библиотеки за безопасна работа с паметта е най-простият, но и по-малко ефективен метод. Пренаписването на кода на Rust се оценява като най-ефективния, но и много скъп път.

Източник: opennet.ru