Les vulnérabilités découvertes pour LZ0 et pour LZ4 viennent d'un code datant de 1999.
En résumé, elles provoquent un dépassement du tas d'entier non-signé, ce qui conduit à une corruption locale de la mémoire.
Ce bogue n'est pas super pratique à utiliser, car il faut lancer la fonction incriminée avec assez de données pour dépasser la limite d'un entier non signé, ce qui dépend donc de l'architecture.
En pratique, cela signifie qu'une architecture 64 bits est plutôt à l'abri.
Le correctif est déjà en place pour LZ0, et il est en cours pour LZ4.
# LZO et LZ4 ?
Posté par Ytterbium . Évalué à 10.
Je présume que le journal parle des algorithmes de compression LZ4 et Lempel-Ziv-Oberhumer.
[^] # Re: LZO et LZ4 ?
Posté par Jiehong (site web personnel) . Évalué à 4.
Tu présumes bien. Il faudrait peut-être le rajouter, tiens.
# Vraiment en pratique…
Posté par Sufflope (site web personnel) . Évalué à 10.
C'est une faille quasiment purement théorique. Rien à craindre.
http://fastcompression.blogspot.fr/2014/06/debunking-lz4-20-years-old-bug-myth.html version troll
http://fastcompression.blogspot.fr/2014/06/lets-move-on.html version plus apaisée
En gros, pour déclencher ce bug il faut que les programmes sortent explicitement des clous de la spec et utilisent des tailles de buffer de plusieurs Mo, alors que tous ceux connus (y compris Linux) se limitent à quelques ko… Évidemment autant corriger ce qu'il faut pour au cas où dans le futur.
[^] # Re: Vraiment en pratique…
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Je croyais qu'il suffisait d'avoir un fichier à décompresser mal formé.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.