Une faille jugée critique découverte au sein de VLC - MàJ

Le par  |  14 commentaire(s)
VLC

Le CERT-bund allemand a annoncé avoir découvert une faille de sécurité déclarée comme critique au sein du lecteur multimédia VLC qui permettrait l'exécution de code à distance.

MàJ : Il n'y avait pas de vulnérabilité de sécurité critique dans VLC.

-----

Le Centre de réponse aux cyberattaques du gouvernement allemand, le CERT-Bund a récemment annoncé avoir mis en lumière une faille jugée critique au sein du lecteur multimédia VLC.

VLC

La situation est d'autant plus inquiétante que VLC comptabilise plus de 3 milliards de téléchargements à travers le monde. La faille identifiée comme CVE-2019-13615 a été classée niveau 4 par l'organisme, soit le niveau le plus critique.

La faille en question permettrait à des hackers d'exécuter du code à distance, mais aussi d'extraire des données de la machine ciblée. Selon le CERT-Bund, aucune exploitation de cette faille n'est à déplorer à ce jour.

Les équipes de développement de VLC travaillent actuellement à combler cette brèche, une mise à jour de sécurité devrait être proposée dans les jours qui viennent.

Complément d'information

Vos commentaires Page 1 / 2

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #2073275
Pas très sympa de dévoiler la faille avant qu'une correction soit disponible...
Le #2073276
JCDentonMale a écrit :

Pas très sympa de dévoiler la faille avant qu'une correction soit disponible...


Tu as une vulnérabilité mais à ce jour aucun vecteur d'attaque donc ils peuvent se permettre de la dévoilé.

De plus, dire que si le CERT ne l'avait pas dévoilé elle serait encore secrète serait à mon avis une belle erreur.

Par contre je suis le seul que la phrase "Le Centre de réponse aux cyberattaques du gouvernement allemand" choc ? c'est pas du tout la définition d'un CERT ... Où au pire des cas c'est occulter la majeure partie de ce que c'est pour ne retenir que le plus "attractif" pour un néophyte ...
Le #2073277
En même temps c'est pas comme si ce genre de faille n'était pas commune...
J'ai lu que c'est la base pour un développeur de faire attention à tout ce qui pourrait générer des erreurs de type overflow et qu'à priori cette faille en fait partie.

Malgré tout, je continuerai à utiliser VLC.
Le #2073278
Johnny6 a écrit :

En même temps c'est pas comme si ce genre de faille n'était pas commune...
J'ai lu que c'est la base pour un développeur de faire attention à tout ce qui pourrait générer des erreurs de type overflow et qu'à priori cette faille en fait partie.

Malgré tout, je continuerai à utiliser VLC.


Entièrement d'accord, je rajouterai même aux buffer overflow les injections SQL, histoire de couvrir une grande parties des failles "communes".
Le #2073293
Technical Details
Vulnerability Type (View All)

Improper Restriction of Operations within the Bounds of a Memory Buffer

En effet c'est du connu.
Le #2073296
La plupart des clients lourds sont, pour des raisons historiques liées à la formation des développeurs, codées dans des langages qui n'incitent pas nécessairement à coder proprement (le C étant le pire exemple, le C++ dans une moindre mesure).

Par exemple, se retrouver avec des dangling pointers en C ou C++ est très vite arrivé (surtout maintenant avec le fameux garbage collector qui incite encore moins à faire les choses proprement).

En Rust ou en Ada, pour arriver à des dangling pointers, il faut vraiment le vouloir (ou alors n'avoir rien compris à ces langages).

Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité.
Le #2073297
BeetleJuice a écrit :

La plupart des clients lourds sont, pour des raisons historiques liées à la formation des développeurs, codées dans des langages qui n'incitent pas nécessairement à coder proprement (le C étant le pire exemple, le C++ dans une moindre mesure).

Par exemple, se retrouver avec des dangling pointers en C ou C++ est très vite arrivé (surtout maintenant avec le fameux garbage collector qui incite encore moins à faire les choses proprement).

En Rust ou en Ada, pour arriver à des dangling pointers, il faut vraiment le vouloir (ou alors n'avoir rien compris à ces langages).

Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité.


Et encore tu ne prend pas en compte le client n'ayant pas une connaissance poussée et qui, malgré le devoir de conseil exercé, t'impose un langage souvent inadapté ou une technologie obsolète.

Malgré cela je vois de plus en plus l'arrivé (et c'est le cas chez nous depuis pas mal d'année) de l'intervention d'équipe Security consulting qui sont requis chez des équipes de dev pour pallier à ce genre de problème (à la fois en amont, lors de la conception, security by design) ainsi que lors du développement (security by default)).
Le #2073298
BeetleJuice a écrit :

La plupart des clients lourds sont, pour des raisons historiques liées à la formation des développeurs, codées dans des langages qui n'incitent pas nécessairement à coder proprement (le C étant le pire exemple, le C++ dans une moindre mesure).

Par exemple, se retrouver avec des dangling pointers en C ou C++ est très vite arrivé (surtout maintenant avec le fameux garbage collector qui incite encore moins à faire les choses proprement).

En Rust ou en Ada, pour arriver à des dangling pointers, il faut vraiment le vouloir (ou alors n'avoir rien compris à ces langages).

Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité.


"Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité."

Mais là c'est un produit open source avec aucun client derrière pour mettre la pression.
Le #2073301
skynet a écrit :

BeetleJuice a écrit :

La plupart des clients lourds sont, pour des raisons historiques liées à la formation des développeurs, codées dans des langages qui n'incitent pas nécessairement à coder proprement (le C étant le pire exemple, le C++ dans une moindre mesure).

Par exemple, se retrouver avec des dangling pointers en C ou C++ est très vite arrivé (surtout maintenant avec le fameux garbage collector qui incite encore moins à faire les choses proprement).

En Rust ou en Ada, pour arriver à des dangling pointers, il faut vraiment le vouloir (ou alors n'avoir rien compris à ces langages).

Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité.


"Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité."

Mais là c'est un produit open source avec aucun client derrière pour mettre la pression.


Je n'ai pas dû être assez clair.

Je disais que dans le monde du dév, la culture ambiante n'est pas d'apprendre un langage où on pense du code mais un langage où on pisse du code (selon l'expression consacrée).

Donc Open source ou pas open source, ça ne change pas la formation que chaque dev a reçue (fortement teintée de C ou de C++, très peu contraignants en terme de sécurité). Est-ce plus clair ainsi ?
Le #2073303
iinconnu a écrit :

BeetleJuice a écrit :

La plupart des clients lourds sont, pour des raisons historiques liées à la formation des développeurs, codées dans des langages qui n'incitent pas nécessairement à coder proprement (le C étant le pire exemple, le C++ dans une moindre mesure).

Par exemple, se retrouver avec des dangling pointers en C ou C++ est très vite arrivé (surtout maintenant avec le fameux garbage collector qui incite encore moins à faire les choses proprement).

En Rust ou en Ada, pour arriver à des dangling pointers, il faut vraiment le vouloir (ou alors n'avoir rien compris à ces langages).

Avant d'arriver à une communauté de développeurs formés à des langages plus vertueux il va encore couler pas mal d'eau sous les ponts (surtout que la mode est plutôt à "pisser du code" pour se conformer aux deadlines impossibles du client que de "penser du code" pour la durée et la sécurité.


Et encore tu ne prend pas en compte le client n'ayant pas une connaissance poussée et qui, malgré le devoir de conseil exercé, t'impose un langage souvent inadapté ou une technologie obsolète.

Malgré cela je vois de plus en plus l'arrivé (et c'est le cas chez nous depuis pas mal d'année) de l'intervention d'équipe Security consulting qui sont requis chez des équipes de dev pour pallier à ce genre de problème (à la fois en amont, lors de la conception, security by design) ainsi que lors du développement (security by default)).


Le client t'impose un langage ? Vous lui vendez le source ?
Suivre les commentaires
Poster un commentaire
Anonyme
Anonyme