Har du någonsin undrat hur säkerhetsbrister kan hittas? Det brittiska företaget GraphicsFuzz förklarar hur de stötte på ett grafikdrivrutinfel på Samsung Galaxy S6 som de kunde utnyttja för att se data från öppna flikar i Google Chrome.
I slutet av mars kontaktade ett brittiskt nystartat företag som specialiserat sig på att testa GPU-tillförlitlighet oss med en GPU-bugg de upptäckte som orsakar Qualcomm Snapdragon 845Samsung Galaxy S9/S9+ för att starta om när du besöker en webbsida. Företaget, ringde GraphicsFuzz, arbetat med oss för att rapportera problemet till Qualcomm och Samsung. Några av våra läsare var intresserade av att lära sig hur ett företag gillar GraphicsFuzz kan hitta dessa sårbarheter, så vi samarbetade med företaget för att visa upp hur de upptäckte en äldre GPU-sårbarhet. Denna redan korrigerade sårbarhet gjorde det möjligt för en angripare att på distans "spionera" på innehållet i Google Chrome webbläsarflikar på Samsung Galaxy S6.
Den här användaren tittade på sin banks webbplats innan han besökte den skadliga webbsidan. Innehållet fångades in och laddades upp till en fjärrserver. Källa: GraphicsFuzz.
Hur GraphicsFuzz hittar GPU-buggar
En grafikdrivrutin fungerar genom att ta ett shader-program och skicka det till GPU: n för att exekveras och på så sätt rendera bilden. Innan du skickar shadern till GPU: n, översätter grafikdrivrutinen den till en form som GPU: n kan förstå; en felaktig översättning kan leda till renderingsfel, program- eller enhetskrascher, felaktiga bilder och till och med säkerhetsproblem. GraphicsFuzz har en automatiserad testsvit som låter dem hitta dessa buggar baserat på en uppsättning referensshaders. När en användare kör sitt test, alla de resulterande bilderna ska se likadana ut. Alla bilder som ser annorlunda ut betyder att det fanns en bugg.
Resultat av flera populära enheter som kör GraphicsFuzz-testsviten. Samsung Galaxy S6, Samsung Galaxy S7 och Samsung Galaxy S8 ingår i dessa diagram. Källa: GraphicsFuzz.
För Samsung Galaxy S6, GraphicsFuzz upptäckte att bilderna i en av raderna visade bilder som skulle finnas i en annan tabell. Det betyder att bilder från tidigare tester läckte in i senare tester. Teamet körde sedan om testsviten i Google Chrome och upptäckte att delar av webbsidan förekom i bilden. Dessutom fann de att öppnandet av en annan flik gjorde att bilden visade delar av andra flikar. I grund och botten tillät denna bugg en Google Chrome-flik att läcka information om en annan Chrome-flik! Teamet bakom GraphicsFuzz letade inte avsiktligt efter säkerhetsbuggar, men det slutade med att de hittade en som ett resultat av deras testning. (Det bör noteras att teamet återskapade buggen på den vanliga Samsung-webbläsaren på Galaxy S6 såväl som Mozilla Firefox.)
Hur buggen fungerar
Bild som används för att utlösa den långvariga buggen på Samsung Galaxy S6. Källa: GraphicsFuzz.
Den "skadliga" webbsidan skapad av GraphicsFuzz använder WebGL för att försöka rita en rymdscen inuti en duk som visas ovan. Färgen på varje pixel bestäms av en fragment shader, ett program som tillhandahålls av webbsidan för att köras på GPU: n. De GraphicsFuzz ramverket modifierade fragmentskuggningen vilket fick den att köras under en riktigt lång tid. När en skuggning körs för länge avbryter webbläsaren eller operativsystemet vanligtvis renderingen. Men medan GPU: n avbröt renderingen efter att ha ritat några pixlar, rapporterade GPU-drivrutinen inte detta till Google Chrome. (Om du tar en titt på bilden överst i artikeln som visar skräpvideominne, kan du faktiskt se delar av rymdscenen i toppen vänster.) Detta innebär att pixlarna som renderades innan avbrytningen lämnas orörda, vilket innebär att den slutliga renderade bilden mestadels är skräpvideo minne. Eftersom videominne kontinuerligt används för att rendera andra webbsidor, innehåller "skräp"-data faktiskt tidigare renderingar av andra webbsidor. Det slutar med att andra webbsidor visas på den "skadliga" webbsidan. Det avgörande är att WebGL tillåter webbsidan att fånga innehållet i vad som än renderas; denna bild laddas sedan upp till en fjärrserver.
Diagram som förklarar det långvariga GPU-felet som gör att Chrome-flikdata "läcker". Källa: GraphicsFuzz.
Google Chrome använder flera processer så olika flikar är ofta isolerade, vilket gör att detta utnyttjande verkar omöjligt på ytan. Chrome interagerar dock med GPU: n med en enda "GPU-process", vilket innebär att alla flikar delar samma GPU-minne, vilket gör att denna exploatering kan fungera. Diagrammet ovan visar detta mer i detalj.
Felet visas i den här videon under de första 22 sekunderna. Andra säkerhetsproblem som hittats av GraphicsFuzz visas också.
Lärdomar att dra
En GPU som inte beter sig kan kringgå alla Google Chromes och Androids säkerhetsåtgärder eftersom WebGL tillåter alla skadliga webbsidor att skicka kod till GPU: n för exekvering. Google kan inte fixa GPU-buggar eftersom företaget inte kontrollerar hårdvaran och drivrutinerna. I det här fallet är det upp till GPU-leverantören (i det här fallet ARM) att fixa buggen och OEM vars enheter påverkas (i det här fallet Samsung) att integrera korrigeringen i en uppdatering. Lägg till bärare till mixen och det är lätt att se hur en bugg som denna kan ta väldigt lång tid att fixa – det tog minst 5 månader för de flesta Samsung Galaxy S6-användare att få patchen.
GraphicsFuzz hjälper GPU-leverantörer att hitta svårupptäckta buggar som felkompileringsbuggar som gör att fel kod genereras och exekveras på GPU: n. Deras automatiserade testramverk låter dem hitta buggar som den som visas upp i den här artikeln. Den långvariga loopen som orsakas av den "skadliga" webbsidan har också visat sig orsaka problem på andra enheter som t.ex. HTC One M7 och på senare tid Samsung Galaxy S9. GraphicsFuzz testar flaggskeppssmartphones och publicerar en resultattabell som rangordnar dessa enheter baserat på deras prestanda på en delmängd av deras tester. Hundratals krascher och renderingsfel har hittats under deras testning, men de flesta undersöks inte för att se om de utgör ett säkerhetshot. Men som visas av detta utnyttjande är en felaktig GPU en säkerhetsrisk, och det är möjligt att en eller flera kritiska säkerhetsbrister väntar på att upptäckas. GraphicsFuzz hoppas att GPU-leverantörer prioriterar att förbättra förarkvaliteten i framtiden.
Jämförande tillförlitlighet för grafikdrivrutiner, sorterade efter antalet totala problem. Källa: GraphicsFuzz.
Tidslinje för avslöjande
- I december 2016 GraphicsFuzz rapporterade felet till Google Chromium buggspårare eftersom den var kvalificerad för Chrome Reward-programmet. Efter att GraphicsFuzz skickade in felet till Google Chromium-felspåraren accepterades felet av Google och skickade det vidare till ARM och Samsung för korrigering.
- Google vidarebefordrade rapporten till kontakter hos ARM och Samsung.
- Samsung patchade felet tyst och rullade ut korrigeringen i Android 7.0 Nougat-uppdateringen som släpptes mellan mars och juni 2017. Även om det inte fanns någon CVE skapad av Samsung, Google eller ARM och varken Samsung eller ARM släppte någon information om patchen, notera att GraphicsFuzz rapporterade inte felet via korrekt process.
- Senare, GraphicsFuzz kunde bekräfta att både Samsung och ARM hade sett rapporten och att ARM kunde åtgärda problemet på grund av rapporten.
- I augusti 2017, GraphicsFuzz belönades med $2 000 av Google för felrapporten.
- I november 2017, felrapporten offentliggjordes.