Intervju: ESET om säkerhetshålet Heartbleed

Permalänk
Medlem

Jag vet att det sagts att buggen inte uppkom avsiktiligt. Om det stämmer som det rapporteras om nu, att NSA känt till buggen under hela tiden och även använt sig av den - verkar det då inte misstänkt att det också är de som har sett till att den tillkom?

Visa signatur

Vituð ér enn, eða hvað?

Permalänk
Hedersmedlem
Skrivet av Bakwetu:

Jag vet att det sagts att buggen inte uppkom avsiktiligt. Om det stämmer som det rapporteras om nu, att NSA känt till buggen under hela tiden och även använt sig av den - verkar det då inte misstänkt att det också är de som har sett till att den tillkom?

Emfas min . Det är viss hets i att trycka in förkortningen "NSA" i alla nyheter numera. "Källan" till påståendet om NSA är två icke-namngivna personer som Bloomberg hävdar sig ha pratat med. Eftersom nyheten låter så pass bra så upprepas den hejvilt av tidningar världen över, men det gör det inte per automatik sant, och källan är inte precis vattentät.

"Misstänkt" — ja, man kan tycka att det är så misstänkt som man vill, men historiken för bibliotekets utveckling är väldokumenterad, och det går att hitta en enskild person (+personen som granskade ändringen) som skrivit denna kodsnutt när heartbeatfunktionaliteten lades till, och personen (från Tyskland, ifall man ser relevans i detta) har själv sagt att det var ett ärligt misstag. Det finns för närvarande inga kända kopplingar till NSA varken förr eller senare gällande denna person. Misstag händer, och det måste ändå vara den rimligaste förklaringen tills motsatsen bevisats.

Det är en rätt slarvig bugg, men tja. Man kan spekulera hur mycket man vill, men det finns idag inget som bekräftat tyder på att detta beteende varit känt sedan tidigare.

En av de större sakerna att ta med sig från detta anser jag personligen är att dessa fundamentala säkerhetsdetaljer som styr mycket av världens infrastruktur borde ges större fokus av de som använder verktygen. Just OpenSSL har varit i blåsväder tidigare, och den skärskådning av koden som gjorts senaste dagarna har inte precis varit till bibliotekets fördel. Ett problem har varit att då OpenSSL blivit något av en branschstandard så har det blivit extremt svårt att genomföra större omfaktoreringar, för om något beteende odokumenterat skulle råka förändras så skulle det påverka enormt många användare. Därav har koden fått lite "liggsår" med tiden. Lösningen på detta är att ha ordentliga sviter med enhetstester så att man kan garantera kodens funktionalitet även efter omfaktorering, men resurserna verkar inte ha tillåtit detta — vilket låter som ett prioriterings/organiseringsfel av inte minst alla de gigantiska organisationer som använt (och fortsätter använda) OpenSSL.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av Yooriitzz:

Tänk om detta inte skulle varit open source.... Jävlar då skulle vi nog haft problem.

ehh, du tycker inte att en stor del av alla servrar på internet varit vidöppna för stöld av i princip allt i två års är problem? Och att alla lösenord på servrar som varit påverkade måste anses vara förverkade är ett problem? I vilken verklighet lever du?

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Dimman:

Det finns en anledning att samtliga crypto-algoritmer som används av banker/militär etc är öppna för alla att se. När implementationen är känd och man inte lyckas knäcka den, då är den hållbar (man kan ju bara dra en gissning över hur många människor som har försökt hitta luckor i algoritmerna..).

Det hjälpte ju förvisso föga i fallet med Dual EC DRBG

Permalänk
SweClockers
Skrivet av The-Architect:

Det hjälpte ju förvisso föga i fallet med Dual EC DRBG

Dual EC DRBG var ju misstänkt redan från början och kritiserades flera år innan NSA-skandalen, tack vare open source.

Visa signatur

» Kontakta oss » SweClockers på Facebook » SweClockers på Youtube » Blips of SweClockers (Spotify)
» Pappa till Moderskeppet » SweClockers chefredaktör 2007–2015

Permalänk
Medlem
Skrivet av Dr.Mabuse:

Hur tänker du nu? Vänligen utveckla, för jag förstår faktisk inte vad opern source har med det hela att göra. Snarare skulle det kunna tala för att öppenhet inte är en garanti för felfri kod och således en myt.

Absolut inte deta jag menade. Denna bug skulle förmodligen ha upptäckts mycket senare om koden skulle varit stängd.

Visa signatur

Aspirerande Nätverk- och Sysadmin
Ryzen 5 1600|Hd 7950|16 GB RAM|
"Går det att installera Linux på den här brödrosten?"

Permalänk
Medlem
Skrivet av The-Architect:

Det hjälpte ju förvisso föga i fallet med Dual EC DRBG

Det är heller ingen som har påstått att det är någon garanti för säkerhet.

Skrivet av Andreas D:

Dual EC DRBG var ju misstänkt redan från början och kritiserades flera år innan NSA-skandalen, tack vare open source.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem

Hopplöst oansvarigt att gå ut med att det skulle vara osannolikt att få tag i lösenord! Jag har själv fiskat rätt på ett antal lösenord från olika siter, dock inte just sweclockers, med den PoC som finns ute. Det är dessutom ännu lättare att sno sessionskakor än lösenord, och i många fall precis lika illa.

Självklart ska man byta sina lösenord! Det skadar inte att byta lösenord ändå när de haft några år på nacken så det här är ett utmärkt tillfälle.

Den viktigaste rekommendationen är dock att köra med en lösenordshanterare som slumpar nya lösenord på alla siter, till exempel LastPass eller KeePass. De är enkla, gratis, och fungerar utmärkt! Gör det redan idag, och glöm inte att ta säkerhetskopior (obs! plural!) på filen där dessa lösenord lagras.

Citat:

Tänk om detta inte skulle varit open source.... Jävlar då skulle vi nog haft problem

Biblioteket openssl som är det där buggen fanns befinner sig i uselt skick, och det hade det gjort oavsett om det var open source eller inte. Att få folk att uppdatera går dock fortare eftersom det inte finns någon leverantör att vänta på.

Citat:

Och jag som för några dagar sedan tänkte skippa att uppgradera eftersom en sårbarhet på min lilla webbsida knappast skulle orsaka någon besvär (ingen av mina besökare använder ändå https).

Har du ett SSL-certifikat på din server och är sårbar så är det mycket bättre att ta bort certifikatet och köra okrypterat än att köra vidare med den trasiga krypteringen. Har du någonsin varit sårbar för detta finns möjligheten att någon kopierat din privata krypteringsnyckel. Du behöver alltid generera ny krypteringsnyckel och nytt certifikat efter att du patchat (samt återkalla det gamla, om det är ett köpt certifikat)!

TL;DR: Byt lösenord! Kör med lösenordshanterare! Nu!

Permalänk
Medlem
Skrivet av Andreas D:

Dual EC DRBG var ju misstänkt redan från början och kritiserades flera år innan NSA-skandalen, tack vare open source.

Det användes dock fortfarande, och krypteringsalgoritmer är inte källkod, så det har inte med opensource att göra. Eller räknas matematiska formler som källkod nu också?

Permalänk
Medlem
Skrivet av Yooriitzz:

Absolut inte deta jag menade. Denna bug skulle förmodligen ha upptäckts mycket senare om koden skulle varit stängd.

Se gärna mitt svar till Sony?, upptäckten kom inte av att någon granskade själva koden utan genom stresstest av dess funktion.

Visa signatur

There are two kinds of people: 1. Those that can extrapolate from incomplete data.
Min tråkiga hemsida om mitt bygge och lite annat smått o gott: www.2x3m4u.net

Permalänk
SweClockers
Skrivet av The-Architect:

Det användes dock fortfarande, och krypteringsalgoritmer är inte källkod, så det har inte med opensource att göra. Eller räknas matematiska formler som källkod nu också?

Öppenheten är det väsentliga och vad som möjliggör granskning. Men ja, termen open source används för mer än källkod.

Visa signatur

» Kontakta oss » SweClockers på Facebook » SweClockers på Youtube » Blips of SweClockers (Spotify)
» Pappa till Moderskeppet » SweClockers chefredaktör 2007–2015

Permalänk
Hedersmedlem

bytte nyligen alla mina lösenord, tog fan ett bra tag asså!

Permalänk
Medlem

Kanske företagen vaknar och börja bidra till openSSL?
Det är en ideell organisation.
https://www.openssl.org/support/donations.html

Visa signatur

ASUS M4A89GTD PRO/USB3 | AMD Phenom2 X6 1055T|GB GF GTX 460 | Corsair 4GB | SSD 40GB Intel X25-M | HD500GB Seagate ST3500418AS | |HD2TB Seagate ST2000DL003 | Corsair TX 650W PSU | Fractal Design Define R3

Permalänk
Medlem
Skrivet av muscle:

Kanske företagen vaknar och börja bidra till openSSL?
Det är en ideell organisation.
https://www.openssl.org/support/donations.html

vore verkligen topp om det skulle bli mer bidrag till öppna standarder. jag stödjer mer än gärna öppna projekt och standarder med donationer, hoppas att även fler kan tänka sig att bidra med €1 eller liknande då och då.

Permalänk
Avstängd
Skrivet av Dr.Mabuse:

Hur tänker du nu? Vänligen utveckla, för jag förstår faktisk inte vad opern source har med det hela att göra. Snarare skulle det kunna tala för att öppenhet inte är en garanti för felfri kod och således en myt.

Buggar och brister torde drabba öppen och stängd kod i ungefär samma utsträckning, och ingen har nog påstått annat. Vissa öppna projekt har dock ekonomiskt utrymme för granskning och där är öppen kod i regel säkrare. Men allt annat lika spelar det ingen roll.

Men jag tror inte det var Yooriitzz avsåg, utan snarare att öppen källkod har bättre förutsättningar att bli granskad och patchad. Det spelar ingen roll om det är öppen eller stängd kod om man ska upptäcka uppenbara buggar och bakdörrar endast genom att pröva saker i protokollet, men däremot tillåter stängd kod bara denna form av förutsättningslös granskning och säkerhetsforskare har gång på gång på gång fått både otrevliga och obehagliga svar av företag som skapar proprietär kod när de väl funnit något problem. De kan bli jagade av jurister och de kan tvingas till tystnad och några som helst garantier för att hålen ska tätas finns inte.

För öppen mjukvara är detta förfarande mer garanterat att bli just öppet och verifierbart. Så jag delar Yooriitzzs mening att man verkligen kan vara glad att denna bugg hittades i öppen källkod. Hur många motsvarigheter som finns i stängd kod som är upptäckta eller åtminstone misstänkta av säkerhetsforskare kan vi faktiskt inte veta, för medan vissa företag givetvis blir glada för rapporterade fel finns det en hel del andra som försöker slåss med jurister för att tysta säkerhetsexpertisen.

Att öppenhet skulle vara en garant för felfri kod är en myt som du har hittat på själv. Så det är en myt att det faktiskt är en myt som förekommer. Öppen kod innehåller inte mindre fel, men felen rättas snabbare och skadeverkningarna och hålen förs i ljuset snabbare. Man ska alltså inte missta publicitet kring buggar och bakdörrar för att det som det är tyst om är säkert.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av eXale:

Yup, vilket gör arbetet extremt enkelt för attackerare om utdelarna/communityn inte är "on the ball".

Finns tyvärr inte mycket tecken på att detta är fallet.

Nej, det kanske verkar så i teorin, men stämmer nog inte i praktiken. Säkerhetshålen i OpenSSL upptäcktes som brukligt är genom att undersöka input och output från ett program och inte genom att granska kod. Kodgranskning är en rätt så specialiserad uppgift och väldigt tidsödande. Klart att en attackerare kommer scanna igenom valda bitar av öppen kod för att se om något uppenbart finns där, men i övrigt rör det sig om så att säga skilda kompetensområden. Dessutom är "stängd kod" mer skyddade av juridik än att koden faktiskt är hemlighållen. Så en attackerare kan antas ha tillgång till källkoden oavsett om koden är öppen eller stängd. Det är därför "security by obscurity" är en dum idé och när det kommer till säkerhet så utgår man ALLTID i säkerhetsmodelleringen från att en attackerare har 1) tillgång till koden och 2) förståelse för de algoritmer som används (t.ex. protokoll och krypteringsalgoritmer). Den allmänna "termen" är "the enemy knows the system", alltså att "fienden" har all upptänklig insyn och det enda denne inte vet är saker som nycklar och lösenord.

Fördelen med öppen källkod här är just den möjliggjorda granskningen. Det är en fördel och en styrka ur säkerhetsperspektiv, inte en nackdel. Jämför gärna med vetenskapliga teorier där det är en styrka att de är falsifierbara och en nackdel och svaghet om de inte kan bevisas vara fel (i själva verket kallar vi inte sådana "teorier" för teori ö.h.t.).

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem

För de som följer tråden och undrar vad som sker med OpenSSL så har OpenBSD-projektet (förutom namnlikheten ej tidigare inblandade i OpenSSL) nu officiellt kallat sitt modifierade kodträd av OpenSSL som de jobbat på senaste veckan för en avgrening och gett den namnet LibreSSL. Initialt kommer det vara OpenBSD-exklusivt, men framöver är planen enligt utsaga att skriva porterbar kod mot övriga plattformar. Framtiden får utvisa om denna gren adapteras brett framöver.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av MBY:

Buggar och brister torde drabba öppen och stängd kod i ungefär samma utsträckning, och ingen har nog påstått annat. Vissa öppna projekt har dock ekonomiskt utrymme för granskning och där är öppen kod i regel säkrare. Men allt annat lika spelar det ingen roll.

Men jag tror inte det var Yooriitzz avsåg, utan snarare att öppen källkod har bättre förutsättningar att bli granskad och patchad. Det spelar ingen roll om det är öppen eller stängd kod om man ska upptäcka uppenbara buggar och bakdörrar endast genom att pröva saker i protokollet, men däremot tillåter stängd kod bara denna form av förutsättningslös granskning och säkerhetsforskare har gång på gång på gång fått både otrevliga och obehagliga svar av företag som skapar proprietär kod när de väl funnit något problem. De kan bli jagade av jurister och de kan tvingas till tystnad och några som helst garantier för att hålen ska tätas finns inte.

För öppen mjukvara är detta förfarande mer garanterat att bli just öppet och verifierbart. Så jag delar Yooriitzzs mening att man verkligen kan vara glad att denna bugg hittades i öppen källkod. Hur många motsvarigheter som finns i stängd kod som är upptäckta eller åtminstone misstänkta av säkerhetsforskare kan vi faktiskt inte veta, för medan vissa företag givetvis blir glada för rapporterade fel finns det en hel del andra som försöker slåss med jurister för att tysta säkerhetsexpertisen.

Att öppenhet skulle vara en garant för felfri kod är en myt som du har hittat på själv. Så det är en myt att det faktiskt är en myt som förekommer. Öppen kod innehåller inte mindre fel, men felen rättas snabbare och skadeverkningarna och hålen förs i ljuset snabbare. Man ska alltså inte missta publicitet kring buggar och bakdörrar för att det som det är tyst om är säkert.

Vad Yooriitzz avsåg och vad min poäng är framgår tydligt om man följer tråden och vår diskussion. Det är såklart ointressant när det viktiga är att leva upp till rollen som allmänbildad. Du är offer för myten om dig själv.

Hitta en ny infallsvinkel, annars är vi nog klara här.

Visa signatur

There are two kinds of people: 1. Those that can extrapolate from incomplete data.
Min tråkiga hemsida om mitt bygge och lite annat smått o gott: www.2x3m4u.net

Permalänk
Avstängd
Skrivet av Dr.Mabuse:

Vad Yooriitzz avsåg och vad min poäng är framgår tydligt om man följer tråden och vår diskussion. Det är såklart ointressant när det viktiga är att leva upp till rollen som allmänbildad. Du är offer för myten om dig själv.

Hitta en ny infallsvinkel, annars är vi nog klara här.

Har du något att säga i sak, eller vill du bara vara oförskämd?

Det finns inga garantier att detta hade kommit i ljuset lika fort om källkoden hade varit stängd eftersom att upptäcka en bugg bara är halva grejen. Det kan gå lika snabbt för stängd kod, men det är långt från självklart och från fall till fall vet vi att säkerhetsbrister ska bekrigas med jurister och inte öppenhet och review. När säkerhetsproblem hittas av expertis som faktiskt arbetar professionellt med sådant rapporteras det i regel alltid först till företaget eller organisationen bakom programmet och sedan kanske till allmänheten, beroende på företaget eller organisationens respons. Detta är ett rejält problem som experter som arbetar såhär med säkerhetsinformatik faktiskt lever med, ett arbetsmiljöproblem. Detta gör att det finns en bias i vilka program och protokoll man tar sig an eftersom repressalier förekommer. Så återigen är det större chans att problem med öppen källkod upptäcks än i stängd, oavsett metod, och framförallt större chans att kunskapen blir publik. I detta fall rör det sig dock om en/ett sådan stor/t och katastrofal bugg/hål att det inte är lätt att jämföra med annat, men tiden från upptäckt till medienyhet denna gång var blott dagar om jag förstått det rätt. Av praktiska och etiska skäl dröjer man emellertid alltid lite innan man informerar allmänheten för att man ska låta viktiga aktörer patcha problemet innan det är i allmän kännedom. När det gäller stängd kod kan detta dröja åratal och det kan finnas fall vi helt enkelt inte känner till alls (trots att seriöst säkerhetsfolk känner till det. Om det handlar om något som bara en attackerare känner till är det förstås sak samma om det handlar om öppen eller stängd kod).

Du skrev att du inte förstod vad öppen källkod hade med del hela att göra. Well, nu har vi förklarat det för dig ett par gånger. Gott så, eller var din fråga inte ärligt ställd och du bara ute efter polemik?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem
Skrivet av MBY:

Har du något att säga i sak, eller vill du bara vara oförskämd?

Det finns inga garantier att detta hade kommit i ljuset lika fort om källkoden hade varit stängd eftersom att upptäcka en bugg bara är halva grejen. Det kan gå lika snabbt för stängd kod, men det är långt från självklart

och från fall till fall vet vi att säkerhetsbrister ska bekrigas med jurister och inte öppenhet och review. När säkerhetsproblem hittas av expertis som faktiskt arbetar professionellt med sådant rapporteras det i regel alltid först till företaget eller organisationen bakom programmet och sedan kanske till allmänheten, beroende på företaget eller organisationens respons. Detta är ett rejält problem som experter som arbetar såhär med säkerhetsinformatik faktiskt lever med, ett arbetsmiljöproblem. Detta gör att det finns en bias i vilka program och protokoll man tar sig an eftersom repressalier förekommer. Så återigen är det större chans att problem med öppen källkod upptäcks än i stängd, oavsett metod, och framförallt större chans att kunskapen blir publik.

I detta fall rör det sig dock om en/ett sådan stor/t och katastrofal bugg/hål att det inte är lätt att jämföra med annat, men tiden från upptäckt till medienyhet denna gång var blott dagar om jag förstått det rätt. Av praktiska och etiska skäl dröjer man emellertid alltid lite innan man informerar allmänheten för att man ska låta viktiga aktörer patcha problemet innan det är i allmän kännedom. När det gäller stängd kod kan detta dröja åratal och det kan finnas fall vi helt enkelt inte känner till alls (trots att seriöst säkerhetsfolk känner till det. Om det handlar om något som bara en attackerare känner till är det förstås sak samma om det handlar om öppen eller stängd kod).

Du skrev att du inte förstod vad öppen källkod hade med del hela att göra. Well, nu har vi förklarat det för dig ett par gånger. Gott så, eller var din fråga inte ärligt ställd och du bara ute efter polemik?

Jodå, frågan var helt ärligt ställd - i sitt kontex. Polemik blev det när du väljer att vantolka och sätta ord i min mun för att sedan hävda att jag själv skapat en myt som vilken snabb sökning som helst på internet hade kunnat bekräfta. Jag frågar vad andra menar om jag inte tycker att det framgår med all tydlighet. Hade du haft ett genuint intresse att faktisk diskutera ämnet i fråga hade du kunnat fråga mig vad jag menar i stället för att bygga en halmdocka. Orsak och verkan min herre, orsak och verkan...

Allt är visserligen relativt, men mer än två år låter inte speciellt snabbt i mina öron för att hitta en bugg (Heartbleed). Hur statistiken ser ut för annan öppen källkod vet jag inte - och det är en del av problematiken för min del; ingen vet men ändå fortsätter argumenten hagla. Vet du?
Under min tid som Operations Manager för en serverpark hängde jag mycket på en hemsida som listade alla uppdateringar för en rad olika OS (hittar inte länken nu tyvärr) för att se om vi behövde göra något. Flest uppdateringar, både bugg och säkerhetsfixar, kom från Microsoft. För mig är det ett bevis på att proprietär kod inte behöver vara sämre när det kommer till rättningar än öppen kod. Sedan kom en rad olika *nix-distributioner. Nu hävdar jag inte att färre rättningar betyder sämre reaktionsförmåga från respektive distributör, förklaringen kan mycket väl ligga i att *nix är ett mognare system. Apple kom sist (ni får dra era egna slutsattser).

Att det skulle krävas jurister för att få tillstånd rättelser av kod låter mer som undantaget som bekräftar regeln. En illusorisk korrelation baserad på ett mindre antal händelser som fått mindre smickrande uppmärksamhet i media kanske? Dessa händelser borde rimligen framstå som en fjärt i rymden i relation till alla de buggar som faktiskt rättas. För att ta Windows 7 som exempel så medför en installation idag hundratals av säkerhetsuppdateringar. Jag tror inte hundratals artiklar om trakasserier från utpekade företag hade undgått mig. Finns det då ett mörkertal? Ja, kanske men då saknar vi också underlag om dess omfattning.
Innan vi kan uttala oss med säkerhet måste vi ha underlag, innan dess är det bara spekulationer. Ditt resonemang bygger på föreställningen att säkerhetsföretag avstår uppdrag som berör proprietär kod eftersom risken för bl.a. repressalier och andra påtryckningar skulle bli ett arbetsmiljöproblem. Åter igen är det omöjligt att uttala sig om hur stor problem verkligen är.

En yrkeshacker demonstrerade för mig vid en pen-test hur han ganska enkelt kunde ta över kontrollen av både en Cisco PIX och en Firewall One. Buggen rapporterades sedan vidare till både Cisco och Check Point utan vare sig juridiska hot eller repressalier, tvärtom. Cisco tackade. CheckPoint dom.. tja, "kände redan till buggen" (eller hur!). Några betänkligheter att stressa ISA eller andra produkter gav han inte direkt uttryck för så jag betvivlar att det är något utbrett "arbetsmiljöproblem". Att utvecklare vill ha tid att rätta buggar och skydda sina kunder under tiden är knappast konstigt. Att media och obstinata hackare gärna utmålar utvecklare av proprietär kod som ovilliga och inkompetenta är såklart lätt när man sitter på läktaren och inte behöver avhjälpa felet själv. Det utesluter självklart inte att kritik mycket väl kan vara befogat och att ansvariga bör ställas mot väggen. Men varför är det inte samma klang i skällan när det gäller öppen kod? Nej, då är det av "etiska och praktisk skäl". Tillåt mig småle.

Visa signatur

There are two kinds of people: 1. Those that can extrapolate from incomplete data.
Min tråkiga hemsida om mitt bygge och lite annat smått o gott: www.2x3m4u.net

Permalänk
Avstängd
Skrivet av Dr.Mabuse:

Jodå, frågan var helt ärligt ställd - i sitt kontex. Polemik blev det när du väljer att vantolka och sätta ord i min mun för att sedan hävda att jag själv skapat en myt som vilken snabb sökning som helst på internet hade kunnat bekräfta. Jag frågar vad andra menar om jag inte tycker att det framgår med all tydlighet. Hade du haft ett genuint intresse att faktisk diskutera ämnet i fråga hade du kunnat fråga mig vad jag menar i stället för att bygga en halmdocka. Orsak och verkan min herre, orsak och verkan...

Ok, jag frågar dig nu vad du menar? Det _finns_ onekligen säkerhetsfördelar med öppen källkod och säkerhet får aldrig förlita sig på hemlighållen kod. Detta är Kerchoffs princip, "the enemy knows the system". Däremot är det väl ingen som påstår att öppen kod blir säkrare när den kodas ner bara för att den är öppen? Det är så jag tolkar ditt påstående. Så, ja, vänligen förklara du.

Skrivet av Dr.Mabuse:

Allt är visserligen relativt, men mer än två år låter inte speciellt snabbt i mina öron för att hitta en bugg (Heartbleed). Hur statistiken ser ut för annan öppen källkod vet jag inte - och det är en del av problematiken för min del; ingen vet men ändå fortsätter argumenten hagla. Vet du?

Eftersom jag inte gjort några empiriska uttalanden här eller formulerat något påstående om några inneboende skillnader i tid så förstår jag inte riktigt relevansen? Det jag påstod är att öppna protokoll får mer granskning eftersom de är öppna. Det betyder INTE att samma metod inte hittar en bugg i stängd kod precis lika snabbt och jag har heller aldrig påstått det heller. Det jag talade var tiden mellan upptäckt, patchning och publicering, inte hur länge koden har legat och varit öppen. Precis som du har jag ingen stark uppfattning om vad som är en "lång" eller "kort" eller "normal" tid här.

Skrivet av Dr.Mabuse:

Under min tid som Operations Manager för en serverpark hängde jag mycket på en hemsida som listade alla uppdateringar för en rad olika OS (hittar inte länken nu tyvärr) för att se om vi behövde göra något. Flest uppdateringar, både bugg och säkerhetsfixar, kom från Microsoft. För mig är det ett bevis på att proprietär kod inte behöver vara sämre när det kommer till rättningar än öppen kod. Sedan kom en rad olika *nix-distributioner. Nu hävdar jag inte att färre rättningar betyder sämre reaktionsförmåga från respektive distributör, förklaringen kan mycket väl ligga i att *nix är ett mognare system. Apple kom sist (ni får dra era egna slutsattser).

Vem argumenterar du med? Vad argumenterar du emot? Vem har påstått att stängd kod av nödvändighet måste vara sämre när det kommer till att rätta kod? Jag talar enbart om vad man _kan_ uttala sig om mer säkert. Vi kan ha som "lemma" att stängd kod kommer patchas enligt Fpatch(öppen)/Fpatch(stängd) >= 1, alltså att stängd kod kan patchas i precis lika stor utsträckning, men troligtvis inte i högre utsträckning. Det senare är inte omöjligt, men däremot tämligen oplausibelt.

Skrivet av Dr.Mabuse:

Att det skulle krävas jurister för att få tillstånd rättelser av kod låter mer som undantaget som bekräftar regeln. En illusorisk korrelation baserad på ett mindre antal händelser som fått mindre smickrande uppmärksamhet i media kanske? Dessa händelser borde rimligen framstå som en fjärt i rymden i relation till alla de buggar som faktiskt rättas. För att ta Windows 7 som exempel så medför en installation idag hundratals av säkerhetsuppdateringar. Jag tror inte hundratals artiklar om trakasserier från utpekade företag hade undgått mig. Finns det då ett mörkertal? Ja, kanske men då saknar vi också underlag om dess omfattning.

Som sagt, din tes faller vid första motexempel. Och nej, det är ingen fjärt i rymden utan ett rent arbetsmiljöproblem.

Skrivet av Dr.Mabuse:

Innan vi kan uttala oss med säkerhet måste vi ha underlag, innan dess är det bara spekulationer. Ditt resonemang bygger på föreställningen att säkerhetsföretag avstår uppdrag som berör proprietär kod eftersom risken för bl.a. repressalier och andra påtryckningar skulle bli ett arbetsmiljöproblem. Åter igen är det omöjligt att uttala sig om hur stor problem verkligen är.

Jag för en tes som håller så längre problemet är större än noll. Du för ett resonemang som faller så fort problemet är större än noll. Hur kan du bara säga "vi vet inte hur stort problemet är"? Inser du inte att om problemet så är pyttelitet så _existerar_ problemet ändå, vilket är allt jag påstår. Och samma problem gäller inte öppen mjukvara. Däremot kan det finnas andra problem som bara drabbar öppen mjukvara, men jag har aldrig hört talas om något exempel eller övertygande argument här. Det enda man hör är påståenden av folk som aldrig har hört talas om Kerchoffs princip.

Skrivet av Dr.Mabuse:

En yrkeshacker demonstrerade för mig vid en pen-test hur han ganska enkelt kunde ta över kontrollen av både en Cisco PIX och en Firewall One. Buggen rapporterades sedan vidare till både Cisco och Check Point utan vare sig juridiska hot eller repressalier, tvärtom. Cisco tackade. CheckPoint dom.. tja, "kände redan till buggen" (eller hur!). Några betänkligheter att stressa ISA eller andra produkter gav han inte direkt uttryck för så jag betvivlar att det är något utbrett "arbetsmiljöproblem".

Varför tar du russinen ur kakan? Microsoft har en erkänt bra relation och respons till säkerhetsproblem. Men det är liksom inte relevant för mitt resonemang som rör _ditt_ resonemang om att man mer eller mindre kan sätta likhetstecken mellan öppen och stängd kod vad säkerhetspatchning beträffar. Det påståendet faller nämligen vid första bästa motexempel. Jag däremot kommer inte med induktiva teser av detta slag utan har bara försökt förklara varför historien hade kunnat se annorlunda ut med stängd kod. Det är inte så konstigt att en hel del företag som sysslar med proprietär kod hanterar buggar på ett snyggt sätt eftersom de inser att det ligger i deras intresse. Det finns dock företag som _inte_ begriper det, eller gärna _vill_ha_ hål i sina mjukvaror av auktoritativa skäl. Och din nästa anekdotiska bevisföring för din tes som kräver perfekt induktion är Cisco?
Well, en anekdot kan lätt besvaras med en annan: https://www.schneier.com/blog/archives/2005/07/cisco_harasses... och https://www.schneier.com/blog/archives/2005/08/more_lynncisco...
Här är ett annat exempel från hål i centrallåset i bilar: https://www.schneier.com/blog/archives/2013/08/scientists_ban...

Här är mer på samma tema, mycket från hästens mun så att säga:
http://www.darkreading.com/vulnerabilities---threats/more-ven...
https://www.schneier.com/blog/archives/2007/01/debating_full_...
https://www.schneier.com/crypto-gram-0111.html#1 <- Microsoft har inte alltid varit glatt inställda till buggrapportering
https://www.schneier.com/blog/archives/2011/12/recent_develop...
https://www.schneier.com/blog/archives/2011/06/open-source_so... <- Om att problemen med öppen källkod mer handlar om missförstånd och osäkerhet (där man tror att hemlig kod implicerar ett extra säkerhetslager)
https://www.schneier.com/blog/archives/2009/07/the_atm_vulner... <- Upptäckt en bugg i en bankomat? Ja, då ska du hålla truten!
https://www.schneier.com/blog/archives/2008/05/the_ethics_of_... <- Också intressant, handlar mer om etiken kring säkerhetsinform
atik och om vilka metoder av intrång, etc, som hederligt säkerhetsfolk ska ägna sig åt och hur upptäckter ska publiceras och i vilken ordning.
http://www.cerias.purdue.edu/site/blog/post/reporting-vulnera... <- Och här! En hel essä om varför man måste vara modig och vara beredd på en del juridisk (och annan) skit för att vara säkerhetsforskare.
https://www.schneier.com/blog/archives/2008/08/full_disclosur... - citat:
"The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities."

Faktum är att det talas om lagstiftning - så stort är problemet - som tvingar företagen och organisationerna att rapportera såväl säkerhetshål såväl som intrång.

Som sagt, för säkerhetsfolk kan detta vara ett verkligt problem och i slutändan blir det därför allas vårt problem. Om det anses för dyrt att patcha så kan man försöka tysta upptäckaren med advokater.

Säkerhetsinformatik är vetenskap och vi kan inte bara dra slutsatser baserade på anekdoter och allmänt tyckande. Säkerhet kan evidensbaseras. Av vad man kan säga i nuläget, det förefaller som öppen källkod är säkrare än stängd. Av en rad olika skäl. Som en generell tumregel, inte som en alltid gällande lag. Men det går att dra generella slutsatser baserade på akademisk analys och det finns gott om exempel om man vill gotta sig i det. Här är ett fall: https://www.schneier.com/blog/archives/2014/02/the_insecurity...

Förlåt, men det är liksom ingen idé att försöka påstå att stängd kod nominellt sett lika säker som öppen kod och dessutom använda personliga anekdoter för detta. Vi kan naturligtvis inte veta om ett enskilt fall om det hade sett annorlunda ut, lika lite som att vi kan påstå att en specifik man är längre än en specifik kvinna baserad på det statistiska faktumet att män är längre än kvinnor. Så vi kan inte säkert veta om buggen i OpenSSL hade upptäckts tidigare eller senare, ptachats tidigare eller senare (eller ö.h.t.) eller om vi normala användare någonsin hade fått informationen eller inte, om det hade varit stängd kod. Det är ingen mening med att spekulera kontrafaktiskt. Det jag talar om är mer det allmänna fallet: öppen källkod har inte en hel del säkerhetsproblem som exklusivt gäller stängd kod och mig veterligen finns det inga exklusiva säkerhetsproblem för just öppen kod. Det är egentligen hela min poäng. Av detta kan man dra slutsatsen att ja, det hade troligtvis sett annorlunda ut om OpenSSL hade varit proprietärt. Och inte bara det, det finns absolut noll som talar för att buggen hade hanterats bättre om koden hade varit stängd. Nominellt kan vi säga att det hade hanterats likadant eller sämre, men förmodligen inte bättre. Ingenting talar för det. Det enda dina anekdoter visar är att _ibland_ hanterar företag och organisationer bakom stängd kod säkerhetsproblem på ett bra sätt.

Skrivet av Dr.Mabuse:

Att utvecklare vill ha tid att rätta buggar och skydda sina kunder under tiden är knappast konstigt.

Vilket ju var precis därför jag just berättade för dig att det inte var konstigt? Varför låtsas du som att det är din replik? Jo, för att göra ytterligare en tankevurpa lite längre ner:

Skrivet av Dr.Mabuse:

Att media och obstinata hackare gärna utmålar utvecklare av proprietär kod som ovilliga och inkompetenta är såklart lätt när man sitter på läktaren och inte behöver avhjälpa felet själv. Det utesluter självklart inte att kritik mycket väl kan vara befogat och att ansvariga bör ställas mot väggen. Men varför är det inte samma klang i skällan när det gäller öppen kod? Nej, då är det av "etiska och praktisk skäl". Tillåt mig småle.

...och här blir du direkt ohederlig och försöker missrepresentera vad jag skrev. Vad är det du småler åt? Det var JAG som påpekade att det är helt i sin ordning att säkerhetsexpertisen går till företaget eller organisationen först och media sedan. Det är så det bör vara, för annars kan en myriad av nya hot uppkomma innan patchen är ute. Detta gäller naturligtvis för både öppen och stängd kod! Ohederligt av dig att försöka påskina att jag skulle mena något annat än vad jag faktiskt skriver. Det är vad som händer _sedan_ som är intressant. Kommer företaget att försöka belägga upptäckaren med yppandeförbud eller kommer buggen till den allmänna kännedom som man kan kräva? Det är -här- det skiljer sig åt, samt _tiden_ innan patchar kommer.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."