Metadata in audiobestand maakt remote code execution in ChromeOS mogelijk
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.
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).
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?
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?
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.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
