Si elles sont exploitées, ces failles peuvent permettre aux attaquants d'obtenir un accès non autorisé à des informations sensibles ou de causer des problèmes en général.
Une vulnérabilité a été identifiée (déjà répertorié sous CVE-2022-37454) en l'implémentation de la fonction de hachage cryptographique SHA-3 (Keccak), proposé dans le package XKCP (eXtended Keccak Code Package).
La vulnérabilité identifiée peut provoquer un débordement de buffer lors du traitement des données formées. Le problème est dû à un bogue dans le code d'une implémentation spécifique de SHA-3, et non à une vulnérabilité dans l'algorithme lui-même.
El Paquete XKCPName est présentée comme l'implémentation officielle de SHA-3, développée avec l'aide de l'équipe de développement de Keccak, et utilisé comme base pour que les fonctions fonctionnent avec SHA-3 dans divers langages de programmation (par exemple, le code XKCP est utilisé dans le module Python hashlib, le package Ruby digest-sha3 et les fonctions PHP hash_*).
Selon le chercheur qui a identifié le problème, pourrait utiliser la vulnérabilité pour violer les propriétés cryptographiques de la fonction de hachage et trouver les première et deuxième préimages, ainsi que déterminer les collisions.
La raison de l'erreur de segmentation est que les scripts essaieront d'écrire plus de données dans un tampon qu'il ne peut en contenir. Une telle vulnérabilité est connue sous le nom de dépassement de mémoire tampon, que l'OWASP décrit comme "probablement la forme la plus connue de vulnérabilité de sécurité logicielle".
Une petite variante du code provoquera une boucle infinie : il suffit de remplacer 4294967295 par 4294967296. Notez la similitude avec CVE-2019-8741, une autre vulnérabilité que j'ai trouvée qui affectait le firmware de plus de 1.400 milliard d'appareils Apple, ce qui a également provoqué une boucle infinie.
Également, la création d'un exploit prototype est annoncée, que permet de réaliser l'exécution du code lors du calcul du hachage à partir d'un fichier spécialement conçu. La vulnérabilité peut également potentiellement être utilisée pour attaquer les algorithmes de vérification de signature numérique utilisant SHA-3 (par exemple, Ed448). Les détails des méthodes d'attaque devraient être publiés ultérieurement, après la suppression générale de la vulnérabilité.
Ce type de comportement n'est pas censé se produire dans les langages "sûrs" comme Python et PHP, car ils vérifient que toutes les opérations de lecture et d'écriture sont dans les limites du tampon. Cependant, le problème est que la vulnérabilité est présente dans le langage C "non sécurisé" sous-jacent...
Encore on ne sait pas comment la vulnérabilité affecte les applications existantes dans la pratique, car pour que le problème se manifeste dans le code, un calcul de hachage cyclique sur les blocs doit être utilisé et l'un des blocs traités doit avoir une taille d'environ 4 Go (au moins 2^32 - 200 octets) .
Lors du traitement des données d'entrée en une seule fois (sans calcul séquentiel du hachage par parties), le problème n'apparaît pas. Comme méthode de protection plus simple, il est proposé de limiter la taille maximale des données impliquées dans une itération du calcul de hachage.
Le code vulnérable a été publié en janvier 2011, il a donc fallu plus d'une décennie pour trouver cette vulnérabilité. Il semble difficile de trouver des vulnérabilités dans les implémentations cryptographiques, même si elles jouent un rôle critique dans la sécurité globale d'un système. (Peut-être que les gens ne recherchent même pas de telles vulnérabilités, puisque ni cette vulnérabilité dans XKCP ni la vulnérabilité Apple mentionnée ci-dessus ne sont éligibles à aucun programme de primes de bogues !)
Vulnérabilité est dû à une erreur dans le traitement du bloc des données d'entrée. En raison d'une comparaison incorrecte des valeurs avec le type "int", une taille incorrecte des données en attente est déterminée, ce qui entraîne l'écriture de la file d'attente hors du tampon alloué.
En particulier, il est mentionné que lors de la comparaison, l'expression «partialBlock + instance->byteIOIndex», qui, avec des valeurs élevées des composants, conduisait à un débordement d'entier. De plus, il y avait un transtypage incorrect "(unsigned int)(dataByteLen - i)" dans le code, provoquant un débordement sur les systèmes avec un type size_t 64 bits.
Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant