{"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\/news\/kollizii-v-sokrashhyonnyh-identifikatorah-kommitov-v-yadre-linux","title":{"rendered":"Kollisionen bei den verk\u00fcrzten Identifikatoren von Commits im Linux-Kernel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Kees Cook, ehemaliger Hauptsystemadministrator von kernel.org und Leiter des Ubuntu Security Teams, hat die M\u00f6glichkeit demonstriert, einen Commit zu erstellen, dessen gek\u00fcrzte ID mit einem vorher in den Linux-Kernel eingef\u00fcgten Commit \u00fcbereinstimmt. Das Experiment wurde als Best\u00e4tigung der Zweckm\u00e4\u00dfigkeit des Wechsels zu 16-stelligen gek\u00fcrzten Commit-IDs im Linux-Kernel durchgef\u00fchrt, was zuvor in der Mailingliste der Kernel-Entwickler diskutiert, aber nicht von Linus Torvalds genehmigt wurde. <\/p>\n
Gek\u00fcrzte Commit-IDs werden gebildet, indem die ersten 12 Zeichen des SHA-1-Hashes (48 Bit von 160 Bit) beibehalten werden. Da die Anzahl der im Kernel identifizierbaren Objekte durch den SHA-1-Hash 13 Millionen \u00fcberschritten hat, war das Auftreten von Kollisionen bei der Verwendung des 12-stelligen Pr\u00e4fixes nur eine Frage der Zeit. Als Beispiel werden bereits in den Kernel eingef\u00fcgte Objekte gezeigt, die sich durch ihre 11-stelligen IDs \u00fcberschneiden. Zudem wird erw\u00e4hnt, dass bereits im Oktober \u00dcberschneidungen bei 12-stelligen IDs festgestellt wurden, aber vor dem Versand des Patches durch das Tool checkpatch identifiziert wurden. <\/p>\n
Abgek\u00fcrzte Identifikatoren werden verwendet, wenn kurze Links zu Commits ver\u00f6ffentlicht werden, und sie werden auch beim Senden von \u00c4nderungen im Tag \u201eFixes\u201c angegeben, als Verweis auf den Commit, dessen Problem im gesendeten Patch behoben wurde (zum Beispiel \u201eFixes: e21d2170f366\u201c). Das Auftreten von Kollisionen, bei denen mehrere verschiedene \u00c4nderungen mit einem einzigen abgek\u00fcrzten Identifikator verkn\u00fcpft sind, kann dazu f\u00fchren, dass Analyse- und Pr\u00fcfwerkzeuge, die den Inhalt der Tags \u201eFixes\u201c ber\u00fccksichtigen, nicht mehr funktionieren. Zum Beispiel werden diese Tags im Handler check_fixes ber\u00fccksichtigt, der im Linux-next-Zweig verwendet wird, sowie in den Skripten zur Analyse von Sicherheitskorrekturen 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 der Objekte (etwa 1\/8). Wahrscheinlich werden, falls zuf\u00e4llige \u00dcberlappungen auftreten, diese zwischen einem Commit und einem Objekt eines anderen Typs liegen (zum Beispiel einem Blob oder einem Branch). Seiner Meinung nach sind verk\u00fcrzte Identifikatoren gerade verk\u00fcrzt, um anschaulich, lesbar 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, und zwar mit einem neuen Format basierend auf der Base36-Codierung (Zeichen 0-9a-z) anstelle von hexadezimalen Ziffern. Linus ist der Meinung, dass eine solche \u00c4nderung mehr Probleme schaffen wird, als sie l\u00f6st. Zum Beispiel m\u00fcsste Unterst\u00fctzung f\u00fcr das neue Format in die bestehenden Tools integriert und ein Format-Identifikator eingef\u00fchrt werden, um alte und neue Formate unterscheiden zu k\u00f6nnen. <\/p>\n
Um zu demonstrieren, dass das Problem mit verk\u00fcrzten Identifikatoren kein theoretisches ist und die L\u00f6sung nicht aufgeschoben werden sollte, hat Kees Cook eine \u00c4nderung der Kernel-Dokumentation formuliert, deren verk\u00fcrzter Identifikator (1da177e4c3f4) mit der Identifikation des Commits zur Erstellung des Kernels 2.6.12-rc2 \u00fcbereinstimmte. Es gelang, die Kollision innerhalb von 6 Stunden Berechnungen auf einem System mit einer NVIDIA GeForce RTX 3080 zu finden. <\/p>\n
Die Auswahl wurde mit dem Werkzeug lucky-commit durchgef\u00fchrt \u2013 zuf\u00e4llige Leerzeichen wurden dem Text des Ziel-Patches hinzugef\u00fcgt, bis der 12-stellige SHA-1-Pr\u00e4fix mit bereits im Kernel vorhandenen Commit-Pr\u00e4fixen \u00fcbereinstimmte. Laut Case stellt nicht so sehr die zuf\u00e4llige \u00dcberschneidung ein Problem dar, sondern die M\u00f6glichkeit, abgek\u00fcrzte Identifikatoren zu manipulierenden Zwecken zu verwenden, beispielsweise um bestimmte Pr\u00fcfungen zu umgehen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"