One Article Review
| Source |  CVE Liste |
|---|---|
| Identifiant | 8367916 |
| Date de publication | 2023-08-09 13:15:09 (vue: 2023-08-09 15:08:16) |
| Titre | CVE-2023-33953 |
| Texte | GRPC contient une vulnérabilité qui permet aux erreurs de comptabilité de la table HPACK pourrait entraîner des déconnexions indésirables entre les clients et les serveurs dans des cas exceptionnels / & acirc; & nbsp; trois vecteurs ont été trouvés qui permettent les attaques DOS suivantes:
- tampon de mémoire illimité dans l'analyseur HPACK
- consommation de processeur illimitée dans l'analyseur HPACK
La consommation de processeur illimitée est due à une copie qui s'est produite par bloc-bloc dans l'analyseur, et parce que cela pourrait être illimité en raison du bug de la copie de mémoire, nous nous retrouvons avec une boucle d'analyse O (n ^ 2), avec n sélectionné parle client.
Les bugs de mémoire tampon de mémoire illimités:
- La vérification de la limite de taille de l'en-tête était derrière le code de lecture de la chaîne, nous devions donc d'abord tamponner jusqu'à une chaîne de 4 gigaoctets avant de la rejeter plus de 8 ou 16 Ko.
- Les varints HPACK ont une bizarrerie codante par laquelle un nombre infini de 0 & acirc; & euro; & commerce; s peut être ajouté au début d'un entier.GRPC & acirc; & euro; & Trade; s Hpack Parser avait besoin de les lire tous avant de conclure une analyse.
- GRPC & acirc; & euro; & Trade; s Le chèque de débordement des métadonnées a été effectué par cadre, de sorte que la séquence de cadres suivante pourrait provoquer une mise en mémoire tampon infinie: En-têtes: contenant une suite: 1: contenant A: 2 continuation: contenant un: 3 etc & acirc; & euro;& Brvbar;
gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clients and servers in exceptional cases/ Three vectors were found that allow the following DOS attacks: - Unbounded memory buffering in the HPACK parser - Unbounded CPU consumption in the HPACK parser The unbounded CPU consumption is down to a copy that occurred per-input-block in the parser, and because that could be unbounded due to the memory copy bug we end up with an O(n^2) parsing loop, with n selected by the client. The unbounded memory buffering bugs: - The header size limit check was behind the string reading code, so we needed to first buffer up to a 4 gigabyte string before rejecting it as longer than 8 or 16kb. - HPACK varints have an encoding quirk whereby an infinite number of 0’s can be added at the start of an integer. gRPC’s hpack parser needed to read all of them before concluding a parse. - gRPC’s metadata overflow check was performed per frame, so that the following sequence of frames could cause infinite buffering: HEADERS: containing a: 1 CONTINUATION: containing a: 2 CONTINUATION: containing a: 3 etc… |
| Notes | |
| Envoyé | Oui |
| Condensat | 0’s 16kb 2023 33953 accounting added all allow allows attacks: because before behind between block buffer buffering buffering: bug bugs: can cases/â three cause check client clients code concluding consumption containing contains continuation: copy could cpu cve disconnects dos down due encoding end errors etc… exceptional first following found frame frames gigabyte grpc grpc’s have header headers: hpack infinite input integer lead limit longer loop memory metadata n^2 needed number occurred overflow parse parser parsing per performed quirk read reading rejecting selected sequence servers size start string table than them unbounded unwanted varints vectors vulnerability whereby |
| Tags | Vulnerability |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.