Plus grand qu'il n'y paraît : une bombe de décompression dans l'en-tête PNG

Un PNG est une signature suivie d'une succession de blocs, et chaque bloc a la même forme : une longueur de 4 octets, un type ASCII de 4 octets, les données, puis un checksum de 4 octets. Cette régularité est ce qui permet de naviguer dans un vidage sans analyseur. Trouvez les quatre lettres qui nomment un bloc et vous savez exactement où commencent ses données.

Le premier bloc est toujours IHDR, et ses huit premiers octets sont la largeur et la hauteur, chacune un entier big-endian de 32 bits. Big-endian signifie que l'octet de poids fort est écrit en premier, donc 00 00 75 30 vaut 0x7530 et non 0x3075. Chaque décodeur lit ces huit octets avant tout le reste, car il doit allouer le tampon de sortie avant de pouvoir y décompresser les données.

Cette allocation est l'attaque. La taille compressée et la taille décodée n'ont aucun rapport : une seule couleur uniforme sur une immense image se compresse en quelques kilo-octets et se développe en gigaoctets. Tout service qui accepte une image, vérifie que l'envoi est petit, puis la transmet à une bibliothèque a déjà perdu, parce que la bibliothèque dimensionne son tampon à partir de l'en-tête et que l'en-tête est contrôlé par l'attaquant.

• Répondre 64. Le 64x64 visible dans la colonne ASCII se trouve dans un bloc de commentaire tEXt. C'est une note, et le journal d'envoi l'a recopiée sans regarder l'en-tête.
• Répondre 20000. C'est la hauteur. La largeur vient en premier dans IHDR.
• Lire les octets en little-endian. Les entiers PNG sont en big-endian, donc 00 00 75 30 vaut 30000, et non 807534592.
• Commencer à compter à l'offset 8. Les offsets 8 à 11 sont la longueur du bloc et 12 à 15 le type. La largeur commence à l'offset 16.
• Lire le bloc pHYs. Il contient les pixels par mètre, ce qui est la résolution, pas la taille.

Décidez si le fichier doit être décodé en vous basant sur l'en-tête, avant de le décoder.

• Analysez vous-même IHDR et rejetez tout ce qui dépasse un budget de pixels. Le nombre total de pixels compte plus que chaque dimension prise seule : 30000 par 20000 fait 600 mégapixels, et un plafond de 50 mégapixels aurait arrêté cela dès l'entrée.
• Fixez les limites que votre bibliothèque d'images propose déjà. La plupart exposent un nombre maximal de pixels et refusent les fichiers surdimensionnés si vous l'activez.
• Faites ce travail dans un processus avec une limite de mémoire stricte, pour qu'un seul mauvais fichier tue un seul worker au lieu de tout le pool, et jamais dans le thread de la requête.
• Traitez chaque bloc de texte comme une décoration non fiable. Les dimensions enregistrées au moment de l'envoi doivent venir de votre propre analyse, pas d'un commentaire du fichier.