{"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\/news\/uyazvimost-v-biblioteke-s-osnovnoj-realizacziej-algoritma-sha-3","title":{"rendered":"Eine Schwachstelle in der Bibliothek mit der Hauptimplementierung des SHA-3-Algorithmus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In der Implementierung der kryptografischen Hash-Funktion SHA-3 (Keccak), die im Paket XKCP (eXtended Keccak Code Package) angeboten wird, wurde eine Schwachstelle (CVE-2022-37454) entdeckt, die zu einem Buffer Overflow bei der Verarbeitung bestimmter formatierten Daten f\u00fchren kann. Das Problem wird durch einen Fehler im Code der konkreten SHA-3-Implementierung verursacht und nicht durch eine Schwachstelle im Algorithmus selbst. Das Paket XKCP wird als offizielle Implementierung von SHA-3 pr\u00e4sentiert, entwickelt mit dem Beitrag des Keccak-Entwicklungsteams und wird als Grundlage in Funktionen zur Arbeit mit SHA-3 in verschiedenen Programmiersprachen verwendet (zum Beispiel wird der XKCP-Code im Python-Modul hashlib, im Ruby-Paket digest-sha3 und in PHP-Funktionen hash_* verwendet). <\/p>\n
Laut dem Forscher, der das Problem entdeckt hat, gelang es ihm, die Schwachstelle auszunutzen, um die kryptografischen Eigenschaften der Hash-Funktion zu beeintr\u00e4chtigen und die erste und zweite Urbilder zu finden sowie Kollisionen zu bestimmen. Zudem wurde ein Prototyp eines Exploits erstellt, der es erm\u00f6glicht, Code w\u00e4hrend der Berechnung des Hashs einer speziell formatierten Datei auszuf\u00fchren. Potenziell kann die Schwachstelle auch f\u00fcr Angriffe auf digitale Signaturpr\u00fcfalgorithmus verwendet werden, die SHA-3 nutzen (zum Beispiel Ed448). Einzelheiten zu den Methoden der Angriffe sollen sp\u00e4ter ver\u00f6ffentlicht werden, nachdem die Schwachstelle umfangreich behoben wurde. <\/p>\n
Wie stark die Sicherheitsanf\u00e4lligkeit bestehende Anwendungen tats\u00e4chlich betrifft, ist bislang unklar, da die Problematik im Code zyklisches Hashing in Bl\u00f6cken erfordert, wobei einer der verarbeiteten Bl\u00f6cke eine Gr\u00f6\u00dfe von etwa 4 GB (mindestens 2^32 - 200 Byte) haben muss. Bei der Verarbeitung von Eingabedaten in einem Rutsch (ohne sequenzielle Berechnung des Hashs in Teilen) tritt das Problem nicht auf. Als einfachste Schutzma\u00dfnahme wird vorgeschlagen, die maximale Gr\u00f6\u00dfe der Daten, die an einer Hash-Berechnung teilnehmen, zu begrenzen. <\/p>\n
Die Sicherheitsanf\u00e4lligkeit wird durch einen Fehler bei der blockweisen Verarbeitung von Eingabedaten verursacht. Wegen eines fehlerhaften Vergleichs von Werten des Typs \u201eint\u201c wird die falsche Gr\u00f6\u00dfe der zu verarbeitenden Daten bestimmt, was dazu f\u00fchrt, dass der Rest \u00fcber den zugewiesenen Puffer hinaus geschrieben wird. Insbesondere wurde bei dem Vergleich der Ausdruck \u201epartialBlock + instance->byteIOIndex\u201c verwendet, der bei gro\u00dfen Werten der einzelnen Komponenten zu einem ganzzahligen \u00dcberlauf f\u00fchrte. Dar\u00fcber hinaus gab es im Code eine falsche Typumwandlung \u201e(unsigned int)(dataByteLen - i)\u201c, die auf Systemen mit einem 64-Bit size_t Typ zu einem \u00dcberlauf f\u00fchrte. <\/p>\n