'Lek in VLC' blijkt in verouderde externe library te zitten

De kwetsbaarheid in VLC waar beveiligingsonderzoekers onlangs over berichtten, blijkt in een library van een derde partij te zitten. De onderzoekers hebben het 'lek' niet eerst aan de makers van VLC gemeld, maar daar zelf een publieke bugtracker over geopend.

Het probleem zat niet in VLC zelf, maar in een library van een derde partij, libebml genaamd, die al geruime tijd gerepareerd is. Dat zegt VideoLAN, de maker van de populaire mediaspeler, in een uitleg op Twitter. Veel media, waaronder Tweakers, schreven over de mogelijkheid van remote code execution via een heap-based buffer overflow. VideoLAN ontkent nu dat het lek in de mediaspeler zelf zit.

"Dit probleem is al in versie 3.0.3 opgelost", schrijft het bedrijf. VideoLAN zegt dat een beveiligingsonderzoeker een oude versie van Ubuntu gebruikte om het lek te testen en dat die versie 18.04 nog oude libraries gebruikte. Vervolgens hebben de onderzoekers zelf een bugticket geopend, waarop Tweakers het nieuws baseerde. Zulke tickets kunnen bij VLC echter door iedereen in de bugtracker worden geopend en de onderzoeker ging daarvoor niet eerst bij VLC langs. Vervolgens werd er ook onafhankelijk een CVE geopend.

VideoLAN hekelt de manier waarop de onderzoekers uit zichzelf de status van de bug online zetten, maar ook hoe de media daarover schreven. Gizmodo schreef bijvoorbeeld dat gebruikers 'VLC het beste direct konden verwijderen'.

Reacties (116)

[TeGek]

Het probleem met dit soort correcties is wat VLC in het tweets vertelde ook tweezijdig; Het eerste topic had een sensationele kop, iedereen en zijn oma had een mening klaar over iets wat een enkele security researcher had gevonden, op een (redelijk zwaar!) verouderd systeem. Het issue begint echter pas echt bij dit artikel; snel een kleine update, een topic geplaatst op een minder populair leesmoment, met veel minder informatie, en vooral het woord rectificatie proberen te vermijden, want tweakers, gizmondo, en ook nu.nl willen liever niet dat het lijkt alsof hun op dit moment fout waren.

Het tweede issue is vele male gevaarlijker; the boy who cried wolf. Bij elke grote fabrikant wordt altijd gecontroleerd of er vooraf responsible disclosure is geweest. er wordt gebeld met persafdelingen of bedrijven zelf. een goed voorbeeld hiervan is het Zoom lek recent: elke website(ook t.net!) heeft of zelf controle uitgevoerd, of controle door een derde partij laten uitvoeren voordat er een stukje gepubliceerd werd. Dit is niet bij VLC gedaan. Het risico is dat er nu over een maand, een kwartaal, of jaar wel een lek uitkomt wat door gebruikers die kennis hebben genomen van dit tweede artikel geen risico wordt gezien omdat de gebruikers weten dat de vorige keer dat ze het artikel zagen er al niets van klopte, dus dan vast ook niet deze keer.

Het zou elke website sieren een wat formeler excuus te maken, en ook de andere artikelen uit te breiden met verdere security adviezen.

[Reactie gewijzigd door TeGek op 28 juli 2024 15:07]

[Anoniem: 834471]

Het tweede issue is vele male gevaarlijker; the boy who cried wolf.

Het is absurd hoe veel mensen dit principe niet snappen.
Kom het ook in supportland tegen.

A werkt niet bij Harry, paniek!
A is gefixt, impact viel mee.
B werkt niet bij Harry, paniek!
B is gefixt, impact viel mee.
C werkt niet bij Harry, paniek!
Ticket gaat maar even op de baan wat Jantje had D issue en Harry zaait paniek.
D wordt gefixt bij jantje.
C bleek achteraf Harry's werkzaamheden tamelijk serieus te frustreren.
Iedereen is gefrustreerd.

[Reactie gewijzigd door Anoniem: 834471 op 28 juli 2024 15:07]

[MrMonkE]

Jou post frustreert niet veel minder moet ik bekennen.
Flashbacks!

[Sp3ci3s8472]

Maar dat is echte journalistiek, kom nou .

Het is hier wel beter gebracht dan bij Gizmodo. Dat stelt volgens mij weinig voor en is van die sensatie clickbait media (met daarbij de gebruikelijk sensationele koppen).

[Reactie gewijzigd door Sp3ci3s8472 op 28 juli 2024 15:07]

[TijsZonderH]

Journalistiek is ook openheid geven over dingen die misgaan en vertellen hoe dat kon gebeuren. Dat probeer ik hier ook.

[Gwaihir]

En dat waardeer ik zeer. Maar ik mis nog even de rol van CERT-Bund in dit artikel. Voor de originele melding hier op Tweakers lijkt het de bron te zijn - en ik kan me voorstellen dat het een bron is die je vertrouwt. Ik zie 'm dus als drieledig: 1) VLC is gewoon veilig (en dat blijkt nog niet direct duidelijk uit de titel, helaas), 2) De orginele onderzoekers publiceerden op een ongewenste / onverantwoorde manier, 3) Het (doorgaans betrouwbare?) CERT-Bund blijkt zijn huiswerk niet gedaan te hebben en dit onterecht geëscaleerd te hebben tot een CVE - waarop het zo de wereld rondging.

[HollowGamer]

Maar verder ga je niet echt in @TeGek en @Jorisadri, dat vind ik wel jammer. Vooral de titel van dit nieuwsbericht vind ik inderdaad storend, want het lijkt nu nog altijd erop dat VLC oude libs zou meegeven.

Overigens zijn die libs niet altijd door de maker zelf beschikbaar gesteld, maar worden deze op Linux veelal via de repo gedownload. Beetje jammer dat dit ook allemaal zo karig erin staat.

[Sp3ci3s8472]

Precies, petje af daarvoor.

[Jorisadri]

Als ik de titel lees denk ik nog altijd dat VLC verouderde libraries gebruikt waar de lek in zit. De titel zou kunnen zijn: 'Lek in VLC' blijkt in verouderde externe libraries te zitten die VLC al x maanden niet meer gebruikt

[GekkePrutser]

Dit is ook een beetje het punt van VLC.. Door alles mee te leveren maken ze installatie handig en heb je geen geklooi meer met codecpacks zoals vroeger. Want player en codecs waren apart waardoor je vaak codecs van vage bronnen binnen moest hengelen om iets af te spelen. In VLC wordt alles meegecompileerd. Als iets speelt in VLC dan speelt het op elk systeem in VLC ongeacht OS of wat er verder in geinstalleerd is.

Aan de andere kant laat je je hierbij wel open voor een hoop kwetsbaarheden in externe code die je meeneemt. Wat gezien kan worden als een fout in je produkt terwijl je hier niets aan kan doen. (In de media: "Kwetsbaarheid in VLC!" in plaats van "Kwetsbaarheid in codec xxxxx")

Dus het sterke punt van VLC is ook gelijk een theoretische zwakte. Maar ik vind dat Videolan hier goed mee omgaat, elke keer als er weer wat gevonden wordt in een oude library (zoals in dit geval vorig jaar met een kwetsbaarheid in ondertitels) wordt dat serieus genomen en meteen gefixt. In dit geval was dat dus proactief al gedaan voordat de bug zelfs bekend was. Bij een bedrijf dat hier minder goed mee omgaat zou het wel een probleem zijn.

Wel erg slecht van die Duitse "Security Waakhond" dat ze geen responsible disclosure hebben gedaan. Die zouden toch echt beter moeten weten. Maarja nu hebben ze hun 5 minuten beroemdheid weer gehad, terwijl het anders nooit gepubliceerd was omdat het allang gefixt was.

[Reactie gewijzigd door GekkePrutser op 28 juli 2024 15:07]

[Troepje]

Hier is juist het probleem dat het een oude ubuntu met oude lib is, VLC gebruikt die lib. De lib was er dus niet statisch gelinked maar dynamisch. Het probleem was dus zijn distributie, niet VLC.

[mikesmit]

Want player en codecs waren apart waardoor je vaak codecs van vage bronnen binnen moest hengelen om iets af te spelen

Je had toch de populaire codec packs als k-media, shark en cccp? Zo vaag waren die bronnen in mijn ogen niet

[R4gnax]

Je had toch de populaire codec packs als k-media, shark en cccp? Zo vaag waren die bronnen in mijn ogen niet

En al die codecs werden op Windows als globaal beschikbare DirectShow filters op je systeem gegooid, terwijl het vaak allemaal experimentele pruts was die enkel geschikt was om binnen een heel simpele media-player gebruikt te worden.

Gevolg: legio andere software, waaronder vaak video-games met FMV sequences, kregen kuren.


Er is wat te zeggen voor een pakket zoals VLC, wat niet alleen alles meelevert, maar het ook binnen zijn eigen gebruiksgrenzen houdt.

[Reactie gewijzigd door R4gnax op 28 juli 2024 15:07]

[mikesmit]

Ik suggereer niet dat het vroeger beter was. Het is wel degelijk gebruiksvriendelijker nu dan dat het ooit geweest is. Ook verschilde de kwaliteit enorm van codec pack tot codec pack. Zeker de 64bits builds waren verschikkelijk. Maar de stable builds van CCCP zijn toch wel sinds de xp tijd een integraal onderdeel van mijn os geweest (met uitzondering van de afgelopen 4 jaar sindsdien vodecpacks eigenlijk overbodig zijn geworden. Deels door VLC maar ook deels door de integratie van populaire codecs rechtstreeks in Windows zelf)

[GekkePrutser]

Ja precies.. Die kwamen allemaal voort uit de illegale download scene en haalde je van websites die ik wel degelijk als 'vaag' kan omschrijven. Vol met gedownloade codecs samengesteld uit bronnen van weet ik veel waar. In elk geval is alles wat in VLC zit helemaal open-source. Bij VLC zit er een team achter die eventuele kwetsbaarheden zelf in de source kan fixen en dat geeft een stuk meer vertrouwen.

Dat ze populair waren betekent niet dat ze uit een betrouwbare bron afkomstig waren.

[Reactie gewijzigd door GekkePrutser op 28 juli 2024 15:07]

[JeroenED]

Is voor mij een bewijs dat een legaal alternatief even aantrekkelijk kan zijn als een illegaal alternatief. Andere bewijzen zijn spotify en mogelijks toekomstig netflix, amazon prime video, etc combo abo.
Voor een deftige prijs (wat gerust meer mag zijn dan 20 of 30 € per maand). En zei die zeggen dat dit niet haalbaar is: als de provider slim is, is dit perfect haalbaar. Want hij kan het argument gebruiken dat een kijker niet enkel netflix kijkt en dus zelf mss 1€ / maand / reguliere gebruiker kan bedingen en via goede contracten kan dit heel goed uitpakken.

[Malarky]

Hoe kom je erbij? Codecguide publiceert al vele jaren de updates van Klite codec pack en wat er in dat pack zit, waarom, wat de bron is, etc. is enorm transparant.

En dat is het al jaren.

[P_Tingen]

Sterker nog; zelfs na herlezing weet ik nou nog niet of die library extern was in de zin van dat die al op het systeem aanwezig was, of extern in de zin van dat die door iemand anders gemaakt is en door Videolan wordt meegeleverd

[Whatts]

Zelfs de titel van dit artikel kon correcter zijn wat mij betreft, want nu lijkt het alsof die library nog altijd gebruikt wordt (met de huidige versie van VLC). In het artikel wordt dit wel verduidelijkt, maar de titel kan beter...

Admin-edit:

Bedankt voor je feedback. Commentaar voor de redactie hoort echter thuis in Geachte Redactie. Hier staat het de inhoudelijke discussie niet in de weg en kan de redactie het eenvoudig terugvinden.

[Reactie gewijzigd door Zeehond op 25 juli 2024 23:28]

[Edgarz]

Een kop is te kort om als complete, genuanceerde samenvatting te dienen. Dat de nuance in het artikel staat is terecht. De suggestie wordt wellicht gewekt in de kop, maar suggestief zijn koppen vrijwel altijd.

[johnkeates]

Ze hadden er 'Lek in VLC blijkt jaar geleden al opgelost te zijn' van kunnen maken.

[SED]

Wat ik dan niet snap dat in de originele melding dit staat"

Het lek zit in de laatste stabiele versie van de VLC Media Player, versie 3.0.7.1, en lager.

En dat in dit artikel de reactie is:

"Dit probleem is al in versie 3.0.3 opgelost", schrijft het bedrijf. VideoLAN

Wat is nu waar?

[johnkeates]

Wat waar is, is dat de library waar het lek in zat een jaar geleden al gepatcht is.

[HollowGamer]

Hebben we het dan ook echt hier over een lek bij VLC? Dat een lib wordt gebruikt door een populaire app, wil nog niet zeggen dat zij ook daarvoor verantwoordelijk dragen en/of die onderhouden. Een andere app die deze (ongepatchte) lib ook gebruikt, kan ook net zo goed lek zijn.

[tweaker2010]

Dat laatste. Feitelijk zou dit artikel een rectificatie van Tweakers moeten zijn.

[Whatts]

Ik verwacht eerlijk gezegd meer van Tweakers dan suggestieve koppen.

[Mit-46]

Het is helaas wel vaker. Ik zat mij er laatst met de Huawei hype ook enorm aan te irriteren.

Het aangeven zoals op deze manier is het enige wat wij kunnen doen.

Deze VLC situatie is weer net zo. Beetje nu.nl niveau.

[Reactie gewijzigd door Mit-46 op 28 juli 2024 15:07]

[RoestVrijStaal]

De grote grap is ook dat volgens het gelinkte(!) tweet in het artikel om ÉÉN library (libebml) gaat.

Tweakers.net weet dat op magische wijze te multipliceren.

[RoestVrijStaal]

Dat had ik al gemeld, dus als het goed is, is het al gecorrigeerd.

[mikesmit]

Hoezo verwacht je meer? Als tweakers niet aan een beetje clickbait deed hadden we vergeven van de ads geweest ondertussen

[Anoniem: 134660]

En terecht dat VLC over de media klaagt. Ongecheckte bronnen, geen wederhoor en klakkeloos kopiëren van dubieuze bronnen. Een excuus voor het publiceren van dit fake news (ook vanuit tweakers) is op zijn plaats.

[TijsZonderH]

Ja, terechte kritiek (al vind ik de term fake news hier niet echt op z'n plaats, maar dat is een semantische discussie denk ik). In dit geval ben ik inderdaad teveel uit gegaan van de bugtracker, ik wist niet dat die bij VLC door iedereen kon worden aangevuld. Verder zit je altijd met afwegingen die je maakt voor je iets publiceert, bijvoorbeeld hoeveel tijd en welk kennisniveau je zelf hebt. Dat had in dat geval zeker beter gekund, ik probeer ook wel te bedenken op welke manier dan.

[kuurtjes]

Ik denk dat je niet veel had kunnen doen. Ze hebben zelfs een CVE gemaakt.

Ik zou liever zien dat de onderzoekers en gizmodo nu minder geloofwaardig bezien worden.

[jeabakker]

De CVE is door een andere (2) partijen aangemaakt ook zonder te gaan vragen bij VLC. Dus die CVE hadden niet eens aangemaakt mogen worden.

[OxWax]

Net als Bloomberg met hun 'anonieme bronnen' en 'gelekte emails'

[OxWax]

Ja, terechte kritiek (al vind ik de term fake news hier niet echt op z'n plaats, maar dat is een semantische discussie denk ik). In dit geval ben ik inderdaad teveel uit gegaan van de bugtracker, ik wist niet dat die bij VLC door iedereen kon worden aangevuld. Verder zit je altijd met afwegingen die je maakt voor je iets publiceert, bijvoorbeeld hoeveel tijd en welk kennisniveau je zelf hebt. Dat had in dat geval zeker beter gekund, ik probeer ook wel te bedenken op welke manier dan.

Collega even raadplegen?

[TijsZonderH]

Dit is inderdaad een optie.

[bkor]

ik wist niet dat die bij VLC door iedereen kon worden aangevuld.

Bij vele open source / free software projecten zijn veel redelijk vrij. Inclusief commentaar geven in een bestaande bug. Je wilt als project juist dat mensen geïnteresseerd raken. Blokkades opwerpen gaat tegen het open zijn in, plus is een onnodige barrière. Uiteindelijk heb je continue nieuwe mensen nodig die meehelpen.

[kuurtjes]

ook hoe de media daarover schreven

nieuws: Onderzoekers vinden lek in VLC dat remote code execution mogelijk maakt

Tweakers ook

(het was zelfs geen remote code execution)

[TijsZonderH]

Staat ook twee keer in het artikel hè. Ik zet voor de volledigheid ook nog een update bij het oude artikel, al wordt dat inmiddels in de praktijk nu veel minder gelezen.

[TheVivaldi]

Maar vaak worden in discussies nog wel oude artikelen aangehaald, dus het is nog steeds goed om het er bij te zetten.

[Reactie gewijzigd door TheVivaldi op 28 juli 2024 15:07]

[ManIkWeet]

Dus... uiteindelijk was het FakeWrong news... Mediabedrijven mogen wel weer eens meer aandacht besteden aan fact checking...

[Reactie gewijzigd door ManIkWeet op 28 juli 2024 15:07]

[TijsZonderH]

Dat vind ik een behoorlijk beladen term, ik verkies dan liever iets als 'foutief nieuws' of zo. Het is niet bewust gebracht om anderen op een verkeerd spoor te zetten.

[OxWax]

"mediabedrijven" zijn tegenwoordig niet meer dan C/P bedrijven. 1 artikel ergens en de rest doorslagje , al dan niet aangedikt.

[TheVivaldi]

Vooral qua koppen met al die clickbait.

[ikweethetbeter]

Gelukkig maar dat ik gewoon VLC ben blijven gebruiken!
Het is overigens wel een blunder eerste klas van de onderzoekers!

[Reactie gewijzigd door ikweethetbeter op 28 juli 2024 15:07]

[HollowGamer]

Ik heb liever 20 blunders, dan geen enkel. Het is al vaker voorkomen dat uit een oude bug die gepatched zou zijn, nog wel degelijk werkt in een nieuwere versie. Of nog leuker, dat een distro nog altijd oude libs meelevert of verkeerd patched.

Wat mij betreft had de onderzoeker wel gewoon de CVE-richtlijnen moeten volgen. De enige reden dat dit nu een groot issue is komt door de komkommertijd van de media.

[Reactie gewijzigd door HollowGamer op 28 juli 2024 15:07]

[L0g0ff]

@TijsZonderH respect dat je de reacties hier zo correct beantwoord!

[TijsZonderH]

Thanks!

[wica]

Tja,

Hoe had een nieuwsmedium als tweakers, de foute berichtgeving kunnen voorkomen?

[Parrotmaster]

Controleren bij VLC of de bevindingen die gedaan zijn gebaseerd op de bugtracker kloppen.

[TijsZonderH]

In theorie ja, in de praktijk ligt dat iets lastiger. Je komt dan bijvoorbeeld sowieso met tijd in de knoop, hoe lang wacht je bijvoorbeeld op een reactie voor publicatie? Dit is ook een uitzonderingsgeval, dat iedereen bij VLC een bugtracker kan openen is lang niet bij iedereen zo en dat wist ik niet, als ik het had geweten had ik eerder bij ze zelf gecheckt ja. Daar komt ook bij dat lang niet ieder bedrijf even open reageert op een vraag, als het om een écht lek zou gaan zou dat waarschijnlijk worden gedownplayed (excuses voor dat lelijke woord).

[Webgnome]

In theorie ja, in de praktijk ligt dat iets lastiger. Je komt dan bijvoorbeeld sowieso met tijd in de knoop, hoe lang wacht je bijvoorbeeld op een reactie voor publicatie?

Nou heel simpel. Je publiceerd zoiets niet als je nog niet alles boven tafel hebt? Of je schrijft met een dikke vermelding dat je nog niet alles hebt kunnen checken en geeft later een update op dat artikel?

[TijsZonderH]

Helaas is dat minder simpel dan ik zou willen. Je gaat in een dergelijk geval uit van andere info zoals de CVE, de bugtracker, deels ook andere media... Checken bij de bron of het lek proberen te reproduceren zijn opties die ik in een ideale wereld altijd zou willen inzetten, maar helaas moet je vaak ook de afweging maken en concluderen dat dat niet realistisch is.

Aanvulling: ik wil in de toekomst bij lekken zeker bedenken of we iets bij kunnen zetten of reproduceerbaarheid of iets in die richting. Ook als dat bijvoorbeeld niet mogelijk is, of als we het niet doen vanwege tijdgebrek. Weet alleen nog niet precies in welke vorm.

[Reactie gewijzigd door TijsZonderH op 28 juli 2024 15:07]

[Marcel317]

Dat het minder simpel is, betekent niet dat het niet de juiste manier is. Ik vind het best kwalijk om dingen te publiceren waarvan niet gecontroleerd is of het daadwerkelijk klopt. Dat er allerlei redenen zijn waarom dat nog niet gecontroleerd kon worden of wat dan ook, is totaal niet relevant. Iets zou niet gepubliceerd moeten worden voordat daadwerkelijk gecontroleerd is of het klopt, óf er moet een duidelijke kanttekening bij geplaatst worden. Op het moment van publiceren was namelijk al duidelijk dat er mogelijk onwaarheden in het artikel stonden. Althans, dat zou duidelijk moeten zijn, aangezien er niets gecontroleerd is. (Niet bij degenen die er daadwerkelijk iets over konden zeggen)

[Reactie gewijzigd door Marcel317 op 28 juli 2024 15:07]

[Nico de Vries]

Bij security risico's wil je ook weer niet te lang wachten. VLC wordt best wel heel veel gebruikt.

Wellicht is snel publiceren maar wel een voorbehoud maken een betere weg.

[TheVivaldi]

Zo snel was Tweakers anders niet, want de bug is een maand geleden geopend en de CVE enkele dagen voordat het artikel hier verscheen.

[Marcel317]

Oh helemaal mee eens, maar dan moet wel vastgesteld zijn dat het een security risico ís.

Een voorbehoud maken is prima wat mij betreft. Alles is beter dan de huidige manier in ieder geval.

[DeComponeur]

Helemaal voorkomen van verkeerde berichtgeving is helaas niet mogelijk. Als je jezelf scherp houdt en niet klakkeloos bent is dat de best effort. Volgens mij heb je/jullie naar eer en geweten een artikel geplaatst.
Helaas blijkt dit niet te kloppen en baal je daar van
Trek je vooral niks aan van mensen die hier kritisch en te makkelijk op reageren. Als het goed is kun je nog steeds in de spiegel kijken en voelt het als een doelpunt in eigen doel die je niet had kunnen voorkomen
'Volgende keer niet weer doen' zou mooi zijn, maar je weet nu al zeker dat het nog wel eens gaat gebeuren.
Maar je weet ook zeker dat je er nog meer aan zult doen om dat te voorkomen ...

[Reactie gewijzigd door DeComponeur op 28 juli 2024 15:07]

[TijsZonderH]

Dat is absoluut niet waar en ik hoop dat je Tweakers niet zo ziet, want dan doen we echt iets fout.

[AddictIT]

Toch is het de nagel op de kop, en alle media zijn hier in hetzelfde bedje ziek.
Bedenk je eens hoeveel krediet je zou krijgen van een technisch onderlegd publiek wanneer jullie pas iets publiceren als de nodige bronnen gecontroleerd zijn (voor zover realistisch mogelijk).

Nee, tegenwoordig is het beter de eerste te zijn, dan het juist te hebben.
Rechtzettingen kunnen altijd, ook al is het kwaad dan al geschied.

Zogenaamd de eerste willen zijn, is de teloorgang van de journalistiek, want de kwaliteit moet er op inboeten.

[TijsZonderH]

Dat is zeker een probleem in de journalistiek, en ook bij ons speelt dat zeker mee. Maar ik denk niet dat je het zo zwart-wit moet zien. Je zegt dat we krediet zouden krijgen, maar als we maar twee berichtjes per dag online zetten die weliswaar HEEL goed gecheckt zijn dan krijgen we ook minstens zoveel kritiek dat we overal te laat mee zijn en veel dingen onderbelicht laten. Het is en blijft een afweging tussen tijd en moeite, al ben ik het in dit geval zeker eens dat die afweging verkeerd was.

[RuudAnders]

Ik denk niet dat de afweging an sich verkeerd was, ook al is het resultaat niet zoals gewenst.

[diyoo]

Je zet dan niet twee berichtjes online per dag, maar dezelfde hoeveelheid berichtjes twee dagen later (er even vanuit gaande dat je niet gaat zitten niksen in de tijd dat er vragen openstaan). Persoonlijk heb ik liever berichten op tweakers die een meerwaarde hebben door journalistiek onderzoek, dan een copy/paste van een andere site. Dat soort berichten zijn soms ook prima, maar zet er dan gewoon even bij dat de bron nog niet heeft kunnen reageren (of dat jullie geen navraag hebben gedaan vanwege tijdgebrek). Wel zo eerlijk, niet zoals je eerder aangeeft "minder simpel dan dat je zou willen", en bovendien heeft de lezer dan context in hoeverre de informatie te vertrouwen is. De uitleg "als we maar twee berichtjes per dag online zetten die weliswaar HEEL goed gecheckt zijn dan krijgen we ook minstens zoveel kritiek dat we overal te laat mee zijn" vind ik wat slap, aangezien je die heel makkelijk pareert met "maar wij hebben WEL onderzoek gedaan". Iedereen maakt weleens een foutje, inclusief ondergetekende, maar het eromheen gedraai van waarom dit is gebeurd vind ik wat vreemd. Zeg gewoon we hebben hier iets niet goed gedaan, in het vervolg komt er een disclaimer of korte uitleg bij en klaar. op deze manier loopt w.m.b. de betrouwbaarheid van tweakers berichtgeving hier toch wel een klein deukje op.

[Amasik]

Je eerste zin kan niet. Je kan niet verwachten dat Tweakers meer tijd per artikel gaat besteden voor meer diepgang, en tegelijkertijd evenveel artikelen kan schrijven.

Er vanuit gaande dat de hoeveelheid FTE hetzelfde blijft.

Deze rectificatie had zeker beter gekund, maar vind ik al een stuk beter dan gizmodo die zeggen "uninstall, or maybe not"

[P_Tingen]

Je zet dan niet twee berichtjes online per dag, maar dezelfde hoeveelheid berichtjes twee dagen later

Dit gaat niet vliegen natuurlijk; je kan de tijd die je gebruikt voor het checken niet gebruiken voor het schrijven van andere artikelen

[Nyarlathotep]

En toch zie ik hier ook veel klachten over te laat gepubliceerde artikelen. Het is wat dat betreft nooit goed...

Maar ik ben het er mee eens dat je foute of onjuiste berichtgeving altijd moet proberen te voorkomen.
Helemaal uitsluiten kun je het helaas niet; ook in de bron kan het mis gaan.

[Mit-46]

Netjes corrigeren is toch niets mis mee?

Dit item is niet netjes gecorrigeerd.

[Reactie gewijzigd door Mit-46 op 28 juli 2024 15:07]

[zap8]

Het eerste willen zijn heeft natuurlijk ook met kliks en dus inkomsten te maken. Ik denk dat daar ook het probleem ligt als het gaat om hedendaagse berichtgeving. Dat er later even excuses gemaakt worden of een retificatie plaatsvindt wordt op de koop toegenomen. Want zoals gezegd het gaat om verlies inkomsten.

[HollowGamer]

Je zou inderdaad denken dat er kritische en eerlijke journalisten zijn. Ik vind het ook nogal vaag dat iemand zonder kennis, wel een heel artikel publiceert en dus niet weet waar hij overschrijft.

Als ik sensatie wil lees ik wel de Telegraaf of Story, daar staat T.net nu eenmaal niet om bekend en doorgaans zijn ze goed geïnformeerd. Echter zie ik het geliefde T.net verslechteren met allemaal nieuws en reviews die niet kloppen, om maar over de winacties te zwijgen.

[Reactie gewijzigd door HollowGamer op 28 juli 2024 15:07]

[Freeaqingme]

In theorie ja, in de praktijk ligt dat iets lastiger. Je komt dan bijvoorbeeld sowieso met tijd in de knoop, hoe lang wacht je bijvoorbeeld op een reactie voor publicatie?

Je kan ze toch in ieder geval een mailtje sturen voor de lunch, en na de lunch kijken of je reactie hebt? Ik snap dat je er niet dagen op wil wachten, maar dan heb je in ieder geval een poging gedaan.

Wellicht denk ik er te simpel over, maar dan zet je in je artikel "We hebben VideoLan om een reactie gevraagd, maar zij konden nog niet (direct) reageren.". Als er dan een reactie komt dan update je het artikel, of - afhankelijk van de nieuwswaarde - publiceer je een apart artikel met de scoop?

Nu heb ik het idee dat er vaak op voorhand helemaal niet gepoogd wordt dergelijke info te verifieren omdat er al bij voorbaat vanuit gegaan wordt dat het toch niet op schiet/geen waarde toevoegt/te veel moeite kost.

Het resultaat in dit geval was dat de naam van VLC is zwartgemaakt terwijl het eigenlijk Canonical/Ubuntu had moeten zijn: "Canonical shipt VLC met een library die 18 maanden oud is en mogelijke - maar niet bevestigd - exploitable bugs bevat"

[TijsZonderH]

In dat geval heb ik niet om een reactie gevraagd door de verkeerde aanname dat de bug door VideoLAN zelf was geplaatst. Als er iets niet duidelijk is doen we altijd aan wederhoor, ook al weten we vaak dat dat niet of pas heel laat komt. Als het om eigen nieuws gaat publiceren we sowieso niet vóór we die hebben. Overigens merken we wel dat artikelen met een update na een paar uur VEEL minder worden gelezen, dan is het kwaad al geschied. Is dat dan echt slim om te doen? Oprechte vraag, want ik weet het persoonlijk niet. Dat is iets waar ik nu over denk.

[mjtdevries]

Wat nu is gedaan om het te corrigeren wat mij betreft de enige juiste methode:
Een nieuw artikel plaatsen EN een update in het oude artikel.

[Anoniem: 392841]

De bugreport zelf is echter gesigneerd met een username. Daarnaast, ik weet dat jullie een boel behandelen, maar zhangwy is al vaker voorbij gekomen afgelopen maanden met claims die twijfelachtig waren. Als ik het me goed herinner heeft hij een paar maanden terug al een geintje uitgehaald waarbij hij samen met anderen een claim maakte over een lek in iets zonder het betreffende bedrijf op de hoogte te stellen (en het vervolgens een foutieve claim bleek).

EDIT: Ik dacht dat het om een foutieve claim mbt AMD chips was, vlak nadat een van de bugs van Intel bekend werd.

[Reactie gewijzigd door Anoniem: 392841 op 28 juli 2024 15:07]

[RoestVrijStaal]

In theorie ja, in de praktijk ligt dat iets lastiger. Je komt dan bijvoorbeeld sowieso met tijd in de knoop, hoe lang wacht je bijvoorbeeld op een reactie voor publicatie?

Gelul, dit is gewoon fact-checking die een goede journalist moet doen.

Nou is het te begrijpen dat sommige bugtrackers (zoals in dit geval Trac) voor leken niet de meest handige user interface hebben. Maar Trac heeft knoppen, er is een zoekfunctie. Het is niet zo "eng" als een gitzwarte met indringende witte letters gekleurde CLI.

Dit is ook een uitzonderingsgeval, dat iedereen bij VLC een bugtracker kan openen is lang niet bij iedereen zo en dat wist ik niet, als ik het had geweten had ik eerder bij ze zelf gecheckt ja.

Tweakers.net heeft software-engineers in huis, dan had je dat toch aan hen kunnen vragen? Of aan hen kunnen vragen of ze hetzelfde kunnen reproduceren in een paar testomgevingen?

Daar komt ook bij dat lang niet ieder bedrijf even open reageert op een vraag, als het om een écht lek zou gaan zou dat waarschijnlijk worden gedownplayed (excuses voor dat lelijke woord).

Daar heb je dan wel weer gelijk in.
Ware het niet dat in het geval van VLC de broncode open is. Dus als de ontwikkelaars het keihard ontkennen of verzwijgen, komt de boemerang duizendmaal harder terug.

[Reactie gewijzigd door RoestVrijStaal op 28 juli 2024 15:07]

[rob12424]

Normaal zeg ik je hebt gelijk. Maar in dit geval is het een opensource programma. Je had minstens de huidige versies tegen die van de researcher kunnen leggen toch?

[Caseum]

Is inderdaad een goede optie.
Alleen heb je geen idee hoe snel VLC erop antwoord.

Die wachttijd kan wel er voor zorgen dat je de zoveelste bent die het artikel plaatst.
Terwijl je graag als 1 van de eersten het artikel wil plaatsen zodat er meer bezoekers komen voor je site

[TijsZonderH]

Qua context: we hebben hier niet het streven altijd de allereerste te zijn, maar dat wil niet zeggen dat tijd helemaal geen rol speelt. Als ik in dit geval zou wachten op een reactie van VLC en die zou de volgende dag pas binnenkomen, ga je dan nog posten? Zeker als VLC zegt "ja, klopt allemaal"? Dan heb je het nieuws na een dag pas online en dat is te laat.

[TheVivaldi]

Maar je was sowieso al laat want de bug is een maand geleden geopend, de CVE enkele dagen voor jullie artikel verscheen en overige media berichtten al 2 dagen voor jullie artikel hierover. Dus die ene dag langer had dan ook niet meer uitgemaakt.

[TheVivaldi]

Maar je was sowieso al laat want de bug is een maand geleden geopend, de CVE enkele dagen voor jullie artikel verscheen en overige media berichtten al 1-2 dagen voor jullie artikel hierover. Dus die ene dag langer had dan ook niet meer uitgemaakt.

[TijsZonderH]

Goede vraag waarvan ik zou willen dat ik er meteen een antwoord op kon geven. Zoals ik hierboven ook schreef: je hebt bij zo'n bericht altijd te maken met afwegingen en in dit geval ging daar iets fout ja.

[ikweethetbeter]

Je probeert verschillende bronnen voor het nieuws te vinden. Alleen hier sprong iedereen meteen op, dus alle media waren hier fout.

[TijsZonderH]

Dat is inderdaad deel van het probleem, want ik baseer me (deels) op wat andere gespecialiseerde media schrijven (niet alleen Gizmodo etc, ook de wat onbekendere securitywebsites). Dat is natuurlijk geen echt excuus en dat is ook zeker niet leidend in zo'n proces, maar wel iets waar ik over na wil denken.

[Mikke8]

Er zijn ook andere instanties die in het process fouten hebben gemaakt.
Er had in dit geval ook nooit een CVE mogen toegekend zijn.

Ze gaan hier in tegen hun eigen guidelines:
Determine if a CVE ID is needed and appropriate: https://cve.mitre.org/cve..._reservation_guidelines#1
Contact the affected product vendor directly: https://cve.mitre.org/cve..._reservation_guidelines#2

Het moment dat de CVE wordt toegekend gaat het eigenlijk mis. Deze organisatie lijkt me echter een (ondertussen minder) betrouwbare bron.

Het enige alternatief is dan wachten op antwoord van de ontwikkelaars of het bug zelf onderzoeken. Beide kan enorm veel (extra) tijd in beslag nemen en wordt verwacht dat dit door een organisatie als Mitre gedaan werd. Als je hier dan op wacht met publiceren en het gaat wel over een legitiem lek dan ben je voor een dergelijk issue zeer laat en kan deze ondertussen al geëxploiteerd worden in het wild zonder dat gebruikers hiervan op de hoogte zijn.

[Reactie gewijzigd door Mikke8 op 28 juli 2024 15:07]

[Division]

Om ook maar wat gewicht aan de andere kant van de weegschaal te leggen:

Het oorspronkelijke verhaal werd door T.net (achteraf gezien onterecht) overgenomen van een incorrecte bron. Dit wellicht omdat diens bericht internationaal aardig onder de aandacht kwam, dus het is begrijpelijk WAAROM het werd overgenomen door de tech media. Ook gezien de 'knowledge' status van de bron.

Echter, bij bekend worden dat het toch om iets anders ging postte T.net ook meteen dit artikel. Een rectificatie als het ware. Voor mij is dat afdoende. Het feit dat de auteur aangeeft dat hem dit tot denken zet is een mooie win voor hem als auteur- maar ook voor ons als lezers.

Alles is een process. Niemand is ooit klaar met leren of verbeteren.

Thanks voor de rectificatie.

[HollowGamer]

Maar welke rectificatie dan? De titel is nog steeds niet correct en een echt excuses heb ik niet gezien.

Ik lees wel allemaal excuses over tijd en bronnen, maar dan ben je misschien niet diegene die hier over moet schrijven, sorry.

Nu is een opensource project bezig met media, terwijl ze juist bezig mogen zijn met de ontwikkeling hiervan. Gewoon omdat een journalist niet even verder zoekt dan zijn neus lang is.

[Freeaqingme]

Ik vrees dat de realiteit is dat al die media elkaar ook kopieren. Wellicht omdat zij ook een dergelijke afweging maken. Je hebt effectief maar 1 bekende nieuwssite nodig voordat 'het hele internet' dat ene artikel (al dan niet herschreven) publiceert.

Ik ben geen journalist, maar volgens mij geldt het beginsel "1 bron is geen bron". Als alle nieuwssites elkaar kopieren dan heb je nog steeds maar 1 bron.

Reden te meer om in ieder geval een poging te doen het te verifieren. Zeker ook het feit dat er op de website van videolan.org niets te vinden was (denk ik) over de vermeende vulnerability, was op zich een goede hint om die extra moeite er in te stoppen.

[TijsZonderH]

Klopt, daarom zijn andere media meestal maar voor een klein deel leidend voor onze verhalen. In dit geval dacht ik dat de bugs in de tracker van VideoLAN zelf afkomstig waren, dat was fout. Verifiëren bij VideoLAN zelf vond ik daarom onnodig, nogmaals, gebaseerd op een foute aanname. Maar het is niet zo dat ik het schreef OMDAT andere media dat deden.

[Freeaqingme]

Fair enough, ik begrijp de redenering. Een deel van de frustratie zit 'm aan mijn kant vooral in dat op tweakers.net er steeds meer artikelen 1:1 worden overgenomen van andere media (in herschreven vorm). Dat is een discussie die met enige regelmaat terugkomt op GoT in GR. Het betreffende artikel had hier zomaar een symptoom van kunnen zijn.

Ik accepteer met alle plezier dat in dit geval de directe oorzaak wellicht een verkeerde aanname was over hoe VLC's bugtracker werkt, maar denk dat ook het onderliggende 'probleem' hier opspeelt: Er is een wens om iedere dag X artikelen te publiceren met Y mensen. Hierbij is X ongetwijfeld altijd net iets meer dan Y wenselijk zou vinden.

Zou die druk er niet zijn, dan had de auteur voor de grap eens de nieuwste versie van VLC gedownload, en gekeken of hij het probleem kon reproduceren met wat in de issue tracker stond. Dan nog eens wat security mensen gebeld om te vragen of ze 't probleem wilden duiden, en tot slot uiteraard ook VLC zelf even een mailtje gestuurd met 'dit zijn mijn bevindingen, hebben jullie hier aanvullingen op?'.

Dat lijkt me leuke artikelen overleveren, maar daarbij moeten we dan ook accepteren dat 't volume fors daalt. Da's een afweging die natuurlijk ook allemaal business implicaties heeft, dus begrijp dat kwaliteit en diepgang niet de enige overweging zijn.

Nu is 't vaak toch "heb ik 2 bronnen? Ja? Dan kan ik 't snel herschrijven en publiceren. Snel door naar het volgende artikel". Of althans, die indruk krijg ik.

[TijsZonderH]

Je hebt helemaal gelijk ja, maar weet wel dat dit zeker een discussie is die hier op de redactie speelt.

Kijk, in een ideale wereld zou ik voor ieder berichtje van 200 woorden over een bug een security-expert lastig vallen voor feedback, zelf reproductie doen, manuals doorspitten en een dag wachten op wederhoor, maar dan verschijnen er twee berichten per dag online en krijgen we daar weer commentaar op

Je moet een balans zoeken, zowel voor individuele berichten als deze als voor onze nieuwsselectie in het algemeen. Daar is geen eenzijdig antwoord op maar we denken daar zeker wel over na. Alleen soms gaat het helaas fout zoals in dit geval.

[mjtdevries]

Het lijkt mij ook niet realistisch dat je bij elke bug melding verwacht dat Tweakers die zelf gaat reproduceren. (tenzij het supersnel te checken is)

Het issue is duidelijk. Per abuis werd gedacht dat de bug in de bugtracker door VLC zelf geplaatst was.

Daar zit de verwarring, en waarschijnlijk ook veroorzaakt door de manier waarop die onderzoeker de bug gemeld heeft. Dat laatste is wellicht ook een goed topic voor een nieuws artikel.

[tonkie_67]

Ben op veel punten met Tijs eens. T-net heeft ook regelmatig eigen content gebasseerd op non published data incl screenprints van interne vendor docs en dan hebben ze in no time legal department uit Round-Rock in de email of foon.... en je wil/kan ook je relaties met de grote hardware jongens op het spel zetten want die heb je ook nodig (demo boxen voor nieuwe hw refs etc)
Altijd iemand niet blij

[burne]

Goed dat je het toegeeft, goed dat je het rechtzet en meer dan goed dat je nadenkt over hoe je het de volgende keer kunt voorkomen.

Ik zie geen aanleiding voor klachten.

[beerse]

Voorkomen kan niet altijd. Nieuws is nieuws als het nieuw is. Natuurlijk is fact-checken een punt. Maar je moet ook uit kunnen gaan van de 'kwaliteit' van de feiten. De bron, de cve, de melding.

Gelukkig heeft tweakers een goede reputatie in het netjes verbeteren van de nieuwsberichten en daar zelf ook weer nieuws van maken.

Dat VLC dit niet als bug maar als security-issue had willen ontvangen. Het issue is een bug dus als bug invoeren kan en mag altijd.

Dat het een cve notering heeft gekregen is het ook waard om het te onderzoeken.

[beerse]

Tja, in de bugtracker staat bij platform 'gnu/linux'. Zonder versie of jaartal of zo. Dan kan ik op oude platformen ook issues opzoeken.
Maar aan de andere kant: ubuntu 18.04 is nog steeds 'current'. Het is immers een LTS variant: Support loopt nog wel een paar jaar. Op dit moment is 18.04.02 actief.
Is dit issue met de verouderde bibliotheek ook aan de library en ubuntu doorgegeven? mogelijk zijn er meer gebruikers.

[kakanox]

Goed punt, maar is het wel met 18.04.2 getest?

[TheVivaldi]

Volgens de onderzoeker wel ja.

[cyberstalker]

Ik heb hier zelf geen Ubuntu, maar Debian, komt natuurlijk redelijk overeen. Volgens apt zijn er maar een paar pakketten die libebml gebruiken:

$ apt-cache rdepends libebml4v5
libebml4v5
Reverse Depends:
libmatroska6v5
vlc-plugin-base
mkvtoolnix-gui
mkvtoolnix
libebml-dev

Naast vlc lijkt het dus vooral mkvtoolnix te zijn.

[TheVivaldi]

"Het is immers een LTS variant: Support loopt nog wel een paar jaar."

Support loopt nog tot 2028, vind jij dat werkelijk "een paar jaar"???

[kakanox]

2023

[TheVivaldi]

Nee, 2028: https://news.softpedia.co...for-10-years-523864.shtml

"Canonical CEO Mark Shuttleworth revealed the fact that the Ubuntu 18.04 LTS (Bionic Beaver) operating system series will be supported with software and security updates for 10 years, until April 2028."

Geen foutieve informatie verspreiden a.u.b., kakanox.

[Reactie gewijzigd door TheVivaldi op 28 juli 2024 15:07]

[kakanox]

@TheVivaldi Je roept "geen foutieve informatie verspreiden a.u.b.", en dan link je naar Softpedia?
Laten we gewoon op de Ubuntu-site kijken:

https://ubuntu.com/download/server

I quote:

Ubuntu Server 18.04.2 LTS
The long-term support version of Ubuntu Server, including the Queens release of OpenStack and support guaranteed until April 2023 — 64-bit only.

Zolang het niet op hun eigen site staat geloof ik het in ieder geval niet.

Edit: quote uit een gerelateerd bug report van de Canonical staff:

The 10 years timeline includes 5 years of open support, followed by 5 years of support under Canonical's Extended Security Maintenance product.

I don't think this translates to changing the output of ubuntu-support-status, any more than it did for Ubuntu 12.04 LTS.

Betaalde support voor servers, dus geen desktop en vermoedelijk weer met een selectie van pakketten.

[Reactie gewijzigd door kakanox op 28 juli 2024 15:07]

[TheVivaldi]

Kan me niet schelen of het een selectie van pakketten is of niet en of het betaald is of niet, 2028 EOL=2028 EOL. En dat het alleen server betreft maakt ook niet uit; ik heb nergens in deze discussie gezien dat we het over de desktopversie hadden.

En het staat wel gewoon op hun site, kijk maar naar de grafiek:
https://ubuntu.com/about/release-cycle

En naar de tabel op hun wiki:
https://wiki.ubuntu.com/Releases

[Reactie gewijzigd door TheVivaldi op 28 juli 2024 15:07]

[kakanox]

Nutteloze discussie. "Guaranteed until 2023" is "Guaranteed until 2023", niet "Guaranteed until 2028".
Dat er nog wel wat mogelijk is ná 2023 is leuk, maar laten we in 2024 verder babbelen als jij je consumer focused pakketjes uit 2017 in 18.04.2 bijgewerkt probeert te krijgen, goed?

[jj71]

VideoLAN zegt dat een beveiligingsonderzoeker een oude versie van Ubuntu gebruikte om het lek te testen en dat die versie 18.04 nog oude libraries gebruikte.

Ok, 18.04 is niet de nieuwste Ubuntu release, maar het is geen oude / verouderde versie; het is de nieuwste Long Term Support release, die wordt ondersteund tot april 2023.

[hackerhater]

Inderdaad en dat lek moet dan ook in deze LTS gerepareerd worden.

[TheVivaldi]

April 2028* (https://news.softpedia.co...for-10-years-523864.shtml)

Jij bent al de tweede hier die die fout maakt

[Reactie gewijzigd door TheVivaldi op 28 juli 2024 15:07]

[jj71]

Even opgezocht bij Ubuntu zelf: https://ubuntu.com/about/release-cycle / https://wiki.ubuntu.com/Releases

De normale support is tot april 2023, maar tot 2028 is er "extended security maintenance for customers". Het is niet helemaal duidelijk maar met "customers" bedoelen ze vast mensen die betalen voor extended support.

[Reactie gewijzigd door jj71 op 28 juli 2024 15:07]

[TheVivaldi]

Dat maakt toch verder niet uit? 2028=2028.

Als Kia zegt "7 jaar garantie" en eigenlijk bedoelt "5 jaar complete garantie + 2 jaar alleen garantie op de motor" dan is het nog steeds 7 jaar.

[Reactie gewijzigd door TheVivaldi op 28 juli 2024 15:07]