8. Security Considerations (Considérations de sécurité)
Toute méthode de compression de données implique la réduction de la redondance dans les données. Zstandard ne fait pas exception, et les précautions habituelles s'appliquent.
On ne devrait jamais compresser un message dont le contenu doit rester secret avec un message généré par un tiers. Une telle compression peut être utilisée pour deviner le contenu du message secret par l'analyse de la réduction d'entropie (Entropy Reduction Analysis). Cela a été démontré dans l'attaque CRIME (Compression Ratio Info-leak Made Easy) [CRIME], par exemple.
Un décodeur doit démontrer des capacités pour détecter et prévenir tout type de falsification de données dans la trame compressée qui pourrait déclencher des défaillances système, telles que la lecture ou l'écriture au-delà des plages de mémoire autorisées. Cela peut être garanti soit par le langage d'implémentation, soit par des vérifications de limites (Bound Checking) soigneuses. Il convient de noter en particulier l'encodage des valeurs Number_of_Sequences qui font lire le décodeur dans l'en-tête de bloc (et au-delà), ainsi que l'indication d'un Frame_Content_Size inférieur aux données réellement décompressées, dans une tentative de déclencher un dépassement de tampon (Buffer Overflow). Il est fortement recommandé de tester par fuzzing (fuzz-test, c'est-à-dire fournir des entrées invalides, inattendues ou aléatoires et vérifier le fonctionnement sûr) les implémentations de décodeur pour tester et renforcer leur capacité à détecter les trames incorrectes et à les gérer sans aucun effet secondaire système indésirable.
Un attaquant peut fournir des trames compressées correctement formées avec des exigences mémoire déraisonnables. Un décodeur doit toujours contrôler les exigences mémoire et imposer certaines limites (spécifiques au système) afin de protéger l'utilisation de la mémoire contre de tels scénarios.
La compression peut être optimisée en entraînant un dictionnaire sur une variété de charges utiles de contenu connexes. Ce dictionnaire doit ensuite être disponible au décodeur pour que la décompression de la charge utile soit possible. Bien que ce document ne spécifie pas comment acquérir un dictionnaire pour une charge utile compressée donnée, il convient de noter que les dictionnaires tiers peuvent interagir de manière inattendue avec un décodeur, entraînant d'éventuelles attaques par épuisement de mémoire ou d'autres ressources (Resource-exhaustion Attacks). Nous nous attendons à ce que ces sujets soient discutés plus en détail dans la section Considérations de sécurité d'un RFC à venir sur l'acquisition et la transmission de dictionnaires, mais nous soulignons ce problème maintenant par excès de prudence.
Comme discuté dans la section 3.1.2, il est possible de stocker des métadonnées utilisateur arbitraires dans des trames ignorables (Skippable Frames). Bien que de telles trames soient ignorées lors de la décompression des données, elles peuvent être utilisées comme filigrane (Watermark) pour suivre le chemin de la charge utile compressée.