Från länken i artikeln står bl.a.
"Using our research methodologies and state-of-the-art fuzz testing technologies,"
Mer konkret lär komma på torsdag denna vecka när Check point håller en presentation kring detta, men låter väldigt mycket som buggarna är programvarubuggar och inte HW-buggar.
Av allt att döma är detta första gången någon tittar på kodbasen som kör Snapdragons DSP från det här perspektivet, tyvärr är det då rätt väntat att man hittar rätt många problem. Sedan är frågan vad man menar med "400 säkerhetsbrister" givet att det, så här lång i alla fall, bara utmynnat i 6 st CVE:er.
Är inte alls osannolikt att man egentligen bara hittat 6 unika hål som man sedan har skapat över 400 olika fall som kan utnyttja. Förhoppningsvis är inte det fallet, för i det läget tycker jag säkerhetsforskarna skriker "VARG" lite väl i hopp om man skapa rubriker.
För att få lite perspektiv på det hela: man hittar runt 100-200 unika säkerhetsproblem i Windows-, Linux- och MacOS-kärnorna per år. I fallet Windows är i storleksordningen en per månad av dessa ett kritisk säkerhetshål som möjliggör att något får total kontroll över systemet utan att behöva några speciella rättigheter på systemet mer än att kunna köra kod.
Men vi vet ju alla att Microsofts kvalité suger... Faktum är att det är rätt normalt med runt 10-50 buggar per 1000 rader kod och Microsoft ligger klart under detta normalvärde på 5-10 buggar per 1000 rader kod. Gissar att rent generellt håller koden i OS långt högre kvalité än "normal" kod, dels då hål här är långt värre och dels p.g.a. föregående är det långt mer intressant att leta hål där.
Här är väl det "värsta" med det man har hittat i Snapdragon, i praktiken är allt som kör på dess DSP del av OS-kärnan så buggar där är värre! Poängen är bara: tror inte Qualcomm på något sätt har sämre kvalité än någon annan, de har bara blivit tillräckligt vanliga för att man likt Windows och Linux kärnorna ska börja mer kritiskt granska kod som är specifik till Snapdragon. Föga oväntat hittar man då saker.
Hittade något om att en typisk Android/iOS applikation tar 50k rader kod, de är i sin tur säker mer komplicerade än rätt mycket av det som utvecklas. Systemprogramvara tenderar ligga på en helt annan skala, Android självt är 12-15 miljoner rader, Chrome (som börjar snart är ett OS självt) är >6 miljoner rader och Googles back-end uppskattas till 2 miljarder rader kod.
Vet inte hur mycket kod som kan tänkas finnas i en DSP, men det lär röra sig om höga hundratusentals rader eller låga miljontals rader kod. Så även om man håller lysande kod-kvalité finns det ~10000 buggar. Långt ifrån alla är så klart säkerhetshål, men en del är så klart det.
Det har praktiskt bevisats att man faktiskt kan skriva nära nog bug-fri kod, sådan finns i de mest kritiska delarna av flygplan, tåg etc. Det är fullt möjligt att hantera det upp till kodbaser på i alla fall hundratusentals rader kod, NASA ska enligt länken jag postade ovan ha lyckats med det i deras rymdsonder. Problemet är att sådan kod är svindyr. Kod skriven mot "Design Assurance Level A" för flygplan förväntas kosta hundratals dollar per rad och NASA uppskattade kostnaden för deras kod till ~$1000 per rad.
Så i prispressade konsumentprodukter får man räkna med hyfsat med buggar. Man kan acceptera att de finns oavsett produkt, eller välja att hela tiden hoppa till saker där man ännu inte gjort någon djupare analys... Det man bör hålla koll på är hur en tillverkare agerar när hål faktiskt uppdagas, de som kör strutstaktik och försöker dribbla bort problem bör undvikas och de som löser problemen på ett professionellt sätt bör premieras. Får se hur Qualcomm hanterar detta!