Ontwikkelaars van die Chromium-projek 912 hoërisiko- en kritieke kwesbaarhede wat sedert 2015 in stabiele weergawes van Chrome geïdentifiseer is, en tot die gevolgtrekking gekom dat 70% daarvan veroorsaak is deur geheue-onsekerheid (foute wanneer met wysers in C/C++-kode gewerk word). Die helfte van hierdie probleme (36.1%) word veroorsaak deur toegang tot die buffer nadat die geheue wat daarmee geassosieer is (gebruik-na-vry) vrygestel is.
By die ontwerp van Chromium was dit aanvanklik , dat dit moontlik is dat foute in die kode verskyn, daarom is groot klem gelê op die gebruik van sandbox-isolasie om die gevolge van kwesbaarhede te beperk. Tans het die moontlikhede om hierdie tegnologie te gebruik die limiet van hul vermoëns bereik en verdere fragmentering in prosesse is onprakties vanuit die oogpunt van hulpbronverbruik.
Om die sekuriteit van die kodebasis te handhaaf, dwing Google ook "", waarvolgens enige bygevoegde kode nie meer as twee van drie voorwaardes moet voldoen nie: werk met ongevalideerde invoerdata, gebruik 'n onveilige programmeertaal (C/C++) en hardloop met verhoogde voorregte. Hierdie reël impliseer dat die kode vir die verwerking van eksterne data óf verminder moet word tot minimale voorregte (geïsoleer) óf in 'n veilige programmeertaal geskryf moet word.
Om die sekuriteit van die kodebasis verder te verbeter, is 'n projek van stapel gestuur om te verhoed dat geheuefoute in die kodebasis verskyn. Daar is drie hoofbenaderings: die skep van C++-biblioteke met funksies vir veilige werking van geheue en die uitbreiding van die omvang van die vullisverwyderaar, deur hardewarebeskermingsmeganismes te gebruik (Memory Tagging Extension) en skryfkomponente in tale wat veilige werk met geheue verseker (Java, Kotlin, JavaScript, Rust, Swift).
Daar word verwag dat werk op twee gebiede gefokus sal wees:
- Beduidende verandering aan die C++-ontwikkelingsproses, wat nie 'n negatiewe impak op prestasie uitsluit nie (bykomende grenskontroles en vullisverwydering). In plaas van rou wysers, word voorgestel om die tipe te gebruik , wat jou toelaat om uitbuitbare gebruik-na-vrye foute te verminder tot ineenstortings wat nie 'n sekuriteitsbedreiging inhou nie, sonder 'n merkbare negatiewe impak op werkverrigting, geheueverbruik en stabiliteit.
- Die gebruik van tale wat ontwerp is om geheueveiligheidskontroles tydens samestellingstyd uit te voer (sal die negatiewe impak op prestasie wat inherent is aan sulke kontroles tydens kode-uitvoering uitskakel, maar sal lei tot bykomende koste vir die organisering van die interaksie van kode in 'n nuwe taal met kode in C++).
Die gebruik van geheue-veilige biblioteke is die eenvoudigste, maar ook minder doeltreffende manier. Die herskryf van kode in Rust word as die doeltreffendste, maar ook baie duur manier aangewys.
Bron: opennet.ru