Kees Cook, a kernel.org korábbi fő rendszergazdája és az Ubuntu Security Team vezetője bemutatta, hogy lehetővé válik olyan commit létrehozása, amelynek rövidített azonosítója megegyezik egy korábban a Linux kernelhez hozzáadott commit azonosítójával. A kísérlet célja annak megerősítése volt, hogy érdemes lenne áttérni a 16 karakteres rövidített commit azonosítókra a Linux kernelben, amelyről korábban a kernel fejlesztői levelezőlistáján beszéltek, de Linus Torvalds nem támogatta.
A rövidített commit azonosítók a SHA-1 hash első 12 karakterének megőrzésével keletkeznek (48 bit a 160 bitből). Mivel a kernelben SHA-1 hash által azonosítható objektumok száma meghaladta a 13 milliót, a 12 karakteres prefix használata során ütközések előfordulása már csak idő kérdése volt. Példaként már a kernelbe hozzáadott objektumokat mutatták be, amelyek 11 karakteres azonosítóik révén átfedésben vannak. Ezen kívül említésre került, hogy a 12 karakteres azonosítók átfedésére már októberben is volt példa, de a patch elküldése előtt a checkpatch segédprogram már észlelte ezt.
A rövidített azonosítók a commitokra mutató rövid hivatkozások közzétételénél használatosak, valamint a "Fixes" címkénél történő változtatások küldésénél is megjelennek, mint a commit hivatkozása, amely probléma a beküldött patchben meg lett oldva (például: "Fixes: e21d2170f366"). Az ütközések, ahol több különböző változtatás egy rövidített azonosítóhoz kapcsolódik, megzavarhatják a változtatások elemzéséért és ellenőrzéséért felelős eszközök működését, figyelembe véve a "Fixes" címkék tartalmát. Például az ilyen címkék szerepelnek a linux-next ágon alkalmazott check_fixes feldolgozóban, valamint a sebezhetőségek javításáról és a patch-ek életciklusának nyomon követéséről szóló elemző skriptekben is.
Linus Torvalds szkeptikusan viszonyult ahhoz a javaslathoz, hogy növeljék a rövidített azonosítók minimális méretét, mivel a tárolóban található commitok száma lényegesen kevesebb, mint a tárgyak száma (körülbelül 1/8). Valószínű, hogy ha véletlen ütközések előfordulnak, azok egy commit és egy más típusú objektum (például blob vagy ág) között fognak történni. Véleménye szerint a rövidített azonosítóknak éppen az a szerepük, hogy átláthatóak, olvashatóak és könnyen idézhetőek legyenek, és a méretük növelésének objektív előfeltételei egyelőre nincsenek.
Az egyik fejlesztő azt javasolta, hogy a méret csökkentése érdekében növeljék a jelentős bitek számát, új formátumot alkalmazva a Base36 kódolás (0-9, a-z karakterek) alapján a hexadecimális számjegyek helyett. Linus véleménye szerint egy ilyen változtatás több problémát fog okozni, mint amennyit megold. Például új formátum támogatását kell hozzáadni a meglévő eszközökhöz, és formátum azonosítót kell bevezetni a régi és új formátum megkülönböztetése érdekében.
A probléma szemléltetésére, miszerint a rövidített azonosítók problémája nem elméleti, és megoldása nem késlekedhet, Kees Cook dokumentációs módosítást kezdeményezett, amelynek rövidített azonosítója (1da177e4c3f4) megegyezett a 2.6.12-rc2 kernel ág létrehozásához tartozó commit azonosítójával. Az ütközést 6 óra számítás segítségével sikerült megtalálni egy NVIDIA GeForce RTX 3080 GPU-val rendelkező rendszeren.
A keresést a lucky-commit eszközkészlettel hajtották végre, a célzott patch szövegéhez véletlenszerű szóközöket adtak, amíg a 12 karakteres SHA-1 előtag meg nem egyezett a kernelben lévő commitok már meglévő előtagjaival. Kees véleménye szerint a problémát nem annyira a véletlenszerű ütközések jelentik, hanem a rövidített azonosítók manipulálásának lehetősége rosszindulatú céllal, például valamilyen ellenőrzés megkerülésére.
Forrás: opennet.ru
