Fullständig eller ansvarsfull upplysning om hur säkerhetsproblem beskrivs

För tre veckor sedan upptäcktes en allvarlig säkerhetsproblem i OS X 10.10.4. Det är i sig inte särskilt intressant.

Säkerhetsproblem i populära programvarupaket upptäcks hela tiden, och OS X är inget undantag. Säkerhetsdatabasen för öppen källkod (OSVDB) visar minst 1100 sårbarheter taggade som “OS X”. Men vad är Intressant är det sätt på vilket den här sårbarheten avslöjades.

Snarare än att berätta för Apple och ge dem tid att åtgärda problemet, bestämde forskaren att lägga ut sitt utnyttjande på Internet för att alla ska se.

Slutresultatet var en vapen-race mellan Apple och Black Hat Hackare. Apple var tvungen att släppa en plåster innan sårbarheten var vapen och hackarna var tvungna att skapa ett utnyttjande innan risksystemen patchades.

Du kanske tror att den särskilda beskrivningsformen är oansvarig. Du kan till och med kalla det oetiskt eller hänsynslöst. Men det är mer komplicerat än det. Välkommen till den underliga, förvirrande världen av sårbarhetsinformation.

Full vs Responsible Disclosure

Det finns två populära sätt att avslöja sårbarheter för programvaruleverantörer.

Den första kallas full information. Såsom i föregående exempel publicerar forskare omedelbart sin sårbarhet i det vilda, vilket ger leverantörerna absolut ingen möjlighet att släppa en fix.

Den andra heter ansvarig information, eller förskjutna upplysningar. Det är här forskaren kontaktar säljaren innan sårbarheten släpps.

Båda parterna är överens om en tidsram där forskaren lovar att inte publicera sårbarheten för att ge säljaren möjlighet att bygga och släppa en fix. Denna tidsperiod kan vara var som helst från 30 dagar till ett år, beroende på svårighetsgraden och komplexiteten hos sårbarheten. Vissa säkerhetshål kan inte lösas enkelt och kräver att hela mjukvarusystem återuppbyggs från början.

När båda parterna är nöjda med den fix som har producerats, avslöjas sårbarheten och ges ett CVE-nummer. Dessa identifierar unikt varje sårbarhet och sårbarheten arkiveras online på OSVDB.

Men vad händer om väntetiden löper ut? Tja, en av två saker. Säljaren kommer sedan att förhandla om en förlängning med forskaren. Men om forskaren är missnöjd med hur säljaren har svarat eller uppfört sig, eller om de känner att begäran om en förlängning är orimlig, kan de helt enkelt publicera den på nätet utan att göra något klart.

I säkerhetsfältet finns det uppvärmda debatter om vilken metod för offentliggörande som är bäst. Vissa tror att den enda etiska och korrekta metoden är fullständigt avslöjande. Vissa tycker att det är bäst att ge leverantörerna möjlighet att lösa ett problem innan de släpps ut i naturen.

Som det visar sig finns det några övertygande argument för båda sidor.

Argumenten till förmån för ansvarsfullt avslöjande

Låt oss titta på ett exempel på var det var bäst att använda ansvarig information.

När vi pratar om kritisk infrastruktur i samband med Internet är det svårt att undvika att prata om DNS-protokollet. Så här byter du dina DNS-servrar och förbättrar Internet Security. Så här ändrar du DNS-servrar och förbättrar Internet Security. Föreställ dig detta - du vaknar en vacker morgon, häll dig en kopp kaffe och lägg dig sedan på din dator för att komma igång med ditt arbete för dagen. Innan du faktiskt får ... Läs mer. Det här låter oss översätta mänskliga läsbara webbadresser (som makeuseof.com) till IP-adresser.

DNS-systemet är oerhört komplicerat, och inte bara på teknisk nivå. Det finns mycket förtroende i detta system. Vi litar på att när vi skriver in en webbadress skickas vi till rätt plats. Det är helt enkelt mycket ridning på integriteten hos detta system.

Om någon kunde störa eller kompromissa med en DNS-förfrågan finns det mycket potential för skador. De kan till exempel skicka människor till bedrägliga webbsidor på internet, vilket gör det möjligt för dem att få sina online bankinguppgifter. De kunde fånga in deras e-post och online-trafik genom en man-i-mitten attack och läsa innehållet. De skulle kunna undergräva säkerheten för Internet som helhet. Läskiga saker.

Dan Kaminsky är en väl respekterad säkerhetsforskare, med ett långt CV om att hitta sårbarheter i välkänd programvara. Men han är mest känd för 2008 års upptäckt av kanske den mest allvarliga sårbarheten i det DNS-system som någonsin hittats. Detta skulle ha gjort det möjligt för någon att enkelt utföra en cache-förgiftning (eller DNS-spoofing) -attack på en DNS-namnserver. De mer tekniska detaljerna för denna sårbarhet förklarades vid Def Con-konferensen 2008.

Kaminsky, akut medveten om följderna av att släppa en sådan allvarlig fel, bestämde sig för att avslöja det för säljare av DNS-mjukvaran som påverkas av detta fel.

Det fanns ett antal viktiga DNS-produkter som berörs, inklusive de som byggdes av Alcatel-Lucent, BlueCoat Technologies, Apple och Cisco. Problemet påverkade också ett antal DNS-implementeringar som levererades med några populära Linux / BSD-distributioner, inklusive de för Debian, Arch, Gentoo och FreeBSD.

Kaminsky gav dem 150 dagar att producera en fix och arbetade med dem i hemlighet för att hjälpa dem att förstå sårbarheten. Han visste att denna fråga var så allvarlig och den potentiella skadan så stor att det skulle ha varit otroligt hänsynslöst att offentligt släppa det utan att ge säljare möjlighet att utfärda en patch.

För övrigt läcktes sårbarheten av misstag av säkerhetsföretaget Matsano i ett blogginlägg. Artikeln togs ner, men den speglades och en dag efter publicering ett utnyttjande Det här är hur de hackar dig: Den muriga världen av exploateringskit Det här är hur de hackar dig: Den muriga världen av exploateringskit Scammers kan använda programvaru sviter till utnyttja sårbarheter och skapa skadlig programvara. Men vad är dessa utnyttjande kit? Var kommer de ifrån? Och hur kan de stoppas? Läs mer hade skapats.

Kaminskys DNS-sårbarhet summerar i slutändan huvudpunkten i argumentet till förmån för ansvarsfullt, förskjutet avslöjande. Några sårbarheter - som sårbarheter med noll dagsdag Vad är ett Säkerhetsproblem för nolldag? [MakeUseOf Förklarar] Vad är en Säkerhetsproblem för nolldagen? [MakeUseOf Explains] Read More - är så signifikanta att för att offentligt släppa dem skulle orsaka betydande skador.

Men det finns också ett övertygande argument för att inte ge förväg varning.

Fallet för fullständig upplysning

Genom att släppa ut en sårbarhet i det öppna, låser du upp en pandoras låda där oskyddade individer snabbt och enkelt kan producera exploater och kompromissa med sårbara system. Så, varför skulle någon välja att göra det?

Det finns ett par anledningar. För det första är leverantörerna ofta ganska långsamma för att svara på säkerhetsanmälningar. Genom att effektivt tvinga sin hand genom att släppa ut en sårbarhet i naturen, är de mer motiverade att reagera snabbt. Ännu värre, vissa är benägna att inte publicera Varför företag som bryter mot en hemlighet kan vara bra eftersom företag som bryter mot en hemlighet kan vara bra med så mycket information online, oroar vi alla för potentiella säkerhetsbrott. Men dessa överträdelser kan hållas hemliga i USA för att skydda dig. Det låter galet, så vad händer? Läs mer det faktum att de skickade sårbar programvara. Fullständig information tvingar dem att vara ärliga med sina kunder.

Uppenbarligen @PepsiCo bryr sig inte om en vuln på deras webbplats, utan att acceptera oönskad hjälp. Har redan ett seksslag. Jag ska göra fullständig information

- White Packet (@WhitePacket) 4 september 2015

Men det gör det också möjligt för konsumenter att göra ett välgrundat val om de vill fortsätta att använda en viss, sårbar mjukvara. Jag skulle föreställa mig majoriteten skulle inte.

Vad vill leverantörer ha?

Leverantörer tycker verkligen inte om fullständigt upplysande.

Det är trots allt otroligt dåligt PR för dem, och det sätter deras kunder i fara. De har försökt att stimulera människor att avslöja sårbarheter på ett ansvarsfullt sätt, även om det är bug-bounty-program. Dessa har varit anmärkningsvärt framgångsrika, med Google betalar $ 1,3 miljoner dollar i 2014 ensam.

Även om det är värt att påpeka att vissa företag - som Oracle Oracle vill du sluta skicka dem - här är varför det är galet Oracle vill du sluta skicka dem Bugs - Det är därför det är galet Oracle är i varmt vatten över ett missvisat blogginlägg av säkerhetschef , Mary Davidson. Denna demonstration av hur Oracles säkerhetsfilosofi avviker från det vanliga mottogs inte bra i säkerhetsgemenskapen ... Läs mer - Främja människor från att utföra säkerhetsforskning på deras programvara.

Men det kommer fortfarande att vara människor som insisterar på att använda fullständigt upplysande, antingen av filosofiska skäl eller för egen nöje. Inget fel bounty program, oavsett hur generös, kan motverka det.

Utforska mer om: Datorsäkerhet, Hacking.