For et par dage siden indtraf en usædvanlig hændelse , der rystede Linux-kernefællesskabet: Linus Torvalds beordrede øjeblikkelig blokering af Kees Cooks konto på kernel.org efter at have opdaget manipulerede commits i denne udviklers Git-repository.
Kees Cook, der er anerkendt for sit lederskab i Ubuntus sikkerhedsteam og for at vedligeholde mere end et dusin undersystemer relateret til kernesikkerhed, blev midlertidigt udelukket fra at indsende ændringer, mens fakta blev afklaret.
Ændring af forfatterskab og signaturer i Kees Cook-arkivet
Problemet opstod som følge af en anmodning om at inkorporere ændringer i 6.16-kernegrenen, hvor Linus identificerede referencer til et arkiv, der indeholdt manipulerede commits med hans navn angivet som forfatter og bekræfter, på trods af at han ikke selv havde foretaget dem. Et af de mest alvorlige eksempler var eksistensen af en duplikat-commit, identisk i indhold med originalen, men med en anden SHA1-hash, som fejlagtigt inkluderede Linus Torvalds' signatur.
Disse ændringer kunne ikke blot tilskrives en utilsigtet fejl under en git-rebase-operation, da de involverede en massiv ændring af følsomme oplysninger, herunder mere end 6.000 omskrevne commits, hvoraf 330 bar Linus' navn som forfatter.
Torvalds' reaktion: mistanke om bevidst manipulation
Linus Torvalds skjulte ikke sin bekymring og beskrev begivenhederne som potentielt ondsindede:
"En eller to omskrivninger kunne være en fejl. Men tusindvis af dem, mange med min forfalskede underskrift, er det ikke," erklærede han.
I betragtning af ændringernes omfang og risikoen for integriteten af det officielle kernetræ bad Torvalds Konstantin Ryabitsev, administrator af kernel.org-infrastrukturen, om at blokere Kees Cooks adgang, indtil situationen var afklaret.
Som svar forklarede Kees Cook, at han for nylig havde oplevet tekniske problemer , der muligvis havde udløst hændelsen. Han oplyste, at hans SSD ikke fungerede korrekt under kopiering, hvilket havde resulteret i korruption i flere repositories. Efter disse fejl forsøgte han at gendanne tilstanden af sit repository ved hjælp af `git rebase` og forskellige automatiseringsværktøjer.
Disse operationer blev dog udført på kritiske grene , såsom for-next/hardening og for-linus/hardening, hvilket førte til en utilsigtet ændring af arkivets historik, herunder ændringer i commit-forfatterskabet. Trods sin forklaring forblev Linus skeptisk.
"Jeg forstår ikke, hvordan en utilsigtet overhaling kan ske, og slet ikke med så mange omkørselsændringer."
Den virkelige synder: git-filter-repo og b4 trailere
I en efterfølgende besked identificerede Kees Cook den sandsynlige kilde til fejlen : den kombinerede brug af to værktøjer, git-filter-repo og b4 trailers, som manipulerer commit-historikken og trailere (mærkater som Signed-off-by:) i commits.
Denne misbrug af værktøjerne ville have forårsaget automatisk omskrivning af tusindvis af commits , inklusive erstatning af forfatteren med standardværdien (i dette tilfælde Linus Torvalds), uden at Kees bemærkede fejlen på det tidspunkt . Konstantin Ryabitsev, forfatteren af b4-værktøjet, bekræftede denne teori og hævdede, at der ikke var nogen ondsindet hensigt fra Cooks side. Faktisk genererede systemet allerede advarsler, der blev ignoreret.
Efter at situationen var blevet afklaret, blev Kees Cooks adgang til kernel.org genoprettet. Som en forebyggende foranstaltning blev det annonceret, at b4-værktøjet vil inkludere en ny sikkerhedskontrol, som vil forhindre ændring af commits, hvis forfatterskab ikke matcher den nuværende brugers identitet. Dette har til formål at forhindre lignende fejl og beskytte integriteten af kernelkildekoden.
Kees lovede på sin side at genskabe de berørte grene fra individuelle patches og grundigt analysere de trin, der førte til fejlen. Selvom hændelsen har belastet forholdet inden for kerneludviklingsteamet, har den også fremhævet vigtigheden af at bruge historikomskrivningsværktøjer med forsigtighed, især i projekter så kritiske som Linux-kernen.
Endelig er det værd at nævne, at denne hændelse mellem Linus Torvalds og Kees Cook tjener som en advarsel om farerne ved at manipulere commit-historikken, og at situationen er blevet bragt under kontrol takket være kernel.org-teamets hurtige indgriben og processens gennemsigtighed.
Endelig, hvis du er interesseret i at lære mere, kan du finde detaljerne på følgende link.