VLC bevat mogelijk beveiligingsprobleem

Bij het verwerken van asf-streams in VLC kan een bug optreden, waardoor kwaadwillenden mogelijk eigen code kunnen draaien op het systeem van een gebruiker. Een oplossing is nog niet voorhanden, maar zou zo snel mogelijk moeten verschijnen.

Beveiligingsonderzoeker Debasish Mandal ontdekte dat de asf-parser van de populaire VLC-mediaspeler een potentieel beveiligingsprobleem bevat, zo bevestigen de ontwikkelaars van het project. Asf is een bestandsformaat van Microsoft waarmee audio- en videostreams kunnen worden gestart.

Een 'speciaal geprepareerd' asf-bestand kan in de parser een buffer overflow veroorzaken. Een buffer overflow zorgt ervoor dat meer data naar het geheugen geschreven wordt dan waarvoor ruimte is gereserveerd, waardoor een aanvaller bijvoorbeeld gegevens naar uitvoerbaar geheugen kan schrijven.

Of dat in dit geval ook kan, is nog niet duidelijk. Volgens het VLC-team zou dat in 'sommige gevallen' mogelijk kunnen zijn, maar is dat niet bevestigd. Daarnaast stelt VLC dat gebruikers expliciet een asf-bestand moeten openen om kwetsbaar te zijn, maar tegelijkertijd raadt het bedrijf gebruikers aan om geen 'onvertrouwde sites' te bezoeken, niet zomaar asf-bestanden te openen en de VLC-browser-plugin uit te schakelen. Een alternatief is om de asf-plugin uit te schakelen, door deze te verwijderen uit de plugin-folder van VLC.

Reacties (41)

Dit is wel degelijk een serieus beveiligingsprobleem. Asf/wmv kan nmlk scripts bevatten en op deze manier kun je een adresje (pointer) waar je teveel naar toeschrijft (overflow) vanuit je script (proberen te) benaderen (en uit te voeren).

Ook al gebruiken de meeste mensen VLC voor het afspelen van lokale films/audio, toch is er wel een risico. Internet staat nmlk vol met wmv/asf bestanden met populaire titels die bij uitvoeren niets op het scherm tonen. Vaak klopt de grootte van de bestanden niet (eerste indicatie). Deze bestanden zitten vaak vol met scriptjes die kwetsbaarheden (proberen te) gebruiken. Dit is er dus 1 van.

Scripts en buffer overflows staan compleet los van elkaar. De overeenkomst is dat ze beide voor kwaadaardige doeleinden gebruikt kunnen worden maar daar houden de overeenkomsten wel zo'n beetje mee op.

Voor zover ik na kan gaan is VLC niet in staat om de ASF scripts uit te voeren. Zie VLC behaviour on ASF script commands voor een reactie van VLC developer Jean-Baptiste Kempf over dit onderwerp.

Aangezien het hier om een bufferoverflow gaat bestaat alsnog het risico dat er misbruik van wordt gemaakt ondanks het feit dat VLC geen scripts uit kan voeren.

Dank voor de aanvulling betreffende scripts in ASF/WMV. Dat maakt het een stuk moeilijker voor een offline exploit (het bestand zelf) om succesvol te zijn.

Scripts en buffer overflows staan compleet los van elkaar. De overeenkomst is dat ze beide voor kwaadaardige doeleinden gebruikt kunnen worden maar daar houden de overeenkomsten wel zo'n beetje mee op.

Dat is niet helemaal waar. Ze kunnen los van elkaar staan, maar bij exploits wordt vaak in een (online) scriptje een stukje code, een function pointer, of een ander adres in het geheugen gezet, waarna de exploit hiervan gebruik (d.m.v. bijvoorbeeld een buffer-overflow) kan proberen maken door dit stukje uit te gaan voeren.

Nog gemakkelijker is het om een variabele te overschrijven, maar nogmaals hiervoor is wel vrij precieze controle over de overflow nodig. De kans is anders groot dat je OS ingrijpt en dat de oorspronkelijke app gewoon vastloopt.

Als je alleen het bestand hebt, kun je in offline modus wel een adres overschrijven. Je hebt echter nauwelijks controle over waarmee, omdat alles in je bestand zelf moet zitten. Als je je bestand teveel veranderd is de kans groot dat hij niet meer aan de ASF/WMV specs voldoet en gooit VLC je er sowieso uit. Dit is dus moeilijker maar niet onmogelijk.

De conclusie moet zijn dat overflows en scripts zonder elkaar inderdaad bedreigend kunnen zijn, maar in combinatie wordt het veel gemakkelijker om een succesvolle exploit te maken.

e.e.a. is precies na te lezen op WikiPedia http://en.wikipedia.org/wiki/Buffer_overflow

Dat is niet helemaal waar. Ze kunnen los van elkaar staan, maar bij exploits wordt vaak in een (online) scriptje een stukje code, een function pointer, of een ander adres in het geheugen gezet, waarna de exploit hiervan gebruik (d.m.v. bijvoorbeeld een buffer-overflow) kan proberen maken door dit stukje uit te gaan voeren.

Dat heeft alleen nut bij scripts e.d. die in een sandbox draaien. Per saldo blijft de exploit echter een buffer overflow en is het script alleen maar een manier om die te creëren, net als een corrupte mp3 bestand of een asf stream dat kunnen zijn. Scripts die niet in een sandbox draaien (denk bijvoorbeeld aan de VBA macro's van Word/Excel of VBS scripts) hebben van nature al geen beperkingen en hebben dan ook geen exploit nodig om schade aan te richten, alleen een gebruiker die zo euhm handig is om ze op te starten. Een script uitvoeren binnen een sandbox is niet inherent minder veilig dan het verwerken van bijvoorbeeld een ASF stream. Het zijn kwetsbaarheden in de player/runtime omgeving die misbruik mogelijk maken.

Nog gemakkelijker is het om een variabele te overschrijven, maar nogmaals hiervoor is wel vrij precieze controle over de overflow nodig. De kans is anders groot dat je OS ingrijpt en dat de oorspronkelijke app gewoon vastloopt.

Microsoft heeft in het verleden bij buffer overruns wel de fout gemaakt er bij te vermelden dat men van mening was dat de kans op misbruik laag was, om vervolgens een paar dagen later toe te moeten geven dat er een werkende exploit was ontdekt. Daarom wordt ook direct gewaarschuwd voor een buffer overflow als deze in VLC. In de praktijk zijn er technieken als stack smashing die het vrij goed mogelijk maken te bepalen welke code uitgevoerd wordt. Simpel gezegd overschrijf je een groot geheugen gebied met allemaal verwijzingen naar de kwaadaardige code. Op die manier ben je vrij trefzeker.

Een applicatie als VLC zou inderdaad kunnen (en moeten) detecteren dat de aangeboden data niet aan de verwachtingen voldoet maar dat is nu juist zo'n beetje de definitie van een buffer overflow: gebrek aan controle van de integriteit van de te verwerken data.

De crashes die je ziet zijn doorgaans gevallen waarin een buffer overflow optreedt zonder dat daar kwaadaardige data achter zit. In dat geval gaat het programma de fout in en grijpt het OS in. Daarnaast kan een techniek als DEP er voor zorgen dat het niet meer mogelijk is een buffer overrun te misbruiken.

Geldt deze beveiligingsprobleem nou enkel voor .asf-bestanden of voor het container-formaat 'Advanced Systems Format'?
Het verschil van impact is groot namelijk. .asf-bestanden kom je amper nog tegen, maar .wma en .wmv-bestanden die ook de Advanced Systems Format-container hebben, vaker.

Eigenlijk was Advanced Systems Format al defective-by-design omdat je uitvoerbare script commando's in kan stoppen.

En voor welke platformen geld het?

the ASF demuxer (libasf_plugin.*) can be removed manually from the VLC plugin installation directory. This will prevent ASF movie playback.

Het gaat om het container-formaat zo te zien.

Eigenlijk was Advanced Systems Format al defective-by-design omdat je uitvoerbare script commando's in kan stoppen.

Dan is het web ook "defective by design", want deze pagina alleen al staat vol met script commando's.

Als we nou de <object>, <script>, <embedded>, <img>, <audio>, <video>-tags niet hadden. Dan was het web een stuk veiliger, maar zo saai.

Geef toe, hoevaak zijn er wel niet bugs/exploits in Javascript-engines van alle browsers voorbij gekomen? Het loont bij voorbaat al om standaard AdBlock+ en NoScript te gebruiken om het browsen wat veiliger te maken.

Dit is gemeld bij VLC op 11 Jan 2013 en zou gefixed moeten zijn in Versie 2.0.6 welke nog zou moeten uitkomen.

Workarounds

The user should refrain from opening files from untrusted third parties or accessing untrusted remote sites (or disable the VLC browser plugins), until the patch is applied.

Alternatively, the ASF demuxer (libasf_plugin.*) can be removed manually from the VLC plugin installation directory. This will prevent ASF movie playback.

Link: http://www.videolan.org/security/sa1302.html

Nou, je moet niet alleen voorzichtig zijn met ASF in dit geval, maar met elke extentie.

Als ik een bestand hernoem van extentie ASF naar bijvoorbeeld MP4, dan speelt VLC 'm gewoon af als ASF, omdat dat in de headers van het bestand staat.

als je dat ding alleen gebruikt om dingen lokaal af te spelen lijkt me dat je geen risico loopt.

VLC gebruik ik nog om Word documenten af te spelen, dat ding kan écht alles!

Wat ik erg vreemd vind is dat de patch al een poosje op de plank ligt. Dit soort bugs zijn kritiek en vragen om een vlugge release. De enige reden die ik kan bedenken waarom dit niet is uitgebuit is omdat WMP de default is voor .asf, waardoor VLC erg lastig te targetten is.

[Reactie gewijzigd door RSpliet op 31 januari 2013 12:07]

VLC gebruik ik nog om Word documenten af te spelen, dat ding kan écht alles!

Heb het net even geprobeerd en VLC kan inderdaad docx ducumenten afspelen

Vet, maar dan krijg ik alleen afbeeldingen te zien. Of krijgen jullie ook tekst en tabellen in VLC media player?

Dit komt omdat docx-bestanden eigenlijk een hoop xml-bestanden en losse media in een gecomprimeerde map zijn. (Probeer maar eens de .docx te veranderen in .zip) VLC zoekt in gecomprimeerde mappen alle bestanden af naar media en speelt die dan af. Daarom zie je alleen de afbeeldingen, VLC herkent waarschijnlijk alleen dat het een zip-bestand is, en weet niet dat het (ook) een word-bestand is.

Ik kwam er gister achter dat hij .rar bestanden kon afspelen. Die had ik gemaakt om een filmbestand over te zetten van de ene computer naar de andere (er zat dus alleen de film in). In plaats van uitpakken bij dubbelklik op de rar, ging VLC afspelen. Top!

Dat kunnen zo veel spelers, zelfs om mijn telefoontje kan VLC en BS Player dat zonder problemen...

Opzich wel tof alleen is de compressie van videobestanden al dusdanig goed dat rarren vaak niet de moeite is, ben dan ook benieuwd wat jouw winst was (in MB/GB) om het in te pakken...

[Reactie gewijzigd door watercoolertje op 31 januari 2013 12:15]

Het was een bestand van ~9GB. Probeer dat maar eens met een usb stick van 8gb over te zetten .

En anders heb je het hele FAT gebeuren ook nog (stomme windows...) met bestanden >4GB

[Reactie gewijzigd door mat.hi.as op 31 januari 2013 12:31]

Ach dan formatter je hem toch ntfs ?

en als je niks kwijt wil raken gebruik je convert
(uit m'n hoofd) convert [drive] fs:ntfs

Wat heeft FAT met Windows te maken?

(edit: bedoel dat FAT gebruikt wordt door OS X, Windows, Linux en allerlei willekeurige apparaten als camera's, telefoons en mp3 spelers)

[Reactie gewijzigd door Dreamvoid op 31 januari 2013 17:08]

Zo ongeveer alles. FAT is altijd door Microsoft gebruikt. Linux gebruikt vooral ext, Apple gebruikt hfs.
De eerste window versies draaiden alleen op FAT, later is er NTFS bij gekomen.

De winst zit hem niet zozeer in grootte, maar eerder in de tijd die het scheelt om het bestand niet uit te pakken.

Hij pakte het in om te verplaatsen dus het was wel degelijk in het belang van grote, anders had ie het ook niet in hoeven te pakken (wat dus meer tijd kost dan niet inpakken)...

Wat Freeze1987 probeert te zeggen is dat een videobestand doorgaans niet kleiner wordt omdat de gebruikte compressie van het bestand al goed is. Sterker nog, een geRARd videobestand of jpeg bestand is vaak zelfs groter.

Het enige voordeel dat je met RAR of dergelijke kan halen is het opsplitsen in meerdere bestanden (wat dus ook het doel van mat.hi.as. was).

Het enige voordeel dat je met RAR of dergelijke kan halen is het opsplitsen in meerdere bestanden (wat dus ook het doel van mat.hi.as. was).

Nog een voordeel is dat je een RAR bestand (en zip en 7zip enz) kan testen zodat je kan zien of de inhoud beschadigd is. Ander voordeel is dat je naast het video bestand ook een bestandje met metadata kan opnemen zodat de boel bijelkaar blijft. Als je de RAR aanmaakt met de laagste compressie stand (store) dan is het ook nog supersnel.

RAR archief beschadigd: "Je bestand is beschadigd; Ik pak niets meer uit"
vs
Video beschadigd: "Oops, ik sla deze frames wel even over"

RAR is dan alleen interessant i.c.m. reparatie mogelijkheden (par2's?), maar zelfs dan vind ik het niet de moeite (en de vele extra data) waard; upload gewoon een video en ik neem een beschadigd videobestandje wel voor lief.

[Reactie gewijzigd door Gamebuster op 31 januari 2013 13:40]

Wat doe je dan als je mediaplayer moeite heeft met die missende data/frames ? Mediaplayers kunnen dan danig in de war raken, zozeer dat de film niet meer goed afspeelbaar is.

Rar-bestanden zijn dan ook reuzehandig icm par files. Zo krijg je altijd een prefect afspeelbare film/iso whatever.

Wel zou het prettig zijn als de inpakker de compressie op store zet; die comprimeert nml nul, maar deelt de film slechts op in rar-files. De winst is nml vrijwel nihil en de snelheden van de internetters hoger dan vroeger. Uitpakken van stored rar files gaat vele malen sneller, inpakken trouwens ook.

VLC kan zelfs kapotte DVD's afspelen. Echt onvoorstelbaar dat programma. Toch heb ik een foutieve MKV denk ik, houdt bij mij op na 1:57

Dan ben je in de war met PAR. Daarmee kun je de inhoud van een bestand op fouten controleren (en repareren), maar het werkt op alle soorten bestanden.

Dat uitpakken van .rar bestanden doet VLC al een jaar of 7 a 10 !

De grote hoeveelheid supported formaten is dan ook direct de achilleshiel van VLC, heel veel parser code dus grotere kans dat ergens wel een exploit in zit.

Daarnaast is .asf ook niet het meest populaire formaat. Ik zou zeggen, .asf voorlopig even vermijden.

Dat vindt ik heel naïef. Op deze wijze maak je jezelf gevoelig voor virussen. Waar komt dat afs bestand wat je wilt afspelen vandaan?

Hmm, dat is natuurlijk niet handig. Persoonlijk ben ik niet zo'n fan van VLC; ik geef toch de voorkeur aan Media Player Classic - Home Cinema (x64). Hier kan ik namelijk instellen dat AAC apart moet worden gedownmixed naar stereo, terwijl de overige formaten met rust worden gelaten. Mijn versterker ondersteund deze AAC-codec namelijk niet.

Ik zal de plugin's van VLC ff checken. Komt die plugin automatisch mee bij installatie als je de auto-associate hebt gebruikt?

[Reactie gewijzigd door BUR op 31 januari 2013 16:33]

Ik zal de plugin's van VLC ff checken. Komt die plugin automatisch mee bij installatie als je de auto-associate hebt gebruikt?

Het gaat om de plugin libasf_plugin.*

grsec: denied resource overstep by requesting 69632 for RLIMIT_MEMLOCK against limit 65536 for /usr/bin/vlc[vlc:8126]

Media Player Classic > VLC

De nieuwste versie van VLC Media Player zuigt. Het heeft een zeer lelijke gebruikersinterface, en als ik een video bekijk op volledig scherm, kan ik dat balkje met de buffer niet altijd verbergen. Als ik hem dan helemaal naar rechtsonder sleep, zodat alleen nog een klein puntje te zien is, springt hij gewoon terug naar de vorige positie.

Ik blijf mooi bij VLC Media Player 1.1.9, de beste versie van VLC Media Player tot nu toe.