Chromiumi projekti arendajad Alates 912. aastast on Chrome'i stabiilsetes versioonides tuvastatud 2015 kõrge riskiga ja kriitilist turvaauku ning järeldati, et 70% neist on põhjustatud mälu ebaturvalisusest (vead C/C++ koodi osutitega töötamisel). Pooled neist probleemidest (36.1%) on põhjustatud juurdepääsust puhvrile pärast sellega seotud mälu vabastamist (use-after-free).
Chromiumi kujundamisel oli see algselt , et koodis võib esineda vigu, mistõttu pandi suurt rõhku liivakasti isolatsiooni kasutamisele, et piirata haavatavust. Praegu on selle tehnoloogia kasutamise võimalused jõudnud oma võimaluste piirini ning edasine killustamine protsessideks on ressursitarbimise seisukohalt ebapraktiline.
Koodibaasi turvalisuse säilitamiseks jõustab Google ka "“, mille kohaselt peab iga lisatud kood vastama mitte rohkem kui kahele tingimusele kolmest: töötamine kinnitamata sisendandmetega, ebaturvalise programmeerimiskeele (C/C++) kasutamine ja kõrgendatud õigustega töötamine. See reegel tähendab, et välisandmete töötlemise kood peab olema vähendatud minimaalsete privileegideni (isoleeritud) või kirjutatud turvalises programmeerimiskeeles.
Koodibaasi turvalisuse edasiseks suurendamiseks on käivitatud projekt, mille eesmärk on vältida mäluvigade ilmumist koodibaasis. On kolm peamist lähenemisviisi: C++ teekide loomine funktsioonidega mälu ohutuks kasutamiseks ja prügikoguja ulatuse laiendamine, kasutades riistvarakaitsemehhanisme. (Memory Tagging Extension) ja kirjutamiskomponendid keeltes, mis tagavad turvalise töö mäluga (Java, Kotlin, JavaScript, Rust, Swift).
Eeldatakse, et töö keskendub kahele valdkonnale:
- Oluline muudatus C++ arendusprotsessis, mis ei välista negatiivset mõju jõudlusele (täiendavad piirikontrollid ja prügivedu). Toorosutite asemel tehakse ettepanek kasutada tüüpi , mis võimaldab vähendada ärakasutatavate pärast-vaba kasutamise vigade arvu krahhideni, mis ei kujuta endast turvaohtu, ilma et see avaldaks märgatavat negatiivset mõju jõudlusele, mälutarbimisele ja stabiilsusele.
- Keelte kasutamine, mis on ette nähtud mälu ohutuse kontrollimiseks kompileerimise ajal (välistab sellistele kontrollidele koodi täitmise ajal omase negatiivse mõju jõudlusele, kuid toob kaasa lisakulusid uues keeles koodi interaktsiooni korraldamisel koodiga C++).
Mälukindlate teekide kasutamine on lihtsaim, kuid ka vähem tõhus viis. Koodi ümberkirjutamine Rustis on hinnatud kõige tõhusamaks, kuid ka väga kulukaks viisiks.
Allikas: opennet.ru