Onderzoekers vinden lek in VLC dat remote code execution mogelijk maakt - update

Onderzoekers hebben een lek ontdekt in mediaspeler VLC waarmee van een afstand code kan worden uitgevoerd. Het gaat volgens de ontdekkers om een buffer-overflowlek. VLC werkt inmiddels aan een patch, maar die is nog niet beschikbaar.

De onderzoekers van de Duitse securitywaakhond CERT-Bund ontdekten het lek en hebben dat de code CVE-2019-13615 gegeven. Het lek zit in de laatste stabiele versie van de VLC Media Player, versie 3.0.7.1, en lager. Met het lek is het mogelijk een remote code execution uit te voeren op het systeem van een slachtoffer. Ook zou het mogelijk zijn informatie te stelen van een systeem of bestanden aan te passen, bijvoorbeeld door ze te versleutelen. Volgens de onderzoekers gaat het om een heap-based buffer overflow en komt het in alle versies van VLC voor.

VideoLAN, het bedrijf achter de mediaspeler, is een maand geleden al begonnen aan een patch. Die zou voor zo'n zestig procent klaar zijn, blijkt uit de bugtracker van het bedrijf. Het is niet bekend of het lek actief is misbruikt.

Update 25-07: VideoLAN heeft reageerd op het bericht en zegt dat het lek zat in verouderde libraries van derde partijen. We hebben een vervolgbericht geschreven.

Reacties (54)

[FerronN]

Ik mis hoe dit lek misbruikt kan worden. Wat is er voor nodig om dit lek te misbruiken?

[Reactie gewijzigd door FerronN op 23 juli 2024 10:30]

[Glodenox]

In het ticket staat er een mp4 die het probleem kan triggeren. Het gaat dus over het afspelen van een bestand dat speciaal hiervoor aangepast is geweest. Zolang je dus niets uit een vreemde bron draait zou het risico zeer beperkt moeten zijn.

[kodak]

Dan lijkt het dus geen remote code execution. Tenzij de gebruiker vlc als service in gebruik heeft, wat niet standaard is.

[TheVivaldi]

Ik zie ook niks over remote code execution in de CVE: https://nvd.nist.gov/vuln...lnCurrentDescriptionTitle

[theboss100]

Het is een lek in de categorie "Buffer errors (CWE-119)". Dit betekend dat er mogelijk code uitgevoerd kan worden.

(bron)

[TheVivaldi]

Ah, dank je wel voor de verduidelijking!

[kodak]

nvd.nist.gov geeft een CVSS score. Die heeft in zich dat er geen actie van de gebruiker nodig zou zijn. Onder welke omstandigheid is onduidelijk.

[SuperDre]

LOL, alleen heeeeeel veel mensen gebruiken VLC juist om videobestanden van een vreemde bron te kijken (ofwel torrentsites, newsgroups, etc)..

[K-aroq]

Nou, niet meer doen dan :-)

[Pep7777]

Het hele verhaal is nogal technisch. En daar zijn prima online dingen over te vinden. Maar het komt erop neer dat als een programma zeg 10 bytes geheugen reserveert voor data, en je levert als input meer aan dan die 10 bytes data. Dat de extra data in geheugen (of op de stack) komt te staan waar het programma verwacht code aan te treffen. En het dus ook gaat uitvoeren alsof het (machine) code is.
Je kan dan als "aanvaller" de data zo vormgeven dat het programma jouw input gaat uitvoeren en waarmee je dus met de rechten van het draaiende programma dingen voor elkaar kan krijgen die het programma zelf nooit zou doen.

Fix : typo

[Reactie gewijzigd door Pep7777 op 23 juli 2024 10:30]

[ajolla]

Als een programma 10 bytes aan geheugen reserveert, is het dan niet aan het OS ervoor te zorgen dat er ook niet meer dan dat kan worden weggeschreven?
Of de compiler?

[Pep7777]

Nee dat is niet aan het OS, al bouwen ze daar ook al wel dingen in om het moeilijker te maken met name rond heap allocatie (als het te technisch wordt roep maar)

In principe is het aan de (C++) programmeur.
- Maakt de afweging tussen lokale variabelen (stack) of gealloceerd geheugen (heap)
- Die maakt de afweging tussen performance (geen checks), of security (wel extra checks), net wat andere hulp functies gebruiken een string-copy of safe-string-copy.
- visual studio/c++ heeft een optie die waarschuwingen kan geven in debug builds.

Zelf ben ik groot voorstander van C++11 (14/17) gebruiken, daar laat je nog meer van geheugen beheer over aan de standaard functies en is het natuurlijker om precies alleen dat geheugen aan te wijzen en aan te spreken wat je ook nodig hebt. (std::string, std::array, std::vector, std::unique_ptr en std::shared_ptr etc).

Dus geen (m)alloc/free, new/delete meer gebruiken als je C++ schrijft! (Scheelt vaak ook nog eens een hoop andere bugs maar dat terzijde)

[R4gnax]

Nee dat is niet aan het OS

Je hebt nog zoiets als wat Microsoft Data Execution Prevention (DEP) heeft genoemd, en wat middels de No-Execute (NX) bit in hardware ook directe ondersteuning heeft.

Microsoft heeft dat al jaren ingebouwd zitten in Windows. Sinds XP al, geloof ik.

Probleem is alleen dat er ook legitieme toepassingen zijn om data executeerbaar te hebben. Daarnaast is een boel legacy Windows software ook gewoon niet netjes geschreven en haalt het allerlei smerige zooi uit die in principe niet gevaarlijk is, maar wel haaks staat op hoe je met geheugen-allocatie moet werken die 'DEP-proof' is.

En dus heeft MS hun DEP feature standaard voor gewone user-mode programma's uitgezet en alleen actief voor systeem-processen. Je kunt, als je het wilt en aandurft, het nog steeds gewoon voor alle programma's aanzetten en programma's die er problemen mee geven handmatig white-listen. Maaruh; data-integriteit, crashes, enzo.

[Magic Power]

Ik heb DEP (Data Execution Prevention) al een paar jaar aanstaan op mijn main PC. Ben tot nu toe 1 programma tegengekomen dat niet met DEP wou werken, en waar ik dat programma moest blacklisten zodat het toch kon werken. Na een bepaalde update hoefde dat gelukkig niet meer, en sindsdien staat DEP voledig aan.

Ik merk praktisch niks van dat het aanstaat. Alles werkt en kan gewoon gebruikt worden. Merk ook geen evt. data-loss ofzo. Dus ik zou zeggen: Als je die extra beveiliging interessant vind, zet DEP aan (Windows 7->Control Panel->System->Advanced->Performance->DEP) en probeer het uit. Merk je dat programma's crashen, kan het daaraan liggen. Blacklist ze in de DEP-instelling en probeer het opnieuw.

[Pep7777]

Yup DEP dus... net zoals ik hierboven net zei, ik heb het op windows nooit zo zien werken
Eigenlijk gewoon voor nieuwe programmas gelijk aanzetten, net als access violations niet opeten met de /SEH compiler vlag en catch(...) lekker geheugen links en rechts vernaggelen en doorgaan of er niks aan de hand is. *eeks*

[R4gnax]

net als access violations niet opeten met de /SEH compiler vlag en catch(...) lekker geheugen links en rechts vernaggelen en doorgaan of er niks aan de hand is. *eeks*

Oof. Niet gaan vloeken heh?

[Reactie gewijzigd door R4gnax op 23 juli 2024 10:30]

[ajolla]

Deze reactie is wat mij betreft iets te veel vanuit 1 versie van 1 specifieke programmeertaal.
Zo los je een algemeen probleem van buffer overflow toch niet op?
Het is onderhand een maatschappelijk probleem aan 't worden en kan mijns inziens niet meer aan de individuele programmeur met z'n specifieke versie van één specifieke taal worden overgelaten.
Als je een beperkt geheugengebied voor data declareert moet òf de compiler er automatisch code omheen genereren die de integriteit van de rest van het geheugen garandeert, òf het OS moet die grenzen bewaken.

[Pep7777]

Voorbeeld komt uit omgeving die ik goed ken, maar principe gaat op voor alle talen die naar native machine code compileren, en is niet speciaal OS afhankelijk. Talen zoals Java, C# hebben die problemen van nature niet al kunnen er weer bugs in die runtime omgevingen (JVM) zitten, en laten ze vaak via achterdeuren toch weer OS API calls toe die vaak ook nog oud en unsafe zijn...

Wat betreft maatschappelijke probleem heb je wel gelijk:
Ik denk dat veel programmeurs allang blij zijn als iets "lijkt" te werken en maken zich inderdaad niet zo druk om security. Dus voor die groep ben ik het met je eens. Andere programmeurs moeten en performance halen EN secure code schrijven denk maar aan IOT apparaatjes met slome processors.

Data en code segmenten bestaan wel met dat idee ook, als je data verandert kan het nooit executeerbare code worden heel vroeger wel in Unix tegenaan gelopen, resulteerde gelijk in crashes. In Windows eigenlijk nooit zien werken.

[unglaublich]

Een typische buffer overflow.

[Reactie gewijzigd door unglaublich op 23 juli 2024 10:30]

[Orion64]

Liever nog even 'security by obscurity...'
Maar eigenlijk wil ik het ook wel weten, vlc staat tenslotte op al mijn Windows pc's. Dus hoe te beschermen (behalve deinstallatie)?

[ACM]

Simpelweg niet gebruiken zal ook prima werken als bescherming en is wat praktischer dan helemaal verwijderen, tenzij je natuurlijk bang bent dat vlc automatisch wordt gebruikt.

En het is natuurlijk ook niet zo dat ineens iedere video die bug misbruikt.

[R4gnax]

Simpelweg niet gebruiken zal ook prima werken als bescherming

Hang er vanaf. Had VLC hoewel het de VideoLanClient is, niet ook wat server componenten aan boord?
Zou knap knudde zijn als VLC remote te launchen viel om dit te exploiteren. (ouch)

[K-aroq]

Niks mis met security by obscurity lijkt me. Iedere extra laag is meegenomen.

[F-I-X]

Zolang er nog geen patch is zullen ze die informatie natuurlijk niet gaan delen.

[TheVivaldi]

@TijsZonderH Hoe bedoel je precies dat Videolan voor 60% klaar zou zijn met de patch? Er staat: "Work: Not started" (https://trac.videolan.org/vlc/ticket/22474)

Edit: zie ook hieronder.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 10:30]

[keranoz]

Onderaan de pagina staat:

Work status: 60% -> Not started

[Ge Someone]

Als je nog beter leest blijkt het alleen voor te komen in de "debug" versies van VLC. Niet in de normale en dus ook niet in de gedistribueerde "stable". Daar is dus geen patch voor, misschien wel voor toekomstige :debug-versies.

[TheVivaldi]

Oké, maar dan nog is het dus momenteel niet meer zo dat de patch in de maak is, zoals het artikel suggereert.

[tweaker2010]

Work status 60% betekent toch wel dat ze ergens mee bezig zijn. Waarschijnlijk is ie bij Work status 100% gereed.

[TheVivaldi]

Nee, lees nou even goed: er staat "Work: Not started". Hoe is dat "60%"?

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 10:30]

[K-aroq]

Wellicht: "Analysis and desing done, implementation not started""

[TheVivaldi]

Dat zou kunnen, maar de tweaker hierboven zegt dat er "60%" staat op die PAGINA van het bug report en dat staat er dus niet, dat is waar ik op doelde.

[djhartman]

Het ticket heeft nu wat meer info...

[LiquidCrystal]

Ik ben vooral benieuwd of dit misbruik alleen onder Windows van toepassing is, of ook onder andere OS'en waar VLC voor bestaat.

Ik gebruik VLC namelijk juist op meerdere Linux systemen.

[jellemdekker]

Het gelinkte ticket over de kwetsbaarheid geeft als platform GNU/Linux aan.

[TheVivaldi]

Maar de CVE geeft geen platform aan: https://nvd.nist.gov/vuln...lnCurrentDescriptionTitle

[kozue]

Het is niet platform specifiek. Wellicht werkt het dus ook op bv de iOS versie, mits die dezelfde bug bevat. Alleen zal een exploit (in het videobestand) platform specifiek moeten zijn, omdat de code die wordt aangeroepen native code is en dus maar op 1 platform zal werken (linux zal geen windows instructies kunnen draaien). Hier kun je wel weer omheen werken door voor alle populaire platformen een versie te ontwikkelen en via platformdetectie (bv op een webpagina via de user agent string) de juiste versie voor te schotelen. In principe werkt het dus overal op.

[Atlantis1995]

Waarom is dit lek gepubliceerd? Of is het drie maand geleden gevonden en heeft VLC er tot dit moment niets mee gedaan?

[TheVivaldi]

Ja, niks mee gedaan. Kijk maar: https://trac.videolan.org/vlc/ticket/22474 "Work: Not started".

[batjes]

Opened 4 weeks ago.

Dit slaat eigenlijk nergens op. Het indexeren van zo'n exploit kan makkelijk een maand duren en dat is echt niet vreemd. Zelfs de 3 maanden is een richtlijn en geen harde (tenzij je Google heet en de geëxploite partij Microsoft is) grens.

Dat dit nu zo geopenbaard wordt is niet netjes tenzij het team van VLC echt keihard de bal heeft laten vallen

[Marctraider]

Om dit soort redenen gebruik je dus NIET de default windows firewall rules. (aka. outbound allowed by default)

Voor alles dat eigenlijk geen internet verbinding nodig heeft. Updaten kan toch handmatig... Je weet nooit wat een programma in de achtergrond doet..

[Reactie gewijzigd door Marctraider op 23 juli 2024 10:30]

[djhartman]

VLC heeft zich een beetje impopulair gemaakt bij een aantal security 'researchers' door een aantal keer hard terug te vechten tegen reports waarbij het project als een soort "pinautomaat voor bounties" en voor reputation building gebruikt wordt.

Door bv. het aanmelden van kleine of bugs in zeer ongebruikelijker configuraties, doen alsof iedereen daarbij affected is en high impact CVEs aanmaken, terwijl in werkelijkheid maar een tiental gebruikers zo'n config zullen draaien en eisen (tot aan lastig vallen van ontwikkelaars aan toe) van een bug bounty. En dan maar lekker hoog van de toren blazen over hoeveel security issues je wel niet aangemeld hebt, terwijl vrijwilligers aan de bak moeten om op stel en sprong het probleem op te lossen in hun spaarzame tijd. Een aantal van de VLC developers hadden het daar een beetje mee gehad en hebben een aantal keer wat minder vriendelijk gereageerd.

Daar hebben ze geen vriendjes mee gemaakt. Maar ze hebben wel gelijk, het is nogal een verdorven wereldje soms die security business.

Zie ook:
https://twitter.com/adulau/status/1146051772416479235

[rjberg]

Android heeft ook een vlc versie. Is die ook kwersbaar.

[Oaknut]

Is MPlayer hiervoor een goed tijdelijk alternatief? Een kennis van mij downloadt een lading films en series iedere paar maanden als hij in Nederland is omdat hij in Afrika geen televisie en geen stabiele internetverbinding heeft. MPlayer heeft hij nog wel op de computer staan.

[toro]

Sommige raken hier van in paniek en verwijderen dan VLC om dan bijvoorbeeld Windows Media Player te gebruiken.

Liever VLC dan Windows Media player.

Bij VLC worden bugs als deze snel aan het licht gebracht en gefixed.

En bij de Windows eigen player kan dat nogal lang verborgen blijven en misbruikt worden voor dat er iets gemaakt word.

Dat vind ik toch wel een plus van open source

[wjzijderveld]

Hoe bekend ben jij met de issue tracker van VLC? Jij hebt het over afgebroken, terwijl je niet weet wat er speelt. Het enige dat je weet, is dat de status van 60% aangepast is naar 'not started', met als comment dat de crash niet voorkomt bij een 'normal release'. Misschien is er nieuwe (niet publieke) informatie en moeten ze een andere invalshoek zoeken. Dat betekend niet dat er niet aan gewerkt wordt of dat ze het opgegeven hebben.

Naar mijn mening ben je nu gewoon aan het zeiken in de comments zonder dat je weet wat er speelt. Je had ook gewoon kunnen vragen "wat betekend die 'work status' nu, het is nogal verwarrend".

[TheVivaldi]

Het ticket is bijgewerkt en men heeft uitgevogeld dat het geen lek is. Dus vertel me nog eens met welke patch ze achter de schermen bezig waren terwijl er geen probleem is...?

[djhartman]

Misschien even deze thread lezen: https://twitter.com/videolan/status/1153963312981389312

[TheVivaldi]

Dat bevestigt dus dat ze helemaal niet bezig waren met een patch omdat ze het probleem zelf niet ervaarden, zoals ik al eerder zei, ondanks wat wjzijderveld me probeerde wijs te maken.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 10:30]

[wjzijderveld]

Waar lees je in mijn comment dat ze met een patch bezig zijn... Wat ik juist probeerde over te brengen is dat we toen niet wisten wat er speelde. Een status zegt gewoon niks. Zowel in dat ticket als in mijn comment probeer je dingen tussen de regels door te lezen die er niet zijn.

[Reactie gewijzigd door wjzijderveld op 23 juli 2024 10:30]

[TheVivaldi]

-foutje, bedankt-

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 10:30]