{"id":121189,"date":"2024-12-31T15:46:00","date_gmt":"2024-12-31T13:46:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kollizii-v-sokrashhyonnyh-identifikatorah-kommitov-v-yadre-linux"},"modified":"2024-12-31T15:46:00","modified_gmt":"2024-12-31T13:46:00","slug":"kollizii-v-sokrashhyonnyh-identifikatorah-kommitov-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/kollizii-v-sokrashhyonnyh-identifikatorah-kommitov-v-yadre-linux","title":{"rendered":"Kollisionen bei verk\u00fcrzten Commit-IDs im Linux-Kernel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Kees Cook, ehemaliger Chief System Administrator von kernel.org und Leiter des Ubuntu Security Teams, hat die M\u00f6glichkeit demonstriert, einen Commit mit einer gek\u00fcrzten Kennung zu erstellen, die mit einem bereits in den Linux-Kernel hinzugef\u00fcgten Commit \u00fcbereinstimmt. Dieses Experiment wurde als Nachweis f\u00fcr die Sinnhaftigkeit der Einf\u00fchrung von 16-stelligen gek\u00fcrzten Commit-Identifikatoren im Linux-Kernel durchgef\u00fchrt, die zuvor in der Mailingliste der Kernel-Entwickler diskutiert, aber von Linus Torvalds nicht genehmigt wurden. <\/p>\n
Gek\u00fcrzte Commit-Identifikatoren entstehen durch die Verwendung der ersten 12 Zeichen des SHA-1-Hashes (48 Bit aus 160 Bit). Da die Anzahl der im Kernel identifizierten Objekte, die \u00fcber den SHA-1-Hash identifiziert werden, 13 Millionen \u00fcberschreitet, ist es nur eine Frage der Zeit, bis Kollisionen bei der Verwendung von 12-stelligen Pr\u00e4fixen auftreten. Beispielsweise werden bereits genutzte Objekte im Kernel gezeigt, die sich durch ihre 11-stelligen Identifikatoren \u00fcberschneiden. Zudem wird erw\u00e4hnt, dass bereits im Oktober Kollisionen bei 12-stelligen Identifikatoren festgestellt wurden, bevor der Patch mit dem Tool checkpatch gesendet wurde. <\/p>\n
Verk\u00fcrzte Identifikatoren werden verwendet, um kurze Links zu Commits zu ver\u00f6ffentlichen und werden auch beim Senden von \u00c4nderungen im Tag \u201eFixes\u201c als Verweis auf den Commit angegeben, in dem das Problem im gesendeten Patch behoben wurde (z. B. \u201eFixes: e21d2170f366\u201c). Das Auftreten von Kollisionen, bei denen mehrere verschiedene \u00c4nderungen mit einem einzigen verk\u00fcrzten Identifikator verkn\u00fcpft sind, kann die Funktion von Werkzeugen zur Analyse und \u00dcberpr\u00fcfung von \u00c4nderungen beeintr\u00e4chtigen, die den Inhalt der Tags \u201eFixes\u201c ber\u00fccksichtigen. Diese Tags werden beispielsweise im Handler check_fixes ber\u00fccksichtigt, der im Branch linux-next verwendet wird, sowie in Skripten zur Analyse von Sicherheitsfixes und zur Verfolgung des Lebenszyklus von Patches. <\/p>\n
Linus Torvalds \u00e4u\u00dferte sich skeptisch zu dem Vorschlag, die minimale Gr\u00f6\u00dfe der verk\u00fcrzten Identifikatoren zu erh\u00f6hen, da die tats\u00e4chliche Anzahl der Commits im Repository deutlich geringer ist als die Anzahl der Objekte (etwa 1\/8). Wahrscheinlich werden zuf\u00e4llige \u00dcberschneidungen nur zwischen einem Commit und einem Objekt eines anderen Typs (zum Beispiel einem Blob oder einem Branch) auftreten. Seiner Meinung nach sind verk\u00fcrzte Identifikatoren gerade daf\u00fcr gedacht, anschaulich, leserlich und leicht zitierbar zu sein, und es gibt derzeit keine objektiven Gr\u00fcnde, ihre Gr\u00f6\u00dfe zu erh\u00f6hen. <\/p>\n
Einer der Entwickler schlug vor, die Gr\u00f6\u00dfe zu reduzieren, indem die Anzahl der signifikanten Bits erh\u00f6ht wird, wobei ein neues Format auf der Basis von Base36-Codierung (Zeichen 0-9a-z) anstelle von hexadezimalen Ziffern verwendet wird. Linus ist der Meinung, dass eine solche \u00c4nderung mehr Probleme schaffen als l\u00f6sen w\u00fcrde. Zum Beispiel m\u00fcsste die Unterst\u00fctzung f\u00fcr das neue Format in bestehende Utilities integriert und ein Formatbezeichner eingef\u00fchrt werden, um zwischen dem alten und dem neuen Format zu unterscheiden. <\/p>\n
Um zu demonstrieren, dass das Problem mit verk\u00fcrzten IDs nicht nur theoretisch ist und dessen L\u00f6sung nicht aufgeschoben werden sollte, hat Case Cook eine \u00c4nderung der Kern-Dokumentation formuliert, deren verk\u00fcrzte ID (1da177e4c3f4) mit der ID des Commits zur Erstellung des Kern-Branches 2.6.12-rc2 \u00fcbereinstimmte. Die Kollision konnte in 6 Stunden Berechnungen auf einem System mit einer NVIDIA GeForce RTX 3080 gefunden werden. <\/p>\n
Die Auswahl erfolgte mit dem Werkzeug lucky-commit \u2014 es wurden zuf\u00e4llige Leerzeichen in den Text des Ziel-Patches eingef\u00fcgt, bis der 12-stellige SHA-1-Pr\u00e4fix mit den bereits vorhandenen Pr\u00e4fixen von Commits im Kernel \u00fcbereinstimmte. Laut Case stellen nicht so sehr zuf\u00e4llige \u00dcberschneidungen ein Problem dar, sondern die M\u00f6glichkeit, verk\u00fcrzte Identifikatoren zu b\u00f6swilligen Zwecken zu manipulieren, zum Beispiel um einige \u00dcberpr\u00fcfungen zu umgehen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"