{"id":105350,"date":"2022-10-21T09:36:42","date_gmt":"2022-10-21T07:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3"},"modified":"2022-10-21T09:36:42","modified_gmt":"2022-10-21T07:36:42","slug":"uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/news\/uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3","title":{"rendered":"S\u00e5rbarhed i biblioteket med den prim\u00e6re implementering af SHA-3 algoritmen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
I implementeringen af den kryptografiske hash-funktion SHA-3 (Keccak), som tilbydes i pakken XKCP (eXtended Keccak Code Package), blev der fundet en s\u00e5rbarhed (CVE-2022-37454), som kan f\u00f8re til buffer overflow under behandlingen af specifikt formaterede data. Problemet skyldes en fejl i koden for den specifikke implementering af SHA-3 og er ikke en s\u00e5rbarhed i selve algoritmen. Pakken XKCP pr\u00e6senteres som den officielle implementering af SHA-3, udvikles med deltagelse af Keccak-udviklerteamet og bruges som grundlag for funktioner, der arbejder med SHA-3 i forskellige programmeringssprog (for eksempel bruges koden fra XKCP i Python-modulet hashlib, Ruby-pakken digest-sha3 og PHP-funktionerne hash_*). <\/p>\n
If\u00f8lge erkl\u00e6ringen fra forskeren, der opdagede problemet, har han form\u00e5et at udnytte s\u00e5rbarheden til at kompromittere de kryptografiske egenskaber af hash-funktionen og finde b\u00e5de f\u00f8rste og anden pr\u00e6billede samt identificere kollisioner. Desuden er det blevet rapporteret, at der er oprettet en prototype exploit, som muligg\u00f8r udf\u00f8relse af kode ved beregning af hash af en specifikt formateret fil. Potentielt kan s\u00e5rbarheden ogs\u00e5 udnyttes til angreb p\u00e5 algoritmer til verifikation af digitale signaturer, der bruger SHA-3 (for eksempel Ed448). Detaljer om angrebsmetoderne planl\u00e6gges offentliggjort senere, efter den generelle udbedring af s\u00e5rbarheden. <\/p>\n
Hvorvidt s\u00e5rbarheden p\u00e5virker eksisterende applikationer i praksis er endnu ikke klart, da problemet i koden kr\u00e6ver cyklisk beregning af hash i blokke, og en af de behandlede blokke skal have en st\u00f8rrelse p\u00e5 omkring 4 GB (mindst 2^32 \u2014 200 byte). N\u00e5r inddata behandles p\u00e5 \u00e9n gang (uden sekventiel beregning af hash i dele), opst\u00e5r problemet ikke. Som en af de nemmeste beskyttelsesmetoder foresl\u00e5s det at begr\u00e6nse den maksimale st\u00f8rrelse af de data, der deltager i en enkelt iterations hashberegning. <\/p>\n
S\u00e5rbarheden skyldes en fejl ved blokbehandling af inddata. P\u00e5 grund af en forkert sammenligning af v\u00e6rdier af typen \u201eint\u201c bestemmes den forkerte st\u00f8rrelse af de data, der venter p\u00e5 behandling, hvilket f\u00f8rer til, at halen skrives uden for den tildelte buffer. Is\u00e6r blev udtrykket \u201epartialBlock + instance->byteIOIndex\u201c brugt til sammenligning, som ved store v\u00e6rdier af de sammensatte dele medf\u00f8rte heltals overflow. Desuden var der i koden en forkert typekonvertering \u201e(unsigned int)(dataByteLen \u2014 i)\u201c, som f\u00f8rte til overflow p\u00e5 systemer med 64-bit size_t type. <\/p>\n