Dette sier mannen som laget Heartbleed-feilen

[tommyb]

Jeg heller også mot å tro på at statsansatte i en eller annen stat har oppdaget denne tidligere, og unnlatt å rapportere den. Fra BS's webside så jeg at det har vært rapportert at det potensielt ble utnyttet i november.

 

NSA ville gjort USA en større tjeneste om de bidro til å fikse slike ting, enn å innføre dem.

Endret 11. april 2014 av tommyb

[0stepop]

Ja, jo. Det er ikke en feil i det jeg skreiv i seg selv, men det er vel der datalekkasjen skjer fordi den utelatte sjekken ikke er gjort...?

 

Jeg er med på tankegangen, bare at den ikke er helt korrekt.

 

Det er der dataen blir kopiert, ja. Men det hjelper ingen å studere den linjen alene for feil.

 

Det er som å si at bildøren er problemet til at en tyv stjal bilen, da døren ikke var låst på forhånd.

[0stepop]

 

 

Så hva er lærdommen? Lås alle open source repoer i høytider med høy partyfaktor! Det kan ta dager før en mere dreven koder kommer og sjekker de 50 commitene som er gjort mens han bearbeidet bakrusen.

Det er noe som heter utviklingssyklus, og revisjonshistorikk. Det er da vel ingen som kjører kritiske/produksjonsløsninger rett i fra utviklingsversjonen av programvare?

Beklager, jeg glemte å slenge på en smiley

 

Selvfølgelig tester man før man setter noe i produksjon, i en idell verden skal alt være gjennomtestet til blods. Ikke praktisk mulig, og ikke alle tester dekker alt.

 

Alle testene i OpenSSL kjørte fint dem, fordi det var ikke opprettet en ny test for å teste ut den nye koden med buggen.

Det er nettopp der problemet ligger. Hadde det vært en enkel blackboxtest for dtls1_process_heartbeat(SSL *s) funksjonen, så hadde den vært avdekket umiddelbart. Og burde ha vært ett minstekrav for denne koden.

 

La oss dykke ned litt dypere:

 

Dr. Stephen Henson sin konto var faktisk brukt til å commite den buggen, 2011.12.31. Og to til neste dag.

Feil 1: Trynefaktor. Man kan vel stole på en doktor? OpenSSL teamet sin feil.

Feil 2: Ble det opprettet noen test? Nei. Review fail. Dr. Stephen Henson sin feil.

Feil 3: Man skal aldri commite kode andre har skrevet, eller tillate andre å bruke din konto. Dr. Stephen Henson sin feil.

 

Alle ledd over Robin Seggelmann feilet ham. Det er ikke Robin Seggelmann som bør klandres, men han som får skylden.

 

Ser du på kommentarene til andre commits fra Dr. Henson, vil du se den del som starter med "Oops". Ikke akkurat tillitsvekkende.

[tommyb]

 

Ja, jo. Det er ikke en feil i det jeg skreiv i seg selv, men det er vel der datalekkasjen skjer fordi den utelatte sjekken ikke er gjort...?

Jeg er med på tankegangen, bare at den ikke er helt korrekt.

 

Det er der dataen blir kopiert, ja. Men det hjelper ingen å studere den linjen alene for feil.

 

Det er som å si at bildøren er problemet til at en tyv stjal bilen, da døren ikke var låst på forhånd.

 

 

Det var da også hele poenget mitt... At Visual Basic ikke kan fange opp slike feil. Der feilen utløses er det strengt tatt ikke noe galt, og der sjekken mangler er det heller ikke noen syntax-feil, teknisk sett ingen bug der heller men "manglende sikkerhetsfunksjonalitet". Sjekken kunne nok vært gjort et annet sted uavhengig av begge disse, og det ville da ikke vært en feil. Da er det vanskelig for et utviklingsverktøy å finne feilen. Det ville sikkert vært vanskelig nok for et verktøy for testing.

Endret 11. april 2014 av tommyb

[efikkan]

Det er fordeler og ulemper med åpen kildekode.

 

Med lukket kildekode ville det vært:

- mindre sannsynlighet for at sikkerhetshullet ble oppdaget av ondsinnede

- og mindre sannsynlighet for at sikkerhetshullet ble utnyttet

og

- mindre sannsynlighet for at vennligsinnede bugsøkere ville funnet feilen,

- mindre sannsynlighet for at vennligsinnede bugsøkere kunne rettet feilen.

 

Fordeler og ulemper. Denne gangen slo ulempene hardt til;

 

Dersom feilen ble funnet i lukket kildekode og rettet ville det i dag være

- mindre sannsynlighet for et fungerende PoC, og

- mindre sannsynlighet for en race condition i utrullingsfasen,

- og det ville tatt lengre tid for et fungerende PoC og exploit å virke dersom detaljene ikke var kjente, noe som gir lengre tid til å oppdatere serverne.

 

Det som er skikkelig problematisk akkurat nå, er at det blir laget en rekke exploits umiddelbart etter feilen ble offentliggjort. Samtidig er det en lang rekke servere som ikke blir oppdatert raskt nok. Dette er selveste definisjonen på en uheldig race condition, og denne gangen vet vi at overvåkere og sikkert vanlige hackere også i stor grad vinner tilgang på masse informasjon.

 

Fordeler og ulemper.

Selv om åpen kildekode øker risikoen for at ondsinnede skal finne feil i kode så overveies dette alltid av at flere kan finne og rapportere feil. Hvis dette ikke stemmer så er programvaren i så dårlig forfatning at programmet er ubrukelig. De store mengdene med feil lukes ut mye tidligere med åpen kildekode. Og om vi antar at koden er den samme, så vil det statistisk sett lønne seg å åpne den. Grunnen til dette er at langt flere forskere og utviklere er i stand til å analysere programvaren.

 

Jeg heller også mot å tro på at statsansatte i en eller annen stat har oppdaget denne tidligere, og unnlatt å rapportere den. Fra BS's webside så jeg at det har vært rapportert at det potensielt ble utnyttet i november.

 

NSA ville gjort USA en større tjeneste om de bidro til å fikse slike ting, enn å innføre dem.

Det gjenstår å se. Det sirkulerer selvsagt mye feilinformasjon i en slik sak, så vi får vente til det er noe harde fakta om det.

 

Det er forøvrig riktig at NSA tjener bedre sine borgere ved å fikse slike feil. Men uansett er jeg ikke så veldig bekymret over NSA, alle land spionerer og det er langt mindre vennlige land enn USA...

[tommyb]

Det er langt mindre vennlige land enn USA, og USA er ikke de som plager meg mest å bli overvåket av. Men jeg er usikker på om det er andre land som putter like mange dollar og arbeidstimer inn i masseovervåkningen, og det er i alle fall ingen andre land som har så mye av kjernetjenestene på egen nasjons jord.

 

EFF hadde forøvrig denne artikkelen om et potensielt exploit hos Terrence Koeman of MediaMonks;

 

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013

 

Det gjenstår å se om også det er et falskt positivt resultat.

[efikkan]

Det er en kjent sak at det finnes et tvilsomt marked som selger ukjente sårbarheter både over og under disk, så det må finnes en mengde med sårbarheter i ulike tjenester. Men vi må huske på at den som finner slike sårbarheter veldig raskt kan avsløre seg selv om de utnytter det i stor grad. Gode systemadministratorer har en rekke metoder for å oppdage store mengder med unormal trafikk eller unormale innlogginger. Derfor er det rimelig å anta at slike angrep ofte brukes mot spesifikke mål ("spearphishing"), og det er verdt å nevne at om noen har kjent til heartbleed-feilen så har de kunne hentet ut små mengder data fra tilfeldige brukere.

[0stepop]

 

 

 

Ja, jo. Det er ikke en feil i det jeg skreiv i seg selv, men det er vel der datalekkasjen skjer fordi den utelatte sjekken ikke er gjort...?

Jeg er med på tankegangen, bare at den ikke er helt korrekt.

 

Det er der dataen blir kopiert, ja. Men det hjelper ingen å studere den linjen alene for feil.

 

Det er som å si at bildøren er problemet til at en tyv stjal bilen, da døren ikke var låst på forhånd.

Det var da også hele poenget mitt... At Visual Basic ikke kan fange opp slike feil. Der feilen utløses er det strengt tatt ikke noe galt, og der sjekken mangler er det heller ikke noen syntax-feil, teknisk sett ingen bug der heller men "manglende sikkerhetsfunksjonalitet". Sjekken kunne nok vært gjort et annet sted uavhengig av begge disse, og det ville da ikke vært en feil. Da er det vanskelig for et utviklingsverktøy å finne feilen. Det ville sikkert vært vanskelig nok for et verktøy for testing.

Hæ? Visual Basic?

Poenget ditt ble overskygget av det du skrev først om memcpy, som er feil. Ordene du leter etter er: logisk feil.

Joda, Visual Studio kan hjelpe deg med logiske feil, du kan da skrive og kjøre tester i VS. VS er mye mer enn en editor og diverse kompilere.

[efikkan]

Det er ikke kompilatorer eller IDEer som bruker å finne slike feil, men dypere analyse og profilering som f.eks. valgrind.

[tommyb]

 

Det var da også hele poenget mitt... At Visual Basic ikke kan fange opp slike feil. Der feilen utløses er det strengt tatt ikke noe galt, og der sjekken mangler er det heller ikke noen syntax-feil, teknisk sett ingen bug der heller men "manglende sikkerhetsfunksjonalitet". Sjekken kunne nok vært gjort et annet sted uavhengig av begge disse, og det ville da ikke vært en feil. Da er det vanskelig for et utviklingsverktøy å finne feilen. Det ville sikkert vært vanskelig nok for et verktøy for testing.

Hæ? Visual Basic?

 

Scroll tilbake da, det var ikke jeg som trakk inn Visual Basic i denne debatten. Visual Basic, ikke Visual Studio. Klart at det er testverktøy som best tester slike tilfeller :g

 

Det er kommet på nyhetene at NSA vissnok har visst om og utnyttet Heartbleed i to år. Hvis det er tilfelle, er det skandale.

 

http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html

Endret 11. april 2014 av tommyb

[nessuno]

P.J.Fry: Not sure if honest mistake, or NSA tool.

[-CerN-]

Syns det er for dumt at han liksom skal få skylden for at dette skjedde. Feil skjer, det er umulig å programere 100% sikker kode. Det er vel heller de som er ansvarlige for OpenSSL som organisasjon som må ta støyten, og se på rutinene for feilsjekking og validering.