Ontwikkelaars van het Chromium-project 912 risicovolle en kritieke kwetsbaarheden geïdentificeerd in stabiele releases van Chrome sinds 2015, en geconcludeerd dat 70% daarvan werd veroorzaakt door geheugenonveiligheid (fouten bij het werken met verwijzingen in C/C++-code). De helft van deze problemen (36.1%) wordt veroorzaakt door toegang tot de buffer na het vrijmaken van het bijbehorende geheugen (use-after-free).
Bij het ontwerpen van Chromium was dat in eerste instantie zo , dat het mogelijk is dat er fouten in de code voorkomen, dus werd er grote nadruk gelegd op het gebruik van sandbox-isolatie om de gevolgen van kwetsbaarheden te beperken. Momenteel hebben de mogelijkheden om deze technologie te gebruiken de grens van hun capaciteiten bereikt en verdere fragmentatie in processen is onpraktisch vanuit het oogpunt van het verbruik van hulpbronnen.
Om de veiligheid van de codebase te behouden, handhaaft Google ook "“, volgens welke elke toegevoegde code aan niet meer dan twee van de drie voorwaarden moet voldoen: werken met niet-gevalideerde invoergegevens, een onveilige programmeertaal gebruiken (C/C++) en draaien met verhoogde rechten. Deze regel impliceert dat de code voor het verwerken van externe gegevens moet worden teruggebracht tot minimale privileges (geïsoleerd) of moet worden geschreven in een veilige programmeertaal.
Om de veiligheid van de codebasis verder te verbeteren, is er een project gestart om te voorkomen dat geheugenfouten in de codebasis voorkomen. Er zijn drie hoofdbenaderingen: het creëren van C++-bibliotheken met functies voor een veilige werking van het geheugen en het uitbreiden van de reikwijdte van de garbage collector, met behulp van hardwarebeschermingsmechanismen (Memory Tagging Extension) en schrijfcomponenten in talen die veilig werken met geheugen garanderen (Java, Kotlin, JavaScript, Rust, Swift).
Er wordt verwacht dat de werkzaamheden zich op twee gebieden zullen concentreren:
- Aanzienlijke verandering in het C++-ontwikkelingsproces, die een negatieve impact op de prestaties niet uitsluit (extra grenscontroles en garbage collection). In plaats van ruwe verwijzingen wordt voorgesteld om het type te gebruiken , waarmee u exploiteerbare use-after-free-fouten kunt reduceren tot crashes die geen veiligheidsrisico vormen, zonder een merkbare negatieve impact op de prestaties, het geheugengebruik en de stabiliteit.
- Het gebruik van talen die zijn ontworpen om geheugenveiligheidscontroles uit te voeren tijdens het compileren (zal de negatieve impact op de prestaties die inherent zijn aan dergelijke controles tijdens code-uitvoering elimineren, maar zal leiden tot extra kosten voor het organiseren van de interactie van code in een nieuwe taal met code in C++).
Het gebruik van geheugenveilige bibliotheken is de eenvoudigste, maar ook minder efficiënte manier. Het herschrijven van code in Rust wordt beoordeeld als de meest effectieve, maar ook erg dure manier.
Bron: opennet.ru