To tredjedeler av alle nettbrukere kan være rammet

[OHJohansen]

Alvorlig sikkerhetshull i OpenSSL oppdaget.

To tredjedeler av alle nettbrukere kan være rammet

[meg0709]

Bra at man har udugelige folk til å lage "sikre" ting.

Ansett mindre udugelige folk til å skrive kode, pro tip.

[hjahre]

Bra at man har udugelige folk til å lage "sikre" ting.

Ansett mindre udugelige folk til å skrive kode, pro tip.

I frykt for å mate trollet. Hele greia med OpenSSL er at det er fritt og åpent, og at de har et community som sørger for at feil blir oppdaget og rettet fort. I dette tilfellet har ikke det skjedd, da feilen kan være godt skjult i koden og kun bli oppdaget i visse tilfeller. Sånn som jeg har forstått det ble denne feilen oppdaget ved å lese pakker som er kryptert med OpenSSL.

Så det at det er udugelige folk som ser over koden må du nok litt lenger ut på landet med. Dessuten er kryptografi avanserte greier

[Trondster]

En veldig, veldig stygg sak. Et av de største sikkerhetshullene hittil.

 

På en skala fra 1-10, hvor høyt har sånt som NSA kjent til denne, tro?

[LoveAmiga]

Trodde åpen programvare = trygt jeg? Dette motbeviser vel alle de påstandene.

[Bleenda]

Trodde åpen programvare = trygt jeg? Dette motbeviser vel alle de påstandene.

Mye merkelige kommentarer ute og går.. Det er da klart Open Source er et tryggere alternativ. Feil kan jo dessverre skje her også. Men du foretrekker kanskje å stole på lukket programvare, helst levert av en stor amerikansk bedrift?

Endret 8. april 2014 av iNzzain

[Trondster]

Trodde åpen programvare = trygt jeg? Dette motbeviser vel alle de påstandene.

 

Helt klart. Nå er det klart at det kun er lukket programvare som er helt trygg. Det ser man tydelig - det er aldri grunn til å patche sikkerhetshull der.

[8086]

Nektelser er vanskelig

 

Det som gjør Heartbeat-hullet så alvorlig er at det ikke skal være umulig å spore ned kriminelle som har brutt seg inn og fått fingrene i sensitive personopplysninger.

 

 

 

Virker jo ikke så farlig når det er mulig å spore de kriminelle ;-)

Endret 8. april 2014 av member_205136

[Dupl3xxx]

[...] På en skala fra 1-10, hvor høyt har sånt som NSA kjent til denne, tro?

 

Et år etter at hullet "var der" vil jeg tippe* 9/10. etter ca 2 mnd vil jeg tippe 6/10.

 

*Ingen videre begrunnelse enn at jeg tipper.

[GeirGrusom]

Dessuten er kryptografi avanserte greier

Men denne buggen er ekstremt grunnleggende. Buggen har fint lite med kryptografi å gjøre. Dette er snakk om at OpenSSL går god for hva sluttklienten sier. Dette er et slags buffer overrun sikkerhetshull ved at brukeren kan spørre om data som ligger utenfor området til strukturen den pekte til.

 

edit: her er committen som fikset problemet for de som er interessert.

Endret 9. april 2014 av GeirGrusom

[Hayer]

 

Dessuten er kryptografi avanserte greier

Men denne buggen er ekstremt grunnleggende. Buggen har fint lite med kryptografi å gjøre. Dette er snakk om at OpenSSL går god for hva sluttklienten sier. Dette er et slags buffer overrun sikkerhetshull ved at brukeren kan spørre om data som ligger utenfor området til strukturen den pekte til.

 

edit: her er committen som fikset problemet for de som er interessert.

Takk for linken til committen - alltid artig å se på andre sin kode. HW kunne gjerne inkluderte sånne linker i artikkelen selv

[Trene Arnholdt]

Hva med å lage en sak på hvor (u)sikkre nettbanker egentlig er?..

Kjørte en liten test fra SSL labs for å se om noen av bankene til meg og familien min var sårbare for "heartbleed".

Fordi om de ikke er det, så var det alikevel SKREMMENDE lesning!..

Når finn.no har bedre sikkerhets "rating" enn bankene våre, så bør det blinke noen alarmbjeller!

 

Nå skal det sies at Finn fikk A-, noe som er veldig bra.

Bankene jeg kjørte test på lå fra B til F!

 

Får man F når man skal drifte en nettbank, bør vel noen ta sin hatt og gå!

[endrebjo]

Hva med å lage en sak på hvor (u)sikkre nettbanker egentlig er?..

Kjørte en liten test fra SSL labs for å se om noen av bankene til meg og familien min var sårbare for "heartbleed".

Fordi om de ikke er det, så var det alikevel SKREMMENDE lesning!..

Når finn.no har bedre sikkerhets "rating" enn bankene våre, så bør det blinke noen alarmbjeller!

 

Nå skal det sies at Finn fikk A-, noe som er veldig bra.

Bankene jeg kjørte test på lå fra B til F!

 

Får man F når man skal drifte en nettbank, bør vel noen ta sin hatt og gå!

Det er ikke bare-bare å se seg blind på karakterene i en vilkårlig test, uten å sjekke hva som ligger bak testene. F.eks nekter SSL Labs å gi noe høyere enn karakteren B hvis siden ikke støtter TLS 1.1+. Paradokset er at TLS 1.1 først ble introdusert i OpenSSL 1.0.1, som nå er kompromittert gjennom Heartbleed (inntil i går). De som har valgt å vente med overgangen til OpenSSL 1.0 har unngått hele Heartbleed-problematikken, men har da ikke hatt mulighet til å bruke TLS 1.1+. Jeg kjenner dessverre ikke til offisiell status på TLS 1.0, så jeg vet ikke om den er veldig usikker, eller om den har blitt kompromittert i det hele tatt. Det er også en viktig betraktning når man skal vurdere sikkerheten på en side.

 

I tillegg baserer de fleste nettbankene seg på BankID, og den sikkerheten blir ikke testet av SSL Labs. De tester første SSL-lag i nettside-kommunikasjonen, mens BankID-innlogging kjører i et helt annet miljø. Du kan samtidig regne med at BankID har minst 5-6 barrierer med diversifisert sikkerhet. Dvs. at de ikke baserer seg på ett bibliotek og en innloggingsmetode, men flere lag med f.eks forskjellige biblioteker som JSSE, SSPI, OpenSSL, forskjellige krypteringsmetoder, og hvert lag er sannsynligvis isolert fra resten i hver sine virtuelle miljøer, eventuelt fysisk adskilt med forskjellige OS også. På den måten unngår man at ett kompromittert bibliotek kan avsløre nøklene brukt i et annet lag.

[PoTski]

Hva med å lage en sak på hvor (u)sikkre nettbanker egentlig er?..

Kjørte en liten test fra SSL labs for å se om noen av bankene til meg og familien min var sårbare for "heartbleed".

Fordi om de ikke er det, så var det alikevel SKREMMENDE lesning!..

Når finn.no har bedre sikkerhets "rating" enn bankene våre, så bør det blinke noen alarmbjeller!

 

Nå skal det sies at Finn fikk A-, noe som er veldig bra.

Bankene jeg kjørte test på lå fra B til F!

 

Får man F når man skal drifte en nettbank, bør vel noen ta sin hatt og gå!

 

Nå skal det sies at banker oppdaterer openSSL det gjør ikke finn.no Versjonene som er påvirket er 1.0.1 til 1.0.1f burde også stå i HW artikkelen. finn.no er sårbar for TCP RST ddos, men det er nok litt enklere og sikre en enkel side som finn en avanserte web applikasjoner.

[PoTski]

Hva med å lage en sak på hvor (u)sikkre nettbanker egentlig er?..

Kjørte en liten test fra SSL labs for å se om noen av bankene til meg og familien min var sårbare for "heartbleed".

Fordi om de ikke er det, så var det alikevel SKREMMENDE lesning!..

Når finn.no har bedre sikkerhets "rating" enn bankene våre, så bør det blinke noen alarmbjeller!

 

Nå skal det sies at Finn fikk A-, noe som er veldig bra.

Bankene jeg kjørte test på lå fra B til F!

 

Får man F når man skal drifte en nettbank, bør vel noen ta sin hatt og gå!

 

btw. finn cookie er ikke secure. session hijacking er awesome.

[efikkan]

Det kommer uklart frem av artikkelen, men denne svakheten gir altså mulighet til å lese av opptil 64kB av minnet til OpenSSL-prosessen på serveren. Det er altså da teoretisk mulig å lese ut privatnøkkel selv om det er svært usannsynlig at noen har gjort det før avsløringen.

 

Trodde åpen programvare = trygt jeg? Dette motbeviser vel alle de påstandene.

Nei, at noe er åpent har aldri gjort det automatisk trygt, men det er alltid tryggere enn lukket programvare. Det er ingen som hindrer folk i å lage elendig åpen programvare. Hvis noen som helst programvare står i fare for å bli kompromittert av åpenhet så har ikke den implementert sikkerhet riktig.

 

Med lukket kildekode ville slike feil som dette som regel ikke blitt oppdaget av godsinnede før det er aktivt utnyttet.

 

Hele greia med OpenSSL er at det er fritt og åpent, og at de har et community som sørger for at feil blir oppdaget og rettet fort. I dette tilfellet har ikke det skjedd, da feilen kan være godt skjult i koden og kun bli oppdaget i visse tilfeller. Sånn som jeg har forstått det ble denne feilen oppdaget ved å lese pakker som er kryptert med OpenSSL.

Bare så det er sagt så er OpenSSL en beryktet implementasjon for elendig kode. ref Prosjektet er fryktelig dårlig administrert og kodet av noen svært få personer som produserer "uleselig" kode.

 

Så det at det er udugelige folk som ser over koden må du nok litt lenger ut på landet med. Dessuten er kryptografi avanserte greier

Udugelige folk er de nok ikke, men de har nok alt for god tro på egenprodusert kode.

Feilen som ble begått er forøvrig ingen feil algoritmisk, men en "nybegynnerfeil" i C-kode.

 

I tillegg baserer de fleste nettbankene seg på BankID, og den sikkerheten blir ikke testet av SSL Labs. De tester første SSL-lag i nettside-kommunikasjonen, mens BankID-innlogging kjører i et helt annet miljø. Du kan samtidig regne med at BankID har minst 5-6 barrierer med diversifisert sikkerhet. Dvs. at de ikke baserer seg på ett bibliotek og en innloggingsmetode, men flere lag med f.eks forskjellige biblioteker som JSSE, SSPI, OpenSSL, forskjellige krypteringsmetoder, og hvert lag er sannsynligvis isolert fra resten i hver sine virtuelle miljøer, eventuelt fysisk adskilt med forskjellige OS også. På den måten unngår man at ett kompromittert bibliotek kan avsløre nøklene brukt i et annet lag.

Grunnen til at BankID bruker java-applet er for å sikre at kommunikasjonen skjer sikkert. Det som de derimot ikke har tenkt på er at folk da kan utnytte usikker kommunikasjon på nettsiden rundt til å bytte ut applet-en med en egenprodusert(og som er "self signed"), uten at brukeren er i stand til å se at de blir lurt. Hele strukturen er altså fundamentalt dårlig, spesielt med tanke på at SSL-implementasjonen i JRE ikke nødvendigvis er helt oppdatert heller.

[LoveAmiga]

 

Trodde åpen programvare = trygt jeg? Dette motbeviser vel alle de påstandene.

Mye merkelige kommentarer ute og går.. Det er da klart Open Source er et tryggere alternativ. Feil kan jo dessverre skje her også. Men du foretrekker kanskje å stole på lukket programvare, helst levert av en stor amerikansk bedrift?

 

 

Ja, huff! Skikkelig skumle disse Amerikanerne. Alt som skjer i denne verden styres jo av de

[endrebjo]

 

Hele greia med OpenSSL er at det er fritt og åpent, og at de har et community som sørger for at feil blir oppdaget og rettet fort. I dette tilfellet har ikke det skjedd, da feilen kan være godt skjult i koden og kun bli oppdaget i visse tilfeller. Sånn som jeg har forstått det ble denne feilen oppdaget ved å lese pakker som er kryptert med OpenSSL.

Bare så det er sagt så er OpenSSL en beryktet implementasjon for elendig kode. ref Prosjektet er fryktelig dårlig administrert og kodet av noen svært få personer som produserer "uleselig" kode.

Så det at det er udugelige folk som ser over koden må du nok litt lenger ut på landet med. Dessuten er kryptografi avanserte greier

Udugelige folk er de nok ikke, men de har nok alt for god tro på egenprodusert kode.

Feilen som ble begått er forøvrig ingen feil algoritmisk, men en "nybegynnerfeil" i C-kode.

 

Interessant. Jeg reagerte faktisk på kodekvaliteten da jeg så på commiten som GeirGrusom viste til, og hvis resten av prosjektet er skrevet på samme måte skjønner jeg godt at det kan dukke opp alvorlige lekkasjer. Men kanskje en sånn feil blir en vekker for flere, slik at hele prosjektet/biblioteket får seg en real overhaling? Det er jo lov å håpe. :-)

 

 

 

I tillegg baserer de fleste nettbankene seg på BankID, og den sikkerheten blir ikke testet av SSL Labs. De tester første SSL-lag i nettside-kommunikasjonen, mens BankID-innlogging kjører i et helt annet miljø. Du kan samtidig regne med at BankID har minst 5-6 barrierer med diversifisert sikkerhet. Dvs. at de ikke baserer seg på ett bibliotek og en innloggingsmetode, men flere lag med f.eks forskjellige biblioteker som JSSE, SSPI, OpenSSL, forskjellige krypteringsmetoder, og hvert lag er sannsynligvis isolert fra resten i hver sine virtuelle miljøer, eventuelt fysisk adskilt med forskjellige OS også. På den måten unngår man at ett kompromittert bibliotek kan avsløre nøklene brukt i et annet lag.

Grunnen til at BankID bruker java-applet er for å sikre at kommunikasjonen skjer sikkert. Det som de derimot ikke har tenkt på er at folk da kan utnytte usikker kommunikasjon på nettsiden rundt til å bytte ut applet-en med en egenprodusert(og som er "self signed"), uten at brukeren er i stand til å se at de blir lurt. Hele strukturen er altså fundamentalt dårlig, spesielt med tanke på at SSL-implementasjonen i JRE ikke nødvendigvis er helt oppdatert heller.

 

Godt poeng! Sikkerheten er ikke sterkere enn det svakeste leddet.

[efikkan]

 

 

Hele greia med OpenSSL er at det er fritt og åpent, og at de har et community som sørger for at feil blir oppdaget og rettet fort. I dette tilfellet har ikke det skjedd, da feilen kan være godt skjult i koden og kun bli oppdaget i visse tilfeller. Sånn som jeg har forstått det ble denne feilen oppdaget ved å lese pakker som er kryptert med OpenSSL.

Bare så det er sagt så er OpenSSL en beryktet implementasjon for elendig kode. ref Prosjektet er fryktelig dårlig administrert og kodet av noen svært få personer som produserer "uleselig" kode.

Så det at det er udugelige folk som ser over koden må du nok litt lenger ut på landet med. Dessuten er kryptografi avanserte greier

Udugelige folk er de nok ikke, men de har nok alt for god tro på egenprodusert kode.

Feilen som ble begått er forøvrig ingen feil algoritmisk, men en "nybegynnerfeil" i C-kode.

 

Interessant. Jeg reagerte faktisk på kodekvaliteten da jeg så på commiten som GeirGrusom viste til, og hvis resten av prosjektet er skrevet på samme måte skjønner jeg godt at det kan dukke opp alvorlige lekkasjer. Men kanskje en sånn feil blir en vekker for flere, slik at hele prosjektet/biblioteket får seg en real overhaling? Det er jo lov å håpe. :-)

 

OpenSSL er et så stort makkverk at det burde vært kastet på havet. Bare se på koden selv eller på kommentarene på github, folk klarer ikke å forstå koden eller variabelnavn.

Det vi virkelig trenger er en referanseimplementasjon av SSL/TLS som alle andre kan sjekkes mot. I tillegg trenger implementasjonene stadige gjennomganger, og vi må anta at hver commit til et slikt prosjekt er skadelig frem til vi har frikjent det.

 

Du husker sikkert SSL-feilen til Apple for kort tid siden. Rett etter dette tok Red Hat en gjennomgang av GnuTLS og fant et urelatert problem. Dette trenger vi mer av, systematiske gjennomganger av alle kritiske komponenter. Selv om jeg skulle være en aldri så perfekt C-programmerer, så kan jeg være i stand til å produsere kode med feil jeg ikke er i stand til å se, spesielt siden jeg leser kode som jeg delvis husker i hodet (på samme måte som en forfatter har mer vansker for å se egne skrivefeil enn en tredjepart).

 

Urelatert til dette prosjektet men likevel verdt å nevne er en rekke viktige pakker fra OpenBSD-gjengen som f.eks. står bak helt uunnværlige OpenSSH. Dette er på langt nær like ille som OpenSSL, men denne gjengens holdninger overfor sikkerhet og egen kodekvalitet bekymrer meg. Selv om det er selveste Linus Torvalds som har gjort en commit så bør vi "sikkerhetsklarere" den.

[Sprokket]

Er Hardware/tek berørt og er feilen rettet her?