Chromiumi 70% turvaprobleemidest on tingitud mäluhalduse vigadest

Chromiumi projekti arendajad analüüsisid Kuna alates 2015. aastast on Chrome'i stabiilsetes versioonides tuvastatud 912 ohtlikku ja kriitilist haavatavust, on järeldatud, et 70% neist on põhjustatud mäluhaldusvigadest (poodiumide vigadest C/C++-s). Pool neist probleemidest (36.1%) on põhjustatud mälu vabastamise järgsest püüdest leida seotud mälukohta (use-after-free).

Chromiumi kavandamisel oli algselt arvestatud, et koodis võivad esineda vead, seetõttu pandi suur rõhk liivakasti isolatsiooni rakendamisele haavatavuste tagajärgede piiramise jaoks. Praegu on selle tehnoloogia rakendamise võimalused saavutanud oma potentsiaali piiri ning edasine protsesside jagamine pole ressursside tarbimise mõttes mõttekas.

Google rakendab koodibaasi turvalisuse tagamiseks ka "kahe reegelKood peab vastama mitte rohkem kui kahele kolmest tingimusest: töötama kontrollimata sisenditega, kasutama ebaturvalist programmeerimiskeelt (C/C++) ja toimima suurenenud õigustega. Sellest reeglist tuleneb, et väliste andmete töötlemiseks mõeldud kood peab kas olema piiratud minimaalsete õigustega (isoleeritud) või kirjutatud turvalises programmeerimiskeeles.

Koodibaasi kaitse edendamiseks on käivitatud projekt, mille eesmärk on vältida mäluhalduse vigu koodibaasis. Tõstetakse esile kolm peamist lähenemist: C++ raamatukogude loomine mälu turvaliseks haldamiseks, prügikorjaja kohaldamise laiendamine, riistvara kaitsemehhanismide rakendamine, MTE (Memory Tagging Extension) ja komponentide kirjutamine keeles, mis toetab mälu turvalist haldamist (Java, Kotlin, JavaScript, Rust, Swift).

Oodata on, et töö keskendub kahele suunale:

• Oluline muudatus C++ arendusprotsessis, mis ei välista negatiivset mõju jõudlusele (lisakontrollid ja mälu koristamine). Soovitatakse kasutada koodis tüüp MiraclePtr, mis vähendab eksisteerivatest use-after-free klassi vigadest tingitud potentsiaalselt ohtlikke krahhe, ilma märkimisväärse negatiivse mõjuta jõudlusele, mälu tarbimisele ja stabiilsusele.
• Keeltes, mis on suunatud mäluga töötamise ohutuse kontrollimise tegemisele kompileerimise ajal (see välistab koodi täitmise ajal toimuvate kontrollide negatiivse mõju jõudlusele, kuid toob kaasa täiendavad kulud uue keele ja C++ koodi omavahelise koostöö korraldamisel).

Mäluga ohutu töötamise raamatukogude kasutamine on kõige lihtsam, kuid vähem tõhus meetod. Koodi ümberkirjutamine Rustis hinnatakse kui kõige tõhusamat, kuid ka väga kallist teed.

Allikas: opennet.ru