Qualcomm repareert kwetsbaarheden voor onbekende bugs in dsp van Snapdragon-socs

Qualcomm heeft patches uitgebracht voor meerdere kwetsbaarheden in de digital signal processors van zijn socs. Die kwetsbaarheden zijn ontdekt door onderzoekers van Check Point, maar inhoudelijke details zijn nauwelijks gegeven.

Qualcomm heeft patches uitgebracht voor de Hexagon-dsp's in zijn chips, dat zijn onderdelen van de Snapdragon-socs die in veel Android-smartphones zitten. De dsp's worden onder andere gebruikt voor het verwerken van audio-, video- en telecomsignalen. Smartphonefabrikanten moeten de patches zelf implementeren en verstrekken voor hun respectievelijke apparaten.

Afgelopen weekend liet beveiligingsbedrijf Check Point weten dat het verschillende kwetsbaarheden in die dsp's zou hebben ontdekt, al geeft het bedrijf daar geen details over. De kwetsbaarheden maken het volgens Check Point onder andere mogelijk om informatie en bestanden van smartphones te bemachtigen, waaronder foto's, video's, realtime microfoonopnames en locatiegegevens van gebruikers. Hiervoor zou geen gebruikersinteractie nodig zijn. De kwetsbaarheid kan telefoons ook permanent laten vastlopen, waardoor alle gegevens op zo'n toestel verloren gaan.

De kwetsbaarheden hebben zes cve-codes gekregen: CVE-2020-11201, CVE-2020-11202, CVE-2020-11206, CVE-2020-11207, CVE-2020-11208 en CVE-2020-11209. Die zijn echter gereserveerd en bieden geen concrete informatie. Zowel Check Point als Qualcomm delen verder geen technische details over de kwetsbaarheid, omdat de kans 'dat deze informatie in verkeerde handen valt' volgens het bedrijf groot is. Check Point heeft het rapport naar eigen zeggen gepubliceerd om 'bewustwording over de kwetsbaarheid te creëren'.

Qualcomm laat aan Bleeping Computer weten dat het momenteel 'geen bewijs heeft dat de kwetsbaarheid wordt misbruikt'. Het bedrijf raadt gebruikers aan om hun apparaten regelmatig te updaten en om alleen applicaties uit de Play Store van Google te installeren.

Reacties (43)

[fapkonijntje]

De Hexagon DSP doet wel meer dan alleen audio, video en telecomsignalen. Er zit sinds een paar jaar ook een heel ML/AI stukje hardware bij met een SDK. Een beetje wat HiSilicon sinds de Kirin 970 doet en Apple met de Bionic merknaam. Iets dat ookwel een NPU heet. Met ondersteuning voor bijvoorbeeld TensorFlow.

Google maakt er voor de camera ook actief gebruik van, want de Google camera software werkt juist qua beeldverwerking zo goed, dankzij de Hexagon DSP. Iets waar Nokia met de Lumia serie met Qualcomm socs met Hexagon DSP ooit mee begon. Wat ik mij hierbij wel afvraag is of de PIxel1 deze fix nog gaat krijgen.

[jvnknvlgl]

...Google camera software werkt juist qua beeldverwerking zo goed, dankzij de Hexagon DSP...

Google heeft ook een eigen stukje hardware, de Pixel Visual Core, die iets vergelijkbaars doet. In ieder geval in de Pixel 2 was dat een cluster met een eigen CPU-kern, wat werkgeheugen en dan een aantal IPU's.

https://en.wikichip.org/wiki/google/pixel_visual_core

[Cerberus_tm]

Maar de Pixel 3a heeft die speciale kern niet. Dus misschien gebruikt die daar wel de DSP voor?

[Deakers]

Is er en lijst met toestellen beschikbaar waar deze soc's inzitten ?

[deSenna24]

Even Googlen naar de DSP en krijg deze lijst van Qualcomm zelf, hier staan wel wat chipsets op maar de meest moderne of high-end zijn niet opgelijst hier.
https://developer.qualcom...gon-dsp-sdk/dsp-processor

[Robbemans]

In principe alle devices waar een Qualcomm SOC in zit... Dat zijn er nogal wat.

[Mrjraider]

Qualcomm heeft patches uitgebracht voor de Hexagon-dsp's in zijn chips, dat zijn onderdelen van de Snapdragon-socs die in veel Android-smartphones zitten. De dsp's worden onder andere gebruikt voor het verwerken van audio-, video- en telecomsignalen. Smartphonefabrikanten moeten de patches zelf implementeren en verstrekken voor hun respectievelijke apparaten.

Vooral dat laatste gaat dus niet gebeuren. Alleen high end toestellen of toestellen die het voor het gros van de fabrikanten het nog waard is gaan deze patch krijgen. Jammer maar helaas.

[t link]

De fairphone 2 en 3 gaat hem waarschijnlijk ook wel krijgen (al duurt het mogelijk een maandje of 3) dat is het voor de fabrikant niet direct waard maar is wel waar ze voor staan. dat is ook specefiek waarom ik daar een telefoon heb gekocht.

[ari3]

Het is een ontwerpfout in Android dat firmware/microcode alleen met een update van de fabrikant vernieuwd kan worden. In Linux, waar Android op gebaseerd is, kun je de firmware gewoon als los package updaten. Er is geen reden waarom er geen apps in de Play store zouden kunnen staan die firmware bijwerken gebaseerd op detectie van specifieke hardware. Google heeft bewust een ecosysteem opgezet dat apparaten al snel onveilig maakt wegens het uitblijven van updates. Het is vooral bedoeld om apparaten versneld te laten vervangen. Geen updates is per definitie onveilig.

[Verwijderd]

Android gebruikt een Linux kernel en dat is de oorzaak van het probleem dat Android toestellen weinig updates krijgen. Voor iedere Linux kernel moet er een nieuwe driver gecompileerd worden omdat er geen stabiele API voor drivers is. Het daardoor niet mogelijk een oudere driver te gebruiken met een nieuwe kernel. Zou Android een stabiele API voor drivers gebruiken dan zou de kernel geupdate kunnen worden zonder dat drivers aangepast moeten worden.

[TheVivaldi]

Dat is niet helemaal waar, want een hoop Android-toestellen draaien op de LTS-kernel, en die API is en blijft wel degelijk stabiel.

[locke960]

Met hetzelfde recht kun je stellen dat de closed source drivers het probleem zijn. Als die open zouden zijn kan iedereen zo een nieuwe driver compileren.

Het echte probleem is natuurlijk dat er voor een open kernel gekozen is in een anderszins gesloten landschap. De beheerders van die kernel hangen namelijk de 'open' filosofie aan, en vinden daarom een stabiele API niet nodig. Je kunt tenslotte gewoon hercompileren.

[Robbemans]

Hoewel je een valide punt hebt is dit eigenlijk te gek voor woorden. 'Heel de wereld' draait hierop en eigenlijk zouden alle telefoons geupdatet moeten worden hiervoor. Het is niet een klein lekje...

[t link]

stem met je portomonee zou ik zeggen. er zijn merken die het wel proberen te doen en hun telefoon 6 jaar lang blijven updaten, al is het dan niet maandelijks meer.

[Reactie gewijzigd door t link op 23 juli 2024 11:07]

[TheVivaldi]

Dat is altijd zo makkelijk gezegd, "stem met je portemonnee". Leuk hoor dat 1 iemand met zijn/haar portemonnee stemt, maar van 1 iemand ligt een fabrikant niet wakker.

[t link]

Oh helemaal mee eens! maar er zijn wel alternatieven die je kan kopen.ik geloof ook niet zo in het princiepe stem met je portomonee, maar een alternatief is er niet echt omdat ons economisch systeem daarop ontworpen is.

[GertMenkel]

Lost deze update het probleem ook op? Van wat ik heb begrepen uit de presentatie voert de DSP code uit die een applicatie inlaadt, en als men een oude, exploitbare image met de juiste signature inlaadt, blijft de exploit volgens mij mogelijk.

[Houtenklaas]

De meeste processoren en DSP's hebben een on-board hoekje waar eens stukje software kan draaien. Bij Intel heet dat bijvoorbeeld de "microcode". En daarbij wordt dus echt een stukje software IN de processor geüpdatet. Oftewel, ook nadat oudere code wordt uitgevoerd, zou dat "safe" moeten zijn.

[mekongsailor]

Slechts 6 terwijl er meer dan 400 zijn?
https://www.techzine.nl/n...roid-telefoons-in-gevaar/

[AverageNL]

Stond niet helemaal duidelijk in de inleiding, maar dat ging om kwetsbaarheden met zes cve-codes. Bij dezen aangepast

[well0549]

Listig hoor, dat er in ieder onderdeel wat er in je telefoon zit kwetsbaarheden kunnen zitten...

Zal wel weer in een buffer overrun gaan of zo...

Kunnen ze daar nou echt niet iets generieks aan doen?...(source code scanner of zo)
Moeten we echt gevalletje voor gevalletje gaan uit pluizen....

[smiba]

Sorry maar wat een domme reactie... Dit is niet ff een stukje code maar iets wat vrij low level is.

Er is geen fail-proof manier om deze bugs of issues er uit te houden, iedereen blijft mens. Het is echt niet alsof Qualcomm denkt van, tja goed genoeg het zal wel... er is gewoon maar zo veel dat je kan automatiseren

[Reactie gewijzigd door smiba op 23 juli 2024 11:07]

[well0549]

Zelfs low level is ooit (op)code geweest en dus te checken...

Assembler kun je ook checken

[smiba]

Assembly is ook niet fail-proof automatisch te checken (Ik weet eigenlijk niet eens of daar uberhaupt hele uitgebreide tooling voor bestaat?)

Handmatig als je de hele code snapt misschien ja... Maar een computer moet weten wat expected behaviour is en wat niet.
(En dit soms terwijl het maar 1 component van het gehele project is, dus alle externe calls en wat deze mogelijk retourneren kan je ook al niet automatisch verifiëren)

[Reactie gewijzigd door smiba op 23 juli 2024 11:07]

[well0549]

Met alles wat er momenteel beschikbaar is met ai, moet het wel heel goed mogelijk zijn om iets dergelijks te maken.

Of de kracht van ai wordt schromelijk overdreven... Maar dat geloof ik niet

[Mellow Jack]

AI is typisch zoiets wat volgens mij gebaseerd is op ideeën van flink wat jaren terug.

Het is niet iets heel revolutionair qua fundament maar we zijn technologisch nu pas zover dat het breed beschikbaar is.

Hoe compute power vroeger nog relatief schaars was, vooral in de parallelle rekenwereld, begint dat nu te veranderen. Niet alleen door brute CPU kracht maar ook door alternatieve methodes zoals GPU's en NPU's. Ook hier is niks nieuws aan maar het heeft even geduurd voordat alle componenten in de keten snel genoeg waren en we sensors hebben ontwikkeld die alles kunnen "voeden".

Natuurlijk kon je vroegah een computer al laten zoeken naar verbanden die een mens niet zosnel zal vinden maar de tijd die het koste om een berg data door te spitten maakte het niet rendabel

Lang verhaal kort, ja AI kan zeker helpen, nee AI is zeker niet de oplossing voor alle problemen

[well0549]

Dat zeg ik toch ook niet, ik denk alleen wel dat je ai kunt trainen op het herkennen van constructies die een buffer overflow veroorzaken....

[SuperDre]

tja, maar dan moet je wel op de hoogte zijn van de methode om zo een kwetsbaarheid te kunnen gebruiken. Ik heb zelfs vaak nog veel moeite met te begrijpen hoe een bufferoverflow kan leiden tot het kunnen uitvoeren van extra code (immers moet de CPU wel weten dat die in dat extra stukje geheugen dus code moet uitvoeren), maar het kan. En wat wij nu kennen als kwetsbaarheden, kan rustig zijn dat op het moment van maken die methode nog helemaal niet bekend is, en je kunt je niet iets fixen waar je niet van afweet dat het fout kan gaan. Vroeger wisten we ook niets over SQL-injection, nu wordt je om de oren geslagen als beginner dat je dat niet zou weten..

[well0549]

Plus dat whitesource/sonarqube Dit ook standaard mee neemt

[SuperDre]

Kijk ook weer 2 dingen waar ik als developer dus nog nooit van gehoord heb. Zo zie je maar weer dat lang niet alles zo vanzelfsprekend is als sommige tweakers hier doen voorkomen, ja ZIJ kennen het toevallig omdat ze er nu dagelijks mee werken, en zo is het dus ook met security problemen.

[Mellow Jack]

Sonarcube beschermd je idd voor stomme fouten niet voor zero day achtig zaken

[well0549]

Wellicht is een buffer overflow over drie jaar net zoiets doms als sql injection nu

[user121]

Ik heb altijd geleerd dat er geen domme vragen zijn, alleen domme ....
Als iemand iets niet weet lijkt mij dit een terechte vraag.

[Blokker_1999]

Als het zo eenvoudig was, dan zou men dat natuurlijk al lang en breed toepassen. En vele automatische controles bestaan al. Maar men kan niet systematisch alles automatisch testen. De testen worden ook nog altijd door mensen ontworpen (en kunnen dus ook fouten bevatten) en zijn uiteindelijk maar zo goed als de persoon die de test bedacht heeft.

[Argantonis]

Er staat hier letterlijk in het bericht dat het om fouten in de processor zelf gaat.

En los daarvan, nee natuurlijk kan je niet even source code scannen om daar dit soort bugs uit te halen. Je kan ook niet even een zooi mentos in een fles cola gooien om naar Mars te vliegen.

[user121]

Er staat ook dat het nu in software is opgelost. Blijkbaar zijn er dus wel mogelijkheden om het in software op te lossen. Waarom zouden er dan geen breder inzetbare mogelijkheden zijn?

[Houtenklaas]

Omdat een DSP is gemaakt om heel vlot zijn data te verwerken en dat wordt in een DSP doorgaans gedaan door zeer gespecialiseerde componenten die getuned zijn op snelheid om realtime data te verwerken. Nu loopt er blijkbaar iets door een software filter heen en daarmee maak je het per definitie trager. Ik dacht hierbij ook nog een een Intel CVE fix van kortgeleden die door de fix eenzelfde probleem zag opdoemen; de processor werd er trager van. Toch is er een goede reden dat er altijd een optie is om in software toch dingen te kunnen fixen, anders is de soldeerbout de enige manier om nog wat te fixen en dat is hier geen optie die handig is. Dan is een software oplossing toch nog beter dan niks

[downtime]

Je kan ook niet even een zooi mentos in een fles cola gooien om naar Mars te vliegen.

Dat slaat echt als een tang op een varken.

Er zijn allerlei tools om code te scannen op veel voorkomende fouten. Ik zie geen reden waarom veel voorkomende fouten als buffer overruns ook niet op die manier gevonden kunnen worden. Hooguit misschien dat de tooling daarvoor nog niet goed genoeg is, maar het lijkt me niet zo’n domme vraag dat jij er zo op moet reageren.

[wjn]

Vandaar de laatste Samsung S10 update: "Verbeteringen voor de camera"?

[Raymond7]

De Europese S10's gebruiken Exynos chips, geen snapdragon.

[TheVivaldi]

Wie zegt dat hij een Europese S10 gebruikt?

[watercoolertje]

Niemand maar als iemand bewust van de norm afwijkt zou hij dat waarschijnlijk wel benoemen.

[wjn]

Volgens Droid Info is het inderdaad een EXYNOS9820.

Volgens de software update info:

• De stabiliteit van Camera is verbeterd
• Wi-Fi-verbinding en stabiliteit zijn verbeterd
• De beveiliging van uw apparaat is verbeterd

[Reactie gewijzigd door wjn op 23 juli 2024 11:07]