{"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\/de\/blog\/novosti-interneta\/uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3","title":{"rendered":"Sicherheitsanf\u00e4lligkeit in der Bibliothek mit der Hauptimplementierung des SHA-3 Algorithmus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Bei der Implementierung der kryptografischen Hash-Funktion SHA-3 (Keccak), die im XKCP (eXtended Keccak Code Package) angeboten wird, wurde eine Sicherheitsanf\u00e4lligkeit (CVE-2022-37454) entdeckt, die zu einem Buffer\u00fcberlauf bei der Verarbeitung bestimmter formatierten Daten f\u00fchren kann. Das Problem entsteht durch einen Fehler im Code der spezifischen Implementierung von SHA-3, nicht durch eine Schw\u00e4che des Algorithmus selbst. Das XKCP-Paket wird als offizielle Implementierung von SHA-3 dargestellt, entwickelt mit Unterst\u00fctzung des Keccak-Entwicklungsteams und wird als Grundlage in Funktionen f\u00fcr die Arbeit mit SHA-3 in verschiedenen Programmiersprachen verwendet (zum Beispiel wird der Code des XKCP in dem Python-Modul hashlib, dem Ruby-Paket digest-sha3 und den PHP-Funktionen hash_* verwendet). <\/p>\n
Laut dem Forscher, der das Problem aufgedeckt hat, konnte er die Schwachstelle nutzen, um die kryptografischen Eigenschaften der Hash-Funktion zu verletzen und den ersten sowie den zweiten Vorl\u00e4ufer zu finden, ebenso wie Kollisionen zu bestimmen. Dar\u00fcber hinaus wurde ein Prototyp eines Exploits entwickelt, der es erm\u00f6glicht, Code auszuf\u00fchren, wenn ein Hash f\u00fcr eine speziell gestaltete Datei berechnet wird. Potenziell k\u00f6nnte die Schwachstelle auch f\u00fcr Angriffe auf Algorithmen zur \u00dcberpr\u00fcfung digitaler Signaturen, die SHA-3 verwenden (wie zum Beispiel Ed448), genutzt werden. Details zu den Angriffsmethoden werden sp\u00e4ter ver\u00f6ffentlicht, nachdem die Schwachstelle umfassend behoben wurde. <\/p>\n
Wie sich die Schwachstelle praktisch auf bestehende Anwendungen auswirkt, ist derzeit unklar, da zur Manifestation des Problems im Code eine zyklische Hash-Berechnung in Bl\u00f6cken erfolgen muss und einer der verarbeiteten Bl\u00f6cke eine Gr\u00f6\u00dfe von etwa 4 GB (mindestens 2^32 \u2013 200 Byte) haben muss. Bei der Verarbeitung von Eingabedaten auf einmal (ohne sequentielle Hash-Berechnungen in Teilen) tritt das Problem nicht auf. Als einfachste Schutzma\u00dfnahme wird vorgeschlagen, die maximale Gr\u00f6\u00dfe der Daten, die in einer Iteration der Hash-Berechnung verwendet werden, zu begrenzen. <\/p>\n
Die Schwachstelle wird durch einen Fehler bei der blockweisen Verarbeitung von Eingabedaten verursacht. Wegen eines fehlerhaften Vergleichs von Werten vom Typ \u201eint\u201c wird die falsche Gr\u00f6\u00dfe der Daten bestimmt, die noch verarbeitet werden m\u00fcssen, was dazu f\u00fchrt, dass der Tail au\u00dferhalb des reservierten Puffers geschrieben wird. Insbesondere wurde beim Vergleich der Ausdruck \u201epartialBlock + instance->byteIOIndex\u201c verwendet, der bei gro\u00dfen Werten der Bestandteile zu einer Ganzzahl\u00fcberlauf f\u00fchrte. Dar\u00fcber hinaus gab es im Code falsche Typumwandlungen \u201e(unsigned int)(dataByteLen - i)\u201c, die auf Systemen mit 64-Bit-Size_t zu einem \u00dcberlauf f\u00fchrten. <\/p>\n