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

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

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

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

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

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

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

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

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

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

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

Добавяне на нов коментар