Des failles dans VLC permettaient de faire planter l'application ou d'exécuter du code

Des failles dans VLC permettaient de faire planter l’application ou d’exécuter du code

Des failles dans VLC permettaient de faire planter l'application ou d'exécuter du code

VideoLAN a publié un bulletin de sécurité pour des failles dans VLC 3.0.6 et versions antérieures. Il est indiqué qu'un « utilisateur distant peut créer des fichiers avi ou mkv spécialement conçus qui, lorsqu'ils sont chargés par l'utilisateur cible, vont provoquer un débordement de la mémoire tampon ».

Leur exploitation nécessite qu'un utilisateur « ouvre explicitement un fichier ou un flux spécialement conçu ». Dans la première version du bulletin, il était indiqué qu' « ASLR et DEP aident à réduire les risques, mais peuvent être contournés », mention qui a disparu. 

Le bulletin affirme que VLC 3.0.7 corrige ces failles, mais ce n'est pas tout. Lors de la mise à jour, une précision a été ajoutée : « Cette version corrige également un problème de sécurité important pouvant entraîner l'exécution de code lors de la lecture d'un fichier AAC ».

Il est, comme toujours, recommandé de mettre à jour le lecteur multimédia avec la dernière version disponible, la 3.0.7 en l'occurrence. Pour rappel, celle-ci corrige pas moins de 33 failles

Commentaires (14)


Juste non.



Y a 30+ failles que on a corrigé en 3.0.7, et ces 2 failles là sont plutôt dans le bas/milieu du panier.



La seconde, c’est MITRE qui fume totalement, en mettant un 9.8 à un double-free. Oui, ça peut crasher, mais non, ce n’est pas exploitable du tout, avec l’ASLR (et le HeASLR en 64bits).



Y a une faille en 3.0.7 qui est high, mais clairement aucune de ces 2 là.


La conclusion est la même : il faut mettre à jour sans traîner <img data-src=" />



Merci pour la précision, et pour le boulot sur le lecteur !


Il faut toujours mettre à jour.


bien sûr :-)



Petite question : vous utilisez des outils d’analyse de qualité de code pour identifier les éventuels problèmes ?


Plein: statique, dynamique, code coverage, fuzzing.








jb a écrit :



Juste non.



Y a 30+ failles que on a corrigé en 3.0.7, et ces 2 failles là sont plutôt dans le bas/milieu du panier.



La seconde, c’est MITRE qui fume totalement, en mettant un 9.8 à un double-free. Oui, ça peut crasher, mais non, ce n’est pas exploitable du tout, avec l’ASLR (et le HeASLR en 64bits).



Y a une faille en 3.0.7 qui est high, mais clairement aucune de ces 2 là.







Du coup c’est quoi ? Une fake news ?



non. Juste imprécise. Et c’est surtout parce qu’on arrive pas à discuter avec les gens de MITRE: on n’est pas assez gros pour avoir ce droit. Donc, c’est l’enfer à chaque faille…


Heureusement qu’il y a MPC-HC.


<img data-src=" />


Les vrais utilisent Windows Media Player avec les codecs qui vont bien.


Realtek Media Player ou Quicktime player, largement plus performant et ergonomiques



/troll&gt;



Sinon merci jb et l’équipe VLC pour tout votre travail !








jb a écrit :



La seconde, c’est MITRE qui fume totalement, en mettant un 9.8 à un double-free. Oui, ça peut crasher, mais non, ce n’est pas exploitable du tout, avec l’ASLR (et le HeASLR en 64bits).







C’est vrai que c’est un peu nawak.





A Buffer Overflow in VLC Media Player causes a crash which can possibly be further developed into a remote code execution exploit.

=&gt; Score: 6.5 MEDIUM







An issue was discovered in zlib_decompress_extra (…). The Matroska demuxer, while parsing a malformed MKV file type, has a double free.

=&gt; Score: 9.8 CRITICAL





Soit les deux sont critiques (C,I,A=high), soit les deux sont en medium (C,I=low, A=high).



Tout à fait, il n’y a jamais aucun bug dans libavcodec, ils sont tous dus à VLC.


Pour moi, les 2 sont medium.



Y a une faille high dans la 3.0.6, qui est dûe à une dépendance, qui est un OOB write.


Fermer