Når lynet slår ned

Jeg er til BSDcan i Ottawa og her sker altid et og andet spændende.

Første gang lynet virkelig slog ned her, var da vores Colin havde afsløret Intels "HyperThreading" som et enormt sikkerhedshul i forhold til krypto på multiuser systemer.

I år var det debian's selvmål der satte stemningen.

Godter vi os så ?

Nej.

Vi ryster naturligvis bedrevidende på hovedet mens vi skukker dybt, sådan er vi højrøvede og bedrevidende BSD'er.

Men vi gør det først, efter at have checket vores egen kildetekst, for den slags fejl kan også ske hos os.

phk

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Bjerregaard

@Jan Keller
Det er rigtigt, http://www.version2.dk/artikel/7271 er en udemærket summering. http://lwn.net/Articles/281901/ har interessante indlæg, hvis man interesserer sig for svagheder i community processer, samt det tekniske grundlag for entropi i kryptering, og hvordan statiske kodecheckere kan snydes af uortodokse metoder der bruges i denne sammenhæng.

Der er masser at blive klog på, og efterdønningerne af denne hændelse kommer nok til at rulle et stykke tid. Husk nu at alle nøgler genereret med openssl værktøjer på Debian (og distributioner afledt af debian) gennem de sidste par år, skal kasseres og regenereres! Disse nøgler kan være havnet på mange andre maskiner (og certifikater). Læs mere her: http://www.debian.org/security/2008/dsa-1576

  • 0
  • 0
Jan Keller Catalan

http://lwn.net/Articles/281901/ har interessante indlæg, hvis man interesserer sig for svagheder i community processer

Fin-fin, jeg tænkte bare på, om der var nogle i særdeleshed, du syntes var værd at læse, eller om det var hele tråden. Det er ikke altid tydeligt, når folk linker til artikler, hvorvidt man "bør" læse det hele eller opdage det "totalt åbenlyse" i de første 2-3 indlæg.

  • 0
  • 0
Lars Lundin

PHK skrev: "Men vi gør det først, efter at have checket vores egen kildetekst, for den slags fejl kan også ske hos os".

Problemet med Debian's selvmål var jo netop at
en debian koder "forbedrede" noget kildetekst, som Debian ellers kun videre-distribuerer.

Og på samme måde kan der jo sagtens være en
koder, som videre-distribuerer noget BSD/PHK kode, men som lige først skal "forbedre" lidt
på det. Den oprindelige forfatter, hvis navn stadig står på den "forbedrede" kode, har herefter en nærmest uoverkommelig opgave med
at kontrollere sin egen kildetekst i alle mulige og umulige distributioner.

Så jeg kan desværre ikke se at BSD-folkene eller nogen andre open-source projekter kan sikre sig mod dette problem. Faktum er i
hvert fald at det ikke er første gang at
en distributørs "forbedring" ikke er
sendt tilbage til den oprindelige vedligeholder, som derfor først har hørt
om "forbedringen" når den optræder i et produktionssystem.

Så efter at have kørt 5 X apt-get update && apt-get upgrade + rettelse af et større antal known_hosts filer, er min eneste trøst at hvis
openssh havde været closed source, så ville udrulningen af updateringen sikkert være sket
som et standard update, uden nogen advarsel om
at maskinerne faktisk har været sårbare i 2 år.

(Personligt sætter jeg min lid til min
firewall, for jeg orker ikke at reinstallere alle mine maskiner, og sikre mig at 2 års data ikke er kompromitterede, men der er helt sikkert en hel del steder, hvor der er brug for et overblik over hvad der kan være kompromitteret i denne to års periode).

  • 0
  • 0
Peter Mogensen

... jeg funderer blot over:

Havde det været et stykke closed source software, hvordan havde en udruldning af en opdatering mon så foregået?

Ikke fordi Debian fik gjort det til UG+, men de bed da trods alt i det sure æble og gjorde det nødvendige.

Hvordan havde et closed source produkt fået listet en udskiftning af alle folks nøgler igennem?

  • 0
  • 0
Jakob Bruun Hansen

Den oprindelige patch, der skabte problemet, blev diskuteret på openssl-dev maillisten:

http://marc.info/?l=openssl-dev&m=114652287210110&w=2

Så der er tilsyneladende ikke, som antydet nogen steder, tale om en tilfældig udvikler med check in rettigheder, der bare fjernede to linjer. Er der nogen, der så kan forklare, hvordan denne bug skulle være karakteristisk for open source, snare end closed source? Altså ud over, at vi kan se præcis hvem, der gjorde hvad galt, hvornår.

Jakob

  • 0
  • 0
Lars Lundin

> Havde det været et stykke closed source software, hvordan
> havde en udruldning af en opdatering mon så foregået?

"For en optimal internet oplevelse anbefales det at der dannes nye nøgler samtidigt med installationen af denne nye og endnu sikrere version af det markedsførende Mega Super Crypt (MS Crypt)".
- eller nok mere sandsynligt, en standard opdatering uden et eneste ord om sårbarheder og gendannelse af nøgler.

For uden kildeteksten forudsætter kryptoanalysen en reverse-engineering af den eksekverbare, og det gør analysen både væsentligt sværere og juridisk set risikabel (men alligevel ikke uset, google f.eks. DeCSS).

Så jeg tror at en distributør af (kryptografisk) software med lukket kildetekst sagtens kunne tage en beslutning om ikke at nævne noget om nogen sårbarheder, og så håbe på at der ikke rigtigt er nogen der opdager noget.

Det juridisk risikable i kryptoanalysen opstår iøvrigt fordi distribution efter princippet om "Security through obscurity" typisk er ledsaget af en klausul i brugerlicensen om at brugeren ikke må forsøge sig med RE.

PS. Hvis nogen stadig skulle være i tvivl, så oplever jeg det som et stort plus at den software jeg udvikler på mit arbejde frigives under GPL.

PPS. Jeg skal beklage at jeg i skyndingen med at skrive mit første indlæg skrev "closed source" fremfor "lukket kildetekst".

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