70% безбедносних проблема у Цхромиум-у је узроковано грешкама у меморији

Програмери Цхромиум пројекта анализирано 912 високоризичних и критичних рањивости идентификованих у стабилним издањима Цхроме-а од 2015. године и закључено је да је 70% њих узроковано несигурношћу меморије (грешке при раду са показивачима у Ц/Ц++ коду). Половина ових проблема (36.1%) је узрокована приступима баферу након ослобађања меморије повезане са њим (усе-афтер-фрее).

Приликом дизајнирања Цхромиум-а то је у почетку било положенода је могуће да се појаве грешке у коду, па је велики акценат стављен на коришћење сандбок изолације како би се ограничиле последице рањивости. Тренутно су могућности коришћења ове технологије достигле границу својих могућности и даља фрагментација на процесе је непрактична са становишта потрошње ресурса.

Да би одржао безбедност базе кодова, Гоогле такође примењује "правило двоје“, према којем сваки додат код мора да испуњава највише два од три услова: рад са непотврђеним улазним подацима, коришћење несигурног програмског језика (Ц/Ц++) и покретање са повишеним привилегијама. Ово правило подразумева да код за обраду екстерних података мора бити или сведен на минималне привилегије (изолован) или написан на безбедном програмском језику.

Да би се додатно побољшала безбедност базе кода, покренут је пројекат за спречавање појављивања меморијских грешака у бази кода. Постоје три главна приступа: креирање Ц++ библиотека са функцијама за безбедан рад меморије и проширење обима сакупљача смећа, коришћењем механизама хардверске заштите МТЕ (Мемори Таггинг Ектенсион) и компоненте за писање на језицима који обезбеђују безбедан рад са меморијом (Јава, Котлин, ЈаваСцрипт, Руст, Свифт).

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

• Значајна промена у Ц++ развојном процесу, што не искључује негативан утицај на перформансе (додатне провере граница и сакупљање смећа). Уместо сирових показивача, предлаже се коришћење типа МирацлеПтр, што вам омогућава да сведете грешке које се могу искористити без употребе на рушења која не представљају безбедносну претњу, без приметног негативног утицаја на перформансе, потрошњу меморије и стабилност.
• Употреба језика дизајнираних за обављање провера безбедности меморије у време компајлирања (елиминисаће негативан утицај на перформансе инхерентан таквим проверама током извршавања кода, али ће довести до додатних трошкова за организовање интеракције кода на новом језику са кодом у Ц++).

Коришћење библиотека безбедних за меморију је најједноставнији, али и мање ефикасан начин. Преписивање кода у Русту је оцењено као најефикаснији, али и веома скуп начин.

Извор: опеннет.ру