Hackerindbrud på Kernel.org: Linux-kernen skal dobbelttjekkes

Versionsstyringsværktøjet Git burde have beskyttet Linux-kernen mod uautoriserede ændringer, men kernen får alligevel et ekstra tjek efter hackere havde fuld adgang til Kernel.org.

Webstedet Kernel.org, som huser Linux-kernen, blev i løbet af august udsat for et hackerindbrud, hvor ukendte personer fik root-adgang til en af serverne. Det oplyser Kernel.org.

Det mest værdifulde indhold på Kernel.org, selve Linux-kernen, ser dog ud til at være intakt, men administratorerne vil alligevel gennemgå programkoden for at sikre, at der ikke er sket uautoriserede ændringer.

Udviklingen på Linux-kernen styres ved hjælp af versionsstyringsværktøjet Git, som skaber en SHA-1 hashværdi for alle 40.000 filer, der udgør kernen. Det betyder, at det ikke skulle være muligt at ændre i en fil, uden det vil blive bemærket af en af de mange udviklere, der arbejder på hver fil.

Hackerne fik formentligt adgang til Kernel.org ved at opsnappe et brugerlogin, hvorefter det var muligt at eskalere rettighederne til root-adgang og dermed fuld adgang til systemet. Det blev blandt andet brugt til at ændre nogle filer til OpenSSH, som bruges til at give brugerne sikker fjernadgang til serverne.

Derfor får alle 448 brugere nu nye SSH-nøgler og kodeord, og alle servere bliver geninstalleret. Samtidig vil udviklerne gennemgå sikkerhedsprocedurerne for at se på, hvor sikkerheden kan forbedres for at undgå en gentagelse.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Ferré Jensen

Det er klart en god joke, at selveste kammeret med den hellige gral bliver hacket.

Og når det så er sket, er det tillidsvækkende, at indbrudet er opdaget og offentliggjort - og at der tages hånd om verifikation af kildekoden.

  • 6
  • 1
Peter Mogensen

Fik de også hacket Linus' laptop?

Mht. til konsekvenser for brugere, så virker det her nu som et non-event. Det burde være en smal sag at verificere koden imod en kendt god kopi i et distribueret versionsstyringssystem som Git.

  • 0
  • 1
Thomas Jensen

Non-event? Synes du ikke det er betænkeligt, at de "fik formentligt adgang til Kernel.org ved at opsnappe et brugerlogin, hvorefter det var muligt at eskalere rettighederne til root-adgang og dermed fuld adgang til systemet"?

  • 3
  • 0
Martin Bøgelund

Jeg er ikke GIT-kyndig. Kan I forklare mig hvordan det sikres at oplysningerne i GIT er korrekte, hvis angriberne har haft root-adgang i et ukendt tidsrum?

Som det antydes i artiklen, kan SHA-1 hashværdien bruges til at verificere indholdet af filerne:

http://www.linuxjournal.com/content/git-revision-control-perfected

To put this into perspective, the example SHA1 listed above happens to be the ID of the first commit of the Linux kernel into a Git repository by Linus Torvalds in 2005 (2.6.12-rc2). This is a lot more useful than some arbitrary revision number with no real meaning. Nothing except that commit ever will have the same ID, and you can use those 40 characters to verify the data in every file throughout that version of Linux. Pretty cool, huh?

  • 3
  • 0
Per Sikker Hansen

Det er jo dybt rystende så ulødig journalistikken på v2 efterhånden er blevet.

Versionsstyringsværktøjet Git burde have beskyttet Linux-kernen mod uautoriserede ændringer,

Det insinuerer meget belejligt at det ikke er tilfældet, hvor virkeligheden, som det nævnes i den følgende sætning, er at man reelt ikke ved om det er tilfældet. Det er misvisende og ulødig sensationsjournalistik.

Virkeligheden er at man med ret stor sikkerhed kan vide ud fra SHA-1 værdien, at der ikke er blevet tampered med koden, men at man alligevel er sin opgave voksen nok til at lave et manuelt dobbelttjek.

Artiklens ordlyd får det til at fremstå som at SHA-1-tjekket har svigtet og at man derfor er tvunget til i panik at lede al koden igennem efter mulige embeddede nasties.

Hvorfor er det, jeg stadig kommer tilbage til v2?

  • 5
  • 2
Glenn Dufke

Version2's læsere havde været bedre tjent udelukkende med en henvisning til original artiklen. Jeg gad godt vide om jounalisten er blevet beordret til at stå på hovedt og indtage kaffe mens han skulle skrive artiklen. Magen til misvisende information skal man lede længe efter.

Mindre Ekstrabladet og mere faktuelt tak!

  • 3
  • 2
Peter Mogensen

Non-event? Synes du ikke det er betænkeligt, at de "fik formentligt adgang til Kernel.org ved at opsnappe et brugerlogin, hvorefter det var muligt at eskalere rettighederne til root-adgang og dermed fuld adgang til systemet"?

Jo, men det er et andet emne end Linux-kildetekstens integritet. Det havde været betænkeligt uanset hvilken installation, der havde gjort det muligt at eskalere rettigheder. Nu har jeg ikke læst hvordan det så foregik, men det behøves ikke nødvendigvis have det mindste med Linux at gøre. Det kunne ske via et hvilket som helst user-space program på maskinen, der kører med root rettigheder. Så hvad angår Linux kildtekstens integritet, så forekommer det mig stadig som et non-event. - som andre nævner ligger bunkevis af good-guys (og især Linux) inde med den beviseligt rigtige version af kildeteksten og SHA1-hashene til at verificere hvert enkelt commit.

  • 2
  • 0
Thomas Jensen

Det kunne ske via et hvilket som helst user-space program på maskinen, der kører med root rettigheder.

Okay, jeg ved godt din kommentar om "non-event" gik på kildekoden, og her er jeg enig med dig - intet problem i den virkelige verden!

Det jeg hæfter mig ved er i artiklen er "muligt at eskalere rettighederne". Man starter ud med at have et bruger-login og ender med root rettigheder. Hvordan eskalerer man lige rettigheder fra user til root?

Jeg er ikke helt sikker på jeg forstår hvad du mener med "Det kunne ske via et hvilket som helst user-space program på maskinen, der kører med root rettigheder". Hvad er "det"? At man eskalerer sine rettigheder? Næppe, for kræver det ikke root-rettigheder hos brugeren, at køre et program der kører med root-rettigheder?

  • 0
  • 0
Log ind eller Opret konto for at kommentere