For noen dager siden inntraff en uvanlig hendelse som rystet Linux-kjernemiljøet: Linus Torvalds beordret umiddelbar blokkering av Kees Cooks konto på kernel.org etter å ha oppdaget manipulerte commits i denne utviklerens Git-repository.
Kees Cook, anerkjent for sitt lederskap i Ubuntus sikkerhetsteam og for å vedlikeholde mer enn et dusin delsystemer relatert til kjernesikkerhet, ble midlertidig utestengt fra å sende inn endringer mens fakta ble avklart.
Endring av forfatterskap og signaturer i Kees Cook-arkivet
Problemet oppsto fra en forespørsel om å innlemme endringer i kjernegrenen i 6.16, der Linus identifiserte referanser til et arkiv som inneholdt manipulerte commits med navnet hans oppført som forfatter og bekrefter, til tross for at han ikke hadde gjort dem. 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 utilsiktet feil under en git-rebase-operasjon, ettersom de involverte massiv modifisering av sensitiv informasjon, inkludert mer enn 6.000 omskrevne commits, hvorav 330 bar 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, ba Torvalds Konstantin Ryabitsev, administrator for kernel.org-infrastrukturen, om å blokkere Kees Cooks tilgang inntil situasjonen var avklart.
Som svar forklarte Kees Cook at han nylig hadde opplevd tekniske problemer som kan ha utløst hendelsen. Han oppga at SSD-en hans ikke fungerte som den skulle under kopieringsoperasjoner, noe som hadde resultert i 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, noe som førte til en utilsiktet modifisering av depotets historikk, inkludert endringer i commit-forfatterskapet. Til tross for forklaringen sin, forble 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 påfølgende melding identifiserte Kees Cook den sannsynlige kilden til feilen : den kombinerte bruken av to verktøy, git-filter-repo og b4 trailers, som manipulerer commit-historikken og trailere (etiketter som Signed-off-by:) i commits.
Denne misbruken av verktøyene ville ha forårsaket automatisk omskriving av tusenvis av commits , inkludert erstatning av forfatteren med standardverdien (i dette tilfellet Linus Torvalds), uten at Kees la merke til feilen på det tidspunktet . Konstantin Ryabitsev, forfatteren av b4-verktøyet, bekreftet denne teorien og hevdet at det ikke var noen ondsinnet hensikt fra Cooks side. Faktisk genererte systemet allerede advarsler som ble ignorert.
Etter at situasjonen ble avklart, ble Kees Cooks tilgang til kernel.org gjenopprettet. Som et forebyggende tiltak ble det annonsert at b4-verktøyet vil inkludere en ny sikkerhetskontroll, som vil forhindre endring av commits hvis forfatterskap ikke samsvarer med den nåværende brukerens identitet. Dette har som mål å forhindre lignende feil og beskytte integriteten til kjernekildekoden.
Kees lovet på sin side å gjenskape de berørte grenene fra individuelle oppdateringer og grundig analysere trinnene som førte til feilen. Selv om hendelsen har anstrengt forholdet innenfor kjerneutviklingsteamet, har den 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-historikken, og at takket være kernel.org-teamets raske inngripen og prosessens åpenhet, har situasjonen blitt brakt under kontroll.
Til slutt, hvis du er interessert i å lære mer, kan du finne detaljene på følgende lenke.