Hoe Google de veiligheidsrisico’s van Android met 52% heeft verminderd

Jarenlang heeft Google hard gewerkt om Android een steeds veiliger besturingssysteem te maken. Aanvallers zoeken naar elk lek dat ze kunnen misbruiken, met behulp van alledaagse methoden zoals phishing of complexere methoden zoals geheugenveiligheidslekken. Nu legt Google uit hoe de Safe Coding-aanpak de afgelopen jaren de geheugenveiligheidslekken in Android aanzienlijk heeft weten te verminderen.

Google gebruikt Safe Coding-aanpak tegen kwetsbaarheden in geheugenveiligheid

Geheugenveiligheidskwetsbaarheden zijn kwetsbaarheden die gebruikmaken van geheugengerelateerde bugs, zoals bufferoverlopen, format string-problemen of bungelende pointers, om te communiceren met of zelfs over het geheugen te schrijven. Dit soort kwetsbaarheden zijn nog steeds wijdverbreid aanwezig in softwareontwikkeling. Ontwikkelaars proberen ze vanuit verschillende benaderingen aan te pakken, waarbij mitigatie en proactieve detecties de boventoon voeren. Google is er echter van overtuigd dat Safe Coding de ideale benadering is om geheugenveiligheidskwetsbaarheden te minimaliseren, zoals blijkt uit de resultaten met Android.

De Safe Coding-aanpak geeft vanaf het begin prioriteit aan het gebruik van geheugenveilige programmeertalen. Er is echter software die al jaren oud is en miljoenen regels aan sleutelcode heeft die is ontwikkeld op ‘geheugenonveilige’ talen. Dus, wat is Google’s voorstel in deze gevallen? Het antwoord ligt in de geleidelijke overgang naar geheugenveilige talen (zoals Rust) voor nieuwe functies.

In principe stelt Google voor dat ontwikkelaars uitsluitend geheugenveilige talen gaan implementeren bij het ontwikkelen van nieuwe functies. In de tussentijd blijft oude code gebaseerd op onveilige talen “ongewijzigd” voorbij de klassieke onderhouds- en bugfixes. Dit vertaalt zich in het bereiken van veilige, efficiënte en kosteneffectieve interoperabiliteit tussen nieuwe en oude code.

De geheugenveiligheidsproblemen van Android zijn in 6 jaar met 52% gedaald

Volgens Google resulteerde de Safe Coding-aanpak in een daling van geheugenveiligheidskwetsbaarheden in Android van 76% naar 24% in slechts 6 jaar. Het idee om geheugenonveilige code te bewaren, kan echter tegenstrijdig lijken. Als u op zoek bent naar maximale beveiliging, zou uw eerste gedachte immers zijn om al uw code te migreren naar een veilige taal. Hoewel dit waar kan zijn, is de aanpak van Google logisch en het bedrijf legt uit waarom.

Bij softwareontwikkeling zijn code-efficiëntie en kosteneffectiviteit van cruciaal belang. Er zijn tools of hele systemen met vele jaren van ontwikkeling achter de rug. Dit omvat miljoenen en miljoenen fundamentele regels code. Terwijl een bedrijf gewoon software vanaf nul kan herschrijven op basis van geheugenveilige talen, zijn de investering en inspanning het waarschijnlijk niet waard. De situatie kan echter anders zijn bij relatief nieuwe ontwikkelingen die nog niet zo lang achter de rug zijn.

Voordelen van veilig coderen en interoperabiliteit

Google beweert dat de Safe Coding-aanpak, die is gebaseerd op code-interoperabiliteit, een kosteneffectieve en praktische manier is om geheugenveilige code te implementeren. Dit maakt het op zijn beurt kosteneffectief, omdat het bedrijven in staat stelt om eerdere investeringen te benutten. De kosten zijn aanzienlijk lager vergeleken met het herschrijven van software vanaf nul. Het is ook efficiënt omdat het nieuwe functies mogelijk maakt om te blijven ontwikkelen terwijl de nieuwe, veilige code wordt geïntegreerd.

Het gebruik van inherent geheugenveilige code zorgt ook voor lagere kosten op de lange termijn. Eerdere benaderingen waren gericht op een eindeloze cyclus van ‘aanvallen en verdedigen’ tussen ontwikkelaars en aanvallers. Vertrouwen op mitigaties en proactieve detecties vereiste voortdurende actie en investering als reactie op potentiële aanvallen. Safe Coding zorgt er echter voor dat ontwikkelaars en bedrijven dit kunnen vergeten, en zich kunnen richten op het onderhouden en verbeteren van functies of het oplossen van bugs.

Er is ook een hogere productiviteit dankzij lagere code rollback rates. Dat wil zeggen, er zijn minder noodgevallen met code rollback vanwege onverwachte bugs. Google beweert dat Rust code rollback rates biedt die minder dan de helft zijn van die van C++. In essentie levert Safe Coding aanzienlijke besparingen op in tijd en geld voor bedrijven en ontwikkelaars. In de huidige industrie, die nauwlettend de winstgevendheid in de gaten houdt, kan dit cruciaal zijn.

Google onthult dat het interoperabiliteit heeft geïmplementeerd tussen “Rust ↔︎ C++ en Rust ↔︎ Kotlin.” Het bedrijf heeft ook geld en tools bijgedragen om zijn aanpak te ondersteunen. Google gaf bijvoorbeeld $ 1.000.000 aan de Rust Foundation om zijn evolutie te stimuleren. Het leverde ook zijn eigen interoperabiliteitstools, zoals Crubit en autocxx.

Google geheugen veilige kwetsbaarheden (3)

Zo maakt de Safe Coding-aanpak software veiliger

U vraagt ​​zich misschien nog steeds af hoe een aanpak die geheugen-onveilige code houdt, kan leiden tot een exponentiële vermindering van geheugenveiligheidskwetsbaarheden. Google legt dit ook uit in zijn blogpost, op een zeer technische manier, maar ik zal proberen het voor iedereen eenvoudig te maken.

Via grootschalige studies ontdekten USENIX Security en Google zelf een intrigerend fenomeen. In principe concludeerde het onderzoek dat de overgrote meerderheid van de geheugenkwetsbaarheden in software hun oorsprong vinden in nieuwe code. Een aanzienlijk deel is ook afkomstig van recent gewijzigde code. Google merkte ook op dat de dichtheid van Android-geheugenveiligheidskwetsbaarheden geleidelijk afnam in oude code.

Aangezien een aanzienlijk deel van het probleem voortkomt uit nieuwe code, is het logisch om je daarop te richten, toch? Dit is de redenatie achter Google’s besluit om de Safe Coding-aanpak te hanteren. Maar waarom stapelen zich meer problemen en kwetsbaarheden op in nieuwe code? Dit komt omdat elke programmeertaal een fundamentele eigenschap heeft: maturatie.

Hoewel de fundamentele structuur van een taal het geheugenonveilig kan maken, kunnen opeenvolgende updates helpen dit te verminderen. Dus, theoretisch gezien, kan onveilige code die in oudere delen van de software wordt gebruikt, na verloop van tijd minder kwetsbaar worden. Door de rijping van oudere code te combineren met nieuwe functies die zijn ontwikkeld in nieuwe, inherent geheugenveilige code, zal het resultaat een exponentiële afname van geheugenkwetsbaarheden zijn.

Google geheugen veilige kwetsbaarheden (2)

Google beveelt Rust aan als geheugenveilige taal

Natuurlijk kan het porten van delen van oudere code naar talen als Rust de zaken nog veiliger maken. Dit is echter niet altijd mogelijk, althans niet op een eenvoudige manier. Er zijn gevallen waarin het verplaatsen van één blok het hele kasteel kan laten instorten. Google is vastbesloten over Rust als een geheugenveilige programmeertaal. Dus als u geïnteresseerd bent in het leren van programmeren of een nieuwe taal om concurrerend te zijn in de industrie van vandaag, dan is Rust misschien wat u zoekt.

Geheugenveiligheidskwetsbaarheden zijn niet de enige. Kwaadwillende derden zullen blijven zoeken naar manieren om de beveiligingslagen van software te omzeilen. Maar sterke barrières in de ‘ingewanden’ van de software zorgen ervoor dat aanvallers hun toevlucht moeten nemen tot meer alledaagse en gemakkelijk te neutraliseren methoden. U kunt bijvoorbeeld voorkomen dat u slachtoffer wordt van phishing door gewoon uw gezonde verstand te gebruiken.

Thijs Van der Does