Dans l'impl\u00e9mentation de la fonction de hachage cryptographique SHA-3 (Keccak), propos\u00e9e dans le paquet XKCP (eXtended Keccak Code Package), une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9couverte (CVE-2022-37454), qui pourrait conduire \u00e0 un d\u00e9bordement de m\u00e9moire lors du traitement de donn\u00e9es sp\u00e9cialement format\u00e9es. Ce probl\u00e8me est caus\u00e9 par une erreur dans le code de l'impl\u00e9mentation sp\u00e9cifique de SHA-3, et non par une vuln\u00e9rabilit\u00e9 dans l'algorithme lui-m\u00eame. Le paquet XKCP est pr\u00e9sent\u00e9 comme l'impl\u00e9mentation officielle de SHA-3, d\u00e9velopp\u00e9 avec la participation de l'\u00e9quipe de d\u00e9veloppeurs de Keccak et utilis\u00e9 comme base dans les fonctions de traitement de SHA-3 dans divers langages de programmation (par exemple, le code XKCP est utilis\u00e9 dans le module hashlib de Python, le paquet digest-sha3 de Ruby et les fonctions de hachage en PHP). <\/p>\n
Selon la d\u00e9claration du chercheur qui a identifi\u00e9 le probl\u00e8me, il a pu exploiter la vuln\u00e9rabilit\u00e9 pour compromettre les propri\u00e9t\u00e9s cryptographiques de la fonction de hachage et trouver les premier et deuxi\u00e8me pr\u00e9images, ainsi que d\u00e9terminer des collisions. De plus, il est annonc\u00e9 la cr\u00e9ation d'un prototype d'exploit permettant d'ex\u00e9cuter du code lors du calcul du hachage d'un fichier sp\u00e9cialement format\u00e9. Potentiellement, la vuln\u00e9rabilit\u00e9 peut \u00e9galement \u00eatre utilis\u00e9e pour des attaques sur des algorithmes de v\u00e9rification de signatures num\u00e9riques utilisant SHA-3 (par exemple, Ed448). Des d\u00e9tails sur les m\u00e9thodes d'attaques seront publi\u00e9s ult\u00e9rieurement, apr\u00e8s que la vuln\u00e9rabilit\u00e9 ait \u00e9t\u00e9 corrig\u00e9e dans tous les cas. <\/p>\n
L'impact de la vuln\u00e9rabilit\u00e9 sur les applications existantes n'est pas encore clair, car pour que le probl\u00e8me se manifeste dans le code, il doit y avoir un calcul de hachage cyclique par blocs et l'un des blocs trait\u00e9s doit avoir une taille d'environ 4 Go (au moins 2^32 \u2014 200 octets). Lors du traitement des donn\u00e9es d'entr\u00e9e en une seule fois (sans calcul s\u00e9quentiel du hachage par parties), le probl\u00e8me ne se manifeste pas. Comme m\u00e9thode de protection la plus simple, il est recommand\u00e9 de limiter la taille maximale des donn\u00e9es participant \u00e0 une it\u00e9ration du calcul du hachage. <\/p>\n
La vuln\u00e9rabilit\u00e9 est caus\u00e9e par une erreur dans le traitement par blocs des donn\u00e9es d'entr\u00e9e. En raison d'une comparaison incorrecte des valeurs de type \u00ab int \u00bb, la taille des donn\u00e9es \u00e0 traiter est d\u00e9termin\u00e9e de mani\u00e8re erron\u00e9e, ce qui entra\u00eene l'\u00e9criture de l'extr\u00e9mit\u00e9 au-del\u00e0 du tampon allou\u00e9. En particulier, l'expression \u00ab partialBlock + instance->byteIOIndex \u00bb a \u00e9t\u00e9 utilis\u00e9e lors de la comparaison, ce qui a conduit \u00e0 un d\u00e9bordement d'entier avec de grandes valeurs de composants. De plus, le code contenait un cast incorrect \u00ab (unsigned int)(dataByteLen - i) \u00bb, entra\u00eenant un d\u00e9bordement sur les syst\u00e8mes avec un type size_t de 64 bits. <\/p>\n