Noen dager siden en uvanlig hendelse inntraff, som rystet Linux-kjernesamfunnet, og det er Linus Torvalds beordret umiddelbar suspensjon av Kees Cooks konto på kernel.org., etter å ha oppdaget eksistensen av manipulerte commits i denne utviklerens Git-repository.
Kees Cook, anerkjent for sitt lederskap i Ubuntus sikkerhetsteam og for å vedlikeholde mer enn et dusin sikkerhetsrelaterte delsystemer i kjernen, ble midlertidig utestengt fra å sende inn endringer mens fakta ble avklart.
Endring av forfatterskap og signaturer i Kees Cook-arkivet
Problemet oppsto som følge av en forespørsel om endring av innlemmelse.s til kjernegrenen 6.16, der Linus identifiserte referanser til et arkiv som inneholdt commits manipulert med navnet hans som forfatter og bekrefter, til tross for at han ikke hadde gjort dem selv. Et av de mest alvorlige eksemplene var eksistensen av en duplikat-commit, identisk i innhold med originalen, men med en annen SHA1-hash, som feilaktig inkluderte Linus Torvalds' signatur.
Disse endringene kunne ikke bare tilskrives en tilfeldig feill under en git rebase-operasjon, siden de involverte massive modifikasjoner av sensitiv informasjon, inkludert over 6.000 omskrevne commits, hvorav 330 hadde Linus' navn som forfatter.
Torvalds' reaksjon: mistanker om bevisst manipulasjon
Linus Torvalds la ikke skjul på bekymringen sin. og beskrev hendelsene som potensielt ondsinnede:
«Én eller to omskrivinger kan være en feil. Men tusenvis av dem, mange med min forfalskede signatur, er det ikke», erklærte han.
Gitt omfanget av endringene og risikoen for integriteten til det offisielle kjernetreet, Torvalds spurte Konstantin Rjabitsev, kernel.org infrastrukturadministrator, qå blokkere Kees Cooks tilgang inntil situasjonen er avklart.
Som svar, Kees Cook forklarte at han nylig hadde hatt tekniske problemer som kunne ha utløst hendelsen. Han sa, SSD-disken din opplevde feil under kopieringsoperasjoner, noe som forårsaket korrupsjon i flere repositorier. Etter disse feilene forsøkte han å gjenopprette tilstanden til repositoriet sitt ved hjelp av git rebase og diverse automatiseringsverktøy.
Disse operasjonene ble imidlertid utført på kritiske grener, som for-next/hardening og for-linus/hardening, som førte til en utilsiktet endring av depothistorikken, inkludert endringen i forfatterskapet til commits. Til tross for forklaringen sin, var Linus skeptisk.:
«Jeg forstår ikke hvordan en utilsiktet forbikjøring kan skje, langt mindre med dette antallet kupéer.»
Den virkelige synderen: git-filter-repo og b4-trailere
I en senere melding, Kees Cook identifiserte den sannsynlige kilden til feilen: kombinert bruk av to verktøy, git-filter-repo og b4 trailere, som manipulerer commit-historikken og trailere (tagger som Signed-off-by:) i commits.
Denne feilaktige bruken av fortjenesten ville ha forårsaket automatisk omskriving av tusenvis av commits, inkludert å erstatte forfatteren med standardverdien (i dette tilfellet Linus Torvalds), uten at Kees la merke til feilen den gangenKonstantin Ryabitsev, forfatteren av b4-verktøyet, bekreftet denne teorien og hevdet at Cook ikke hadde noen ondsinnet hensikt. Systemet genererte faktisk allerede advarsler som ble ignorert.
Etter at situasjonen ble avklart, ble Kees Cooks tilgang til kernel.org gjenopprettet. Som et forebyggende tiltak har det blitt annonsert at verktøyet b4 vil inkludere en ny sikkerhetskontroll, Dette vil forhindre modifisering av commits hvis forfatterskap ikke samsvarer med den nåværende brukerens identitet fra nå av. Dette er ment å forhindre lignende feil og beskytte integriteten til kjernekildekoden.
Kees lovet på sin side å gjenskape de berørte grenene. fra individuelle patcher og analysere trinnene som førte til feilen i dybden. Selv om Hendelsen har satt press på forholdet innad i laget kjerneutvikling har også fremhevet viktigheten av å bruke verktøy for historikkomskriving med forsiktighet, spesielt i prosjekter så kritiske som Linux-kjernen.
Til slutt er det verdt å nevne at denne hendelsen mellom Linus Torvalds og Kees Cook tjener som en advarsel om farene ved å manipulere commit-historikk, og at takket være den raske inngripen fra de ansvarlige for kernel.org og gjennomsiktigheten i prosessen, situasjonen er brakt under kontroll.
Til slutt, hvis du er interessert i å lære mer om det, kan du sjekke detaljene i det følgende link.