Gå til innhold

Dette sier mannen som laget Heartbleed-feilen


Anbefalte innlegg

Videoannonse
Annonse

Selv lurer jeg litt på hva utviklerne bruker til dette? Notisblokk eller notepad++ samt jedit?

 

Hadde det vært virtual basic:

 

 

errorlist1.gif

Ville nok feil bli oppdaget veldig raskt.

 

Godt spørsmål - håper noen svarer på dette.

 

Litt på siden, men samtidig helt seriøst, så lurer jeg også på hva journalister skriver artiklene sine i. Jeg ser ofte tilsvarende slurvefeil i nettaviser. Feil som enkelt hadde blitt oppdaget av f.eks Word eller et annet program med stavekontroll. Nå er det riktignok langt viktigere at koden til OpenSSL er korrekt enn at nyhetsartiklene er stavet riktig, men en undres likevel hvordan det har seg at slurvefeil er så utbredt når det finnes mange måter å oppdage dem på.

  • Liker 6
Lenke til kommentar

Selv lurer jeg litt på hva utviklerne bruker til dette? Notisblokk eller notepad++ samt jedit?

 

Hadde det vært virtual basic:

 

 

*snip*

Ville nok feil bli oppdaget veldig raskt.

 

Tror du seriøst at de som sitter utvikler sikkerhetsstandarder brukt over hele verden ikke har skikkelige utvikler-verktøy? :hrm:

 

For å dra en parallell som de fleste kan henge med på: Du kan få til å skrive mye feil selv med retteprogram i Word. ;)

 

Det er klart at en del språk er mindre strenge på koden man skriver. Men feil får man til i de fleste utviklerverktøy :)

Endret av Dipso
  • Liker 1
Lenke til kommentar
Gjest Slettet+214asdf125

Selv lurer jeg litt på hva utviklerne bruker til dette? Notisblokk eller notepad++ samt jedit?

 

Hadde det vært virtual basic:

SNIP

Ville nok feil bli oppdaget veldig raskt.

Med mindre det er skrevet noe om denne valideringsfeilen som jeg ikke har fått med meg vil det ikke være en feil av den typen du har et eksempel på.

 

Utviklerverktøy kan lett fange opp syntaksfeil, men det fins mange typer mulige feil i kode.

Et banalt eksempel vil være SQL-injection, hvor all koden er lovlig og problemet ikke vil fanges opp uten grundig testing av input-verdiene i alle tekstfelt og lignende.

 

Å glemme EN variabeltest av lignende type vil være katastrofalt, men når man sitter med potensielt tusenvis av linjer kode er det fort gjort. Spesielt dersom man kjører en test som ikke er omfattende nok og feilaktig tror at koden som testes er bombesikker.

 

https://en.wikipedia.org/wiki/SQL_injection

Lenke til kommentar

Enig med Oddsor, som en som går på Informatikk linje på UiO så er det flere ganger koden er uten feil, men programmet oppfører seg ikke som jeg vil. Da kan være mye rart. Noen ganger har den oppført seg som jeg vil, men med enkelte tester så kan en feil dukke opp og vise at det er fortsatt noe "feil" i koden. Selv om alt kjører helt fint.

 

I større programmer og løsninger kan sånne feil være vanskeligere å spotte. Kan tenke meg hvorfor det er mer og mer vanlig med større beta tester og early access på spill og programmer.

Lenke til kommentar

Her er feilen:

 

memcpy(bp, pl, payload);

 

"Heartbleed explanation: This line copies payload bytes from pl to bp. But payload contains the length that the client says that pl has, it has not been checked that the client doesn't lie about the length of pl. "

 

Denne type feil vil ikke vises i Visual Studio.

 

Kilde: https://github.com/openssl/openssl/commit/4817504d069b4c5082161b02a22116ad75f822b1

  • Liker 5
Lenke til kommentar

Enda godt OpenSSL er open source, sånn at feilen ble funnet raskt etter noen år.

 

Ja, ikke sant. Det er mye mer behagelig med lukket kildekode, der slike feil så langt det er mulig blir forsøkt unndrat offentlighetens lys fordi det gir prestisjetap og uønsket markedsføringseffekt for bedriften.

 

Jeg for min del lar meg imponere av Seggelmann som bevarer fatningen i mediestormen og klarer å peke på den åpenbare løsningen - at dersom flere bidro, ville det bli færre slike feil.

 

 

Mvh

Per Gunnar Hansø

  • Liker 6
Lenke til kommentar

 

Enda godt OpenSSL er open source, sånn at feilen ble funnet raskt etter noen år.

Ja, ikke sant. Det er mye mer behagelig med lukket kildekode, der slike feil så langt det er mulig blir forsøkt unndrat offentlighetens lys fordi det gir prestisjetap og uønsket markedsføringseffekt for bedriften.

 

 

Absolutt, absolutt.

Lenke til kommentar

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.

  • Liker 1
Lenke til kommentar

Det er fordeler og ulemper med åpen kildekode.

 

[Gode avveininger mellom fordeler og ulemper snippet]

 

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.

 

Mange gode poeng her. Vil bare føye på et spesifkt og generelt poeng til.

 

Spesielt for denne saken, har jo nå alle berørte blitt gjort klar over at de har vært utsatt, og hvor lenge. Med feil i lukket kildekode får du gjerne ikke den informasjonen.

 

Generelt har nå flere blitt klar over at sikkerhet på nett (og i dataprogrammer generelt) ikke er 100%. Det er en verdi i seg selv. Det skader ikke at folk flest tenker en ekstra tanke på sikkerhet før de gjør ting på nett.

 

Mvh

Per Gunnar Hansø

  • Liker 2
Lenke til kommentar

Generelt har nå flere blitt klar over at sikkerhet på nett (og i dataprogrammer generelt) ikke er 100%. Det er en verdi i seg selv. Det skader ikke at folk flest tenker en ekstra tanke på sikkerhet før de gjør ting på nett.

 

Og jeg kan jo henge på et til poeng, relatert til ditt... To menn, navn skal være unevnt, og en prosjektorganisasjon er nå blitt hengt sånn passe opp i gapestokk. Kjipt for dem, men det kan medføre at enkeltpersoner og organisasjoner strammer inn sine testrutiner over hele fagfeltet.
  • Liker 1
Lenke til kommentar

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?

Lenke til kommentar

Her er feilen:

 

memcpy(bp, pl, payload);

 

"Heartbleed explanation: This line copies payload bytes from pl to bp. But payload contains the length that the client says that pl has, it has not been checked that the client doesn't lie about the length of pl. "

 

Denne type feil vil ikke vises i Visual Studio.

 

Kilde: https://github.com/openssl/openssl/commit/4817504d069b4c5082161b02a22116ad75f822b1

 

Dette er ikke feilen, bare en bivirkning. Feilen er den utelatte sjekken på verdien av payload lenge før.

 

"" <- dette er feilen.

"if (1 + 2 + payload + 16 > s->s3->rrec.length)

return 0; /* silently discard per RFC 6520 sec. 4 */" <- dette er fiksen

 

Fremdeles mange sider som er utsatt:

https://github.com/musalbas/heartbleed-masstest

Lenke til kommentar

Mange gode poeng her. Vil bare føye på et spesifkt og generelt poeng til.

 

Spesielt for denne saken, har jo nå alle berørte blitt gjort klar over at de har vært utsatt, og hvor lenge. Med feil i lukket kildekode får du gjerne ikke den informasjonen.

 

Generelt har nå flere blitt klar over at sikkerhet på nett (og i dataprogrammer generelt) ikke er 100%. Det er en verdi i seg selv. Det skader ikke at folk flest tenker en ekstra tanke på sikkerhet før de gjør ting på nett.

 

Mvh

Per Gunnar Hansø

 

Det sterkeste poenget som jeg anser det: denne feilen ville vært vanskeligere å utnytte i 2 år hvis OpenSSL ikke var open source.

Black hats studerer åpen kildekode dag og natt etter feil, nettopp av denne typen. Og jeg er derfor i konflikt med meg selv om OpenSSLs åpenhet.

 

Selv etter feilen har blitt avduket og rettet er det mange nettsteder som henger etter, og blir i nåværende tidspunkt utsatt for angrep. Honeypots mister sin effekt da white hats også utfører "angrep" i god opplysningsånd.

Lenke til kommentar

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

Laster...
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...