Распрацоўнікі праекта Chromium 912 небяспечных і крытычных уразлівасцяў, выяўленых у стабільных выпусках Chrome з 2015 гады, і дашлі да высновы, што 70% з іх былі выкліканыя небяспечнай працай з памяццю (памылкамі пры працы з паказальнікамі ў кодзе на C/C++). Палова з дадзеных праблем (36.1%) выклікана зваротамі да буфера пасля вызвалення звязанай з ім памяці (use-after-free).
Пры праектаванні Chromium было першапачаткова , што ў кодзе не выключана з'яўленне памылак, таму вялікая стаўка рабілася на ўжыванне sandbox-ізаляцыі для абмежавання наступстваў праявы ўразлівасцяў. У цяперашні час магчымасці прымянення гэтай тэхналогіі дасягнулі мяжы сваіх магчымасцей і далейшае драбненне на працэсы немэтазгодна з пункту гледжання спажывання рэсурсаў.
Для падтрымання бяспекі кодавай базы Google таксама прымяняе ««, у адпаведнасці з якім любы код, які дадаецца, павінен падпадаць не больш, чым пад дзве ўмовы з трох: праца з неправеранымі ўваходнымі дадзенымі, выкарыстанне небяспечнай мовы праграмавання (C/C++) і выкананне з падвышанымі прывілеямі. З гэтага правіла вынікае, што код для апрацоўкі вонкавых дадзеных павінен альбо быць зрэзаны да мінімальных прывілеяў (ізаляваны), альбо быць напісаны на бяспечнай мове праграмавання.
Для далейшага ўзмацнення абароненасці кодавай базы запушчаны праект па прадухіленні з'яўлення памылак працы з памяццю ў кодавай базе. Вылучаецца тры асноўныя падыходы: стварэнне бібліятэк С++ з функцыямі для бяспечнай працы з памяццю і пашырэнне вобласці ўжывання зборшчыка смецця, ужыванне апаратных механізмаў абароны (Memory Tagging Extension) і напісанне кампанентаў на мовах, якія забяспечваюць бяспечную працу з памяццю (Java, Kotlin, JavaScript, Rust, Swift).
Чакаецца, што работа будзе сканцэнтравана ў двух напрамках:
- Значная змена працэсу распрацоўкі на З++, не выняткоўвалае негатыўнага ўплыву на прадукцыйнасць (дадатковыя праверкі меж і зборка смецця). Замест raw-паказчыкаў прапануецца выкарыстоўваць у кодзе тып , які дазваляе звесці эксплуатаваныя памылкі класа use-after-free да якія не ўяўляюць пагрозу бяспецы крахам, без адчувальнага негатыўнага ўплыву на прадукцыйнасць, спажыванне памяці і стабільнасць.
- Ужыванне моў, разлічаных на выкананне праверак бяспечнай працы з памяццю падчас кампіляцыі (дазволіць выключыць негатыўны ўплыў на прадукцыйнасць, уласцівае падобным праверкам падчас выканання кода, але прывядзе да дадатковых выдаткаў на арганізацыю ўзаемадзеяння кода на новай мове з кодам на З++).
Выкарыстанне бібліятэк для бяспечнай працы з памяццю з'яўляецца найболей простым, але і меней эфектыўным спосабам. Перапісванне ж кода на Rust ацэньваецца як найбольш эфектыўны, але і вельмі дарагі шлях.
Крыніца: opennet.ru