Några dagar sen en ovanlig händelse inträffade, vilket skakade Linuxkärngemenskapen, och det är Linus Torvalds beordrade omedelbar avstängning av Kees Cooks konto på kernel.org., efter att ha upptäckt förekomsten av manipulerade commits i den här utvecklarens Git-arkiv.
Kees Cook, erkänd för sitt ledarskap i Ubuntus säkerhetsteam och för att underhålla mer än ett dussin säkerhetsrelaterade delsystem i kärnan, förbjöds tillfälligt att skicka in ändringar medan fakta klargjordes.
Ändring av författarskap och signaturer i Kees Cook-arkivet
Problemet uppstod på grund av en begäran om ändring av införlivande.s till kärngrenen 6.16, där Linus identifierade referenser till ett arkiv som innehöll commits manipulerade med hans namn som författare och bekräftare, trots att han inte själv gjort dem. Ett av de allvarligaste exemplen var förekomsten av en duplicerad commit, identisk till innehållet med originalet men med en annan SHA1-hash, som felaktigt inkluderade Linus Torvalds signatur.
Dessa förändringar kunde inte enbart tillskrivas ett oavsiktligt fell under en git-rebase-operation, eftersom de innebar omfattande modifieringar av känslig information, inklusive över 6.000 330 omskrivna commits, varav XNUMX hade Linus namn som författare.
Torvalds reaktion: misstankar om avsiktlig manipulation
Linus Torvalds dolde inte sin oro och beskrev händelserna som potentiellt skadliga:
"En eller två omskrivningar kan vara ett misstag. Men tusentals av dem, många med min förfalskade signatur, är det inte", förklarade han.
Med tanke på förändringarnas omfattning och risken för integriteten hos det officiella kärnträdet, Torvalds frågade Konstantin Rjabitsev, kernel.org infrastrukturadministratör, qatt blockera Kees Cooks åtkomst tills situationen är klarlagd.
Som svar, Kees Cook förklarade att han nyligen hade haft tekniska problem som kunde ha utlöst händelsen. Han sa, Din SSD-enhet upplevde fel under kopiering, vilket orsakade skada i flera repositorier. Efter dessa fel försökte han återställa repositoriets tillstånd med hjälp av git rebase och olika automatiseringsverktyg.
Dessa operationer utfördes dock på kritiska grenar, såsom for-next/hardening och for-linus/hardening, vilket ledde till en oavsiktlig modifiering av arkivets historik, inklusive ändringen av författarskapet till commits. Trots sin förklaring var Linus skeptisk.:
"Jag förstår inte hur en oavsiktlig omkörning kan ske, än mindre med den här mängden växlingar."
Den verkliga boven: git-filter-repo och b4-trailers
I ett senare meddelande, Kees Cook identifierade den troliga källan till feletkombinerad användning av två verktyg, git-filter-repo och b4 trailers, som manipulerar commit-historiken och trailers (taggar som Signed-off-by:) i commits.
Denna felaktiga användning av vinsterna skulle ha orsakat automatisk omskrivning av tusentals commits, inklusive att ersätta författaren med standardvärdet (i det här fallet Linus Torvalds), utan att Kees märkte felet dåKonstantin Ryabitsev, författaren till b4-verktyget, bekräftade denna teori och hävdade att det inte fanns någon ond avsikt från Cooks sida. Faktum är att systemet redan genererade varningar som ignorerades.
Efter att situationen klarnat återställdes Kees Cooks åtkomst till kernel.org. Som en förebyggande åtgärd har det tillkännagivits att verktyget b4 kommer att inkludera en ny säkerhetskontroll, Detta kommer att förhindra modifiering av commits vars författarskap inte matchar den nuvarande användarens identitet från och med nu. Detta är avsett att förhindra liknande fel och skydda integriteten hos kärnkällkoden.
Kees lovade å sin sida att återskapa de drabbade grenarna. från enskilda patchar och analysera på djupet de steg som ledde till felet. Även om Händelsen har spänt relationerna inom laget kärnutveckling, har också belyst vikten av att använda verktyg för historikomskrivning med försiktighet, särskilt i projekt så kritiska som Linuxkärnan.
Slutligen är det värt att nämna att denna incident mellan Linus Torvalds och Kees Cook tjänar som en varning om farorna med att manipulera commit-historik och att tack vare det snabba ingripandet från de ansvariga för kernel.org och processens transparens, situationen har fått kontroll.
Slutligen, om du är intresserad av att lära dig mer om det, kan du se detaljerna i följande länken.