Kees Cook, ehemaliger Hauptsystemadministrator von kernel.org und Leiter des Ubuntu Security Teams, hat die Möglichkeit demonstriert, einen Commit zu erstellen, dessen gekürzte ID mit einem vorher in den Linux-Kernel eingefügten Commit übereinstimmt. Das Experiment wurde als Bestätigung der Zweckmäßigkeit des Wechsels zu 16-stelligen gekürzten Commit-IDs im Linux-Kernel durchgeführt, was zuvor in der Mailingliste der Kernel-Entwickler diskutiert, aber nicht von Linus Torvalds genehmigt wurde.
Gekürzte 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 überschritten hat, war das Auftreten von Kollisionen bei der Verwendung des 12-stelligen Präfixes nur eine Frage der Zeit. Als Beispiel werden bereits in den Kernel eingefügte Objekte gezeigt, die sich durch ihre 11-stelligen IDs überschneiden. Zudem wird erwähnt, dass bereits im Oktober Überschneidungen bei 12-stelligen IDs festgestellt wurden, aber vor dem Versand des Patches durch das Tool checkpatch identifiziert wurden.
Gekürzte IDs werden verwendet, um kurze Links zu Commits zu veröffentlichen, und werden auch beim Einfügen von Änderungen im Tag „Fixes“ als Verweis auf den Commit angegeben, in dem das Problem im gesendeten Patch behoben wurde (zum Beispiel „Fixes: e21d2170f366“). Das Auftreten von Kollisionen, bei denen mehrere verschiedene Änderungen mit einer einzigen gekürzten ID verknüpft sind, kann die Funktionalität von Tools zur Analyse und Überprüfung von Änderungen beeinträchtigen, die den Inhalt der „Fixes“-Tags berücksichtigen. So werden diese Tags im Handler check_fixes berücksichtigt, der im linux-next-Branch verwendet wird, sowie in Skripten zur Analyse von Sicherheitskorrekturen und zur Verfolgung des Lebenszyklus von Patches.
Linus Torvalds äußerte sich skeptisch zu dem Vorschlag, die minimale Größe der verkürzten Identifikatoren zu erhöhen, da die tatsächliche Anzahl der Commits im Repository deutlich geringer ist als die der Objekte (etwa 1/8). Wahrscheinlich werden, falls zufällige Überlappungen auftreten, diese zwischen einem Commit und einem Objekt eines anderen Typs liegen (zum Beispiel einem Blob oder einem Branch). Seiner Meinung nach sind verkürzte Identifikatoren gerade verkürzt, um anschaulich, lesbar und leicht zitierbar zu sein, und es gibt derzeit keine objektiven Gründe, ihre Größe zu erhöhen.
Einer der Entwickler schlug vor, die Größe zu reduzieren, indem die Anzahl der signifikanten Bits erhöht 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 Änderung mehr Probleme schaffen wird, als sie löst. Zum Beispiel müsste Unterstützung für das neue Format in die bestehenden Tools integriert und ein Format-Identifikator eingeführt werden, um alte und neue Formate unterscheiden zu können.
Um zu demonstrieren, dass das Problem mit verkürzten Identifikatoren kein theoretisches ist und die Lösung nicht aufgeschoben werden sollte, hat Kees Cook eine Änderung der Kernel-Dokumentation formuliert, deren verkürzter Identifikator (1da177e4c3f4) mit der Identifikation des Commits zur Erstellung des Kernels 2.6.12-rc2 übereinstimmte. Es gelang, die Kollision innerhalb von 6 Stunden Berechnungen auf einem System mit einer NVIDIA GeForce RTX 3080 zu finden.
Die Ermittlung wurde mit dem Werkzeug lucky-commit durchgeführt – zufällige Leerzeichen wurden in den Text des Ziel-Patches hinzugefügt, bis der 12-stellige SHA-1-Präfix mit bereits vorhandenen Präfixen der Commits im Kernel übereinstimmte. Laut Kees stellt nicht so sehr die Möglichkeit der zufälligen Überlappungen ein Problem dar, sondern die Möglichkeit der Manipulation mit verkürzten Identifikatoren zu böswilligen Zwecken, beispielsweise um bestimmte Prüfungen zu umgehen.
Quelle: opennet.ru
