image

Metadata in audiobestand maakt remote code execution in ChromeOS mogelijk

maandag 22 augustus 2022, 10:13 door Redactie, 9 reacties

Een kwetsbaarheid in ChromeOS maakt het mogelijk voor aanvallers om door middel van malafide metadata in een audiobestand willekeurige code op het systeem uit te voeren, zo hebben onderzoekers van Microsoft ontdekt. Google heeft inmiddels een beveiligingsupdate voor het besturingssysteem uitgebracht.

Het probleem, aangeduid als CVE-2022-2587, doet zich voor bij het afspelen van een audiobestand vanuit de browser of vanaf een aangesloten usb- of bluetooth-apparaat. Door middel van het manipuleren van de metadata in een audiobestand is het mogelijk om een "out of bounds write" te veroorzaken. Dit kan leiden tot een denial of service of in extreme gevallen remote code execution. De impact van het beveiligingslek is op een schaal van 1 tot en met 10 beoordeeld met een 9.8 en heeft het label "kritiek" gekregen.

Google stelt dat de impact van de kwetsbaarheid, die zich in de audioserver van ChromeOS bevindt, "high" is. Het gaat dan om verschillende scenario's waarbij code execution of ontsnapping uit de sandbox van het besturingssysteem mogelijk is. Het techbedrijf werd op 28 april door Microsoft over het beveiligingslek ingelicht en bracht op 15 juni een update uit. "Gegeven de potentiële impact van de kwetsbaarheid, gekoppeld met het feit dat die op afstand was te misbruiken, is het een beveiligingsrisico dat de gegeven prioriteit en snelheid waarmee de fix werd uitgerold rechtvaardigt", aldus Microsoft-onderzoeker Jonathan Bar Or.

Reacties (9)
22-08-2022, 11:12 door Anoniem
Hoe zou het toch komen? dat Microsoft problemen bij een ander wel meldt maar dat de kritieke Microsoft problemen elke patch Tuesday door een ander zijn gevonden.
22-08-2022, 12:05 door Anoniem
Door Anoniem: Hoe zou het toch komen? dat Microsoft problemen bij een ander wel meldt maar dat de kritieke Microsoft problemen elke patch Tuesday door een ander zijn gevonden.
Omdat er een bepaalde blindheid in het ontwikkelproces van software zit waardoor minder evidente fouten/tekortkomingen met grotere tot hele grote consequenties niet worden opgemerkt??
22-08-2022, 12:08 door Anoniem
Google vindt het blijkbaar zelf high en niet kritiek omdat het om mogelijk code execution als gewone user betreft. Je systeem kan dus gelukkig niet versleuteld worden.
22-08-2022, 12:50 door Anoniem
Meten is dus weten, analyseren iets met zekerheid durven beweren

Alleen wat niet geweten mag worden, kan ons later nog bijten of flink opbreken.

Security through obscurity moet dus stoppen.

Veiligheid voor iedere eindgebruiker en niet alleen voor dataslurpers en controleurs, surveillance diensten e.d.

Anders krijg je ook nooit cybercrime de wereld uit. Dat vraagt totale openheid en dat is wat anders dan totale transparantie ten behoeve van de machthebbers (overheid, big corp, groot investeerders).
22-08-2022, 16:24 door Anoniem
CD-spelers bestaan gelukkig nog steeds. Geen stom gekloot met metadata.
23-08-2022, 07:46 door Anoniem
Door Anoniem: Hoe zou het toch komen? dat Microsoft problemen bij een ander wel meldt maar dat de kritieke Microsoft problemen elke patch Tuesday door een ander zijn gevonden.
Het lijkt me stug dat dat beeld klopt. Ik denk dat iedereen die enigzins serieus software heeft ontwikkeld soms zelf bugs (waaronder beveiligingslekken) heeft herkend in code en daar actie op heeft ondernomen. Ik heb zo een keer een kritisch beveiligingslek in een webapplicatie verholpen dat aantoonbaar nog niet was misbruikt, en ik heb ettelijke ernstige fouten in administratieve processen verholpen voordat de zeldzame omstandigheid die de fout zou triggeren ooit was opgetreden. Ik kan me niet voorstellen dat dat bij Microsoft of bij welke club ontwikkelaars dan ook niet gebeurt, daarvoor moet je actief negeren wat je wel degelijk ziet. En dat is nog maar een van de manieren waarop een organisatie fouten in de eigen software kan opsporen. Ze hebben duidelijk ook een club die actief naar beveiligingslekken zoekt. En ze zijn zelf een grote gebruiker van hun eigen software, dus intern zal er ook het nodige gemeld worden.

Wat ik me wel goed kan voorstellen is dat een bedrijf als Microsoft om marketingredenen eerder een blogpost publiceert over hoe ze een ernstige fout in software van een ander hebben gevonden dan over het vinden en verhelpen van een ernstige fout in hun eigen software. Kan je beeld daarop gebaseerd zijn?
23-08-2022, 09:57 door Anoniem
Door Anoniem:
Door Anoniem: Hoe zou het toch komen? dat Microsoft problemen bij een ander wel meldt maar dat de kritieke Microsoft problemen elke patch Tuesday door een ander zijn gevonden.
Het lijkt me stug dat dat beeld klopt. Ik denk dat iedereen die enigzins serieus software heeft ontwikkeld soms zelf bugs (waaronder beveiligingslekken) heeft herkend in code en daar actie op heeft ondernomen. Ik heb zo een keer een kritisch beveiligingslek in een webapplicatie verholpen dat aantoonbaar nog niet was misbruikt, en ik heb ettelijke ernstige fouten in administratieve processen verholpen voordat de zeldzame omstandigheid die de fout zou triggeren ooit was opgetreden. Ik kan me niet voorstellen dat dat bij Microsoft of bij welke club ontwikkelaars dan ook niet gebeurt, daarvoor moet je actief negeren wat je wel degelijk ziet. En dat is nog maar een van de manieren waarop een organisatie fouten in de eigen software kan opsporen. Ze hebben duidelijk ook een club die actief naar beveiligingslekken zoekt. En ze zijn zelf een grote gebruiker van hun eigen software, dus intern zal er ook het nodige gemeld worden.

Wat ik me wel goed kan voorstellen is dat een bedrijf als Microsoft om marketingredenen eerder een blogpost publiceert over hoe ze een ernstige fout in software van een ander hebben gevonden dan over het vinden en verhelpen van een ernstige fout in hun eigen software. Kan je beeld daarop gebaseerd zijn?
Check de Patch Tuesday Acknowledgements. Bijna allemaal extern.
23-08-2022, 16:40 door Anoniem
Dat is alleen bij een programma waar je mee opnemen of audio veranderen kan :

Een programma dat alleen muziek afspeeld heeft geen write-rechten nodig,
daarom zal zo een programma alleen met het read-attribute een bestand openen,
als een programma tog readwrite-rechten gebruikt is dit raar, en verdacht, overbodig.
Ook komt er een administrator waarschuwing wat anders niet in beeld zou komen voor dit programma.

Ik ben benieuwd naar een prakties voorbeeld.
24-08-2022, 00:59 door Anoniem
Door Anoniem: Dat is alleen bij een programma waar je mee opnemen of audio veranderen kan :

Een programma dat alleen muziek afspeeld heeft geen write-rechten nodig,
daarom zal zo een programma alleen met het read-attribute een bestand openen,
als een programma tog readwrite-rechten gebruikt is dit raar, en verdacht, overbodig.
Ook komt er een administrator waarschuwing wat anders niet in beeld zou komen voor dit programma.

Ik ben benieuwd naar een prakties voorbeeld.

Men schrijft 'praktisch' .

Je denkt alleen maar in termen van schrijf-rechten op files .

Een muziek programma schrijft - naar de buffer van de audiodriver , bijvoorbeeld.
Die meta-data (bijvoorbeeld artiest, titel, album, lyrics) - die worden ook door het afspeelprogramma geschreven naar "iets" - misschien de eigen display module, misschien een of andere "bus" waar de window manager dat soort dingen van kan oppakken .
Verder is de kans heel groot dat een muziekspeler een handjevol 'tmp' files schrijft, misschien process-id , misschien waar in de playlist hij bezig was , noem maar op.

BTW 'out of bound write' slaat alleen op het overschrijven van buffers in het geheugen .

Er is echt nog een hoop voor je leren op software gebied om de berichten en typische issues goed te interpreteren.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.