Fullständig eller ansvarsfull offentliggörande: Hur säkerhetsproblemen avslöjas

Annons

Tre veckor sedan, en allvarlig säkerhetsfråga i OS X 10.10.4 upptäcktes. Det i sig är inte särskilt intressant.

Säkerhetsproblem i populära programvarupaket upptäcks hela tiden, och OS X är inget undantag. OpenVs Sulnerability Database (OSVDB) visar minst 1100 sårbarheter taggade som ”OS X”. Men vad är intressant är det sätt på vilket denna sårbarhet avslöjades.

Istället för att berätta för Apple och ge dem tid att avhjälpa problemet, bestämde forskaren sig för att publicera sin exploatering på Internet för alla att se.

Slutresultatet var ett vapenkapp mellan Apple och hackare med svart hatt. Apple var tvungen att släppa en lapp innan sårbarheten vapenades, och hackarna var tvungna att skapa en exploit innan riskfyllda system lappas.

Du kanske tror att den särskilda metoden för avslöjande är ansvarslös. Du kan till och med kalla det oetiskt eller hänsynslöst. Men det är mer komplicerat än så. Välkommen till den konstiga, förvirrande världen av avslöjande av sårbarhet.

Fullt mot ansvarsfullt avslöjande

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

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

Den andra heter ansvarsfullt avslöjande, eller förvrängd avslöjande. Det är här forskaren kontaktar leverantören innan sårbarheten släpps.

Båda parter enas sedan om en tidsram där forskaren lovar att inte publicera sårbarheten för att ge leverantören en möjlighet att bygga och släppa en fix. Denna tidsperiod kan vara allt från 30 dagar till ett år, beroende på svårighetsgraden och komplexiteten. Vissa säkerhetshål kan inte fixas enkelt och kräver att hela programvarusystem byggs om från grunden.

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

Men vad händer om väntetiden går 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 tycker att begäran om en förlängning är orimligt, kanske de helt enkelt publicerar det online utan någon fix klar.

Inom säkerhetsfältet är det heta debatter om vilken metod för avslöjande som är bäst. Vissa tror att den enda etiska och korrekta metoden är fullständig avslöjande. Vissa tycker att det är bäst att ge leverantörer möjlighet att lösa ett problem innan de släpper ut i naturen.

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

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

Låt oss titta på ett exempel på var det bäst var att använda ansvarsfullt avslöjande.

När vi pratar om kritisk infrastruktur inom Internet, är det svårt att undvika att prata om DNS-protokollet Hur du ändrar dina DNS-servrar och förbättrar Internet-säkerhetFöreställ dig det här - du vaknar en vacker morgon, häller dig en kopp kaffe och sedan sätter dig vid din dator för att komma igång med ditt arbete för dagen. Innan du faktiskt får ... Läs mer . Det är detta som gör att vi kan ö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 här systemet har mycket förtroende. Vi litar på att när vi skriver in en webbadress kommer vi att skickas till rätt plats. Det går helt enkelt mycket på det här systemets integritet.

Om någon kunde störa eller kompromissa med en DNS-begäran finns det mycket potential för skador. Till exempel kan de skicka människor till bedrägliga onlinebanksidor och därmed låta dem få sina onlinebankuppgifter. De kunde avlyssna sin e-post och onlinetrafik genom en man-i-mitt-attack och läsa innehållet. De kan fundamentalt undergräva säkerheten på Internet som helhet. Läskiga saker.

Dan Kaminsky är en väl respekterad säkerhetsforskare, med en lång CV för att hitta sårbarheter i välkänd programvara. Men han är mest känd för 2008: s upptäckt av kanske mest allvarliga sårbarheten i DNS-systemet 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-förfalskning) attack på en DNS-namnserver. Mer tekniska detaljer om denna sårbarhet förklarades vid Def Con-konferensen 2008.

Kaminsky, medveten om konsekvenserna av att släppa en sådan allvarlig brist, beslutade att avslöja den till leverantörerna av DNS-programvaran som påverkas av detta fel.

Det var ett antal större DNS-produkter som drabbades, inklusive de som byggdes av Alcatel-Lucent, BlueCoat Technologies, Apple och Cisco. Frågan påverkade också ett antal DNS-implementationer som levererades med några populära Linux / BSD-distributioner, inklusive dem 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 den här frågan var så allvarlig och de potentiella skadorna så stora att det skulle ha varit otroligt hänsynslöst att offentliggöra det utan att ge leverantörerna en möjlighet att utfärda en lappa.

För övrigt var sårbarheten läckt av misstag av säkerhetsföretaget Matsano i ett blogginlägg. Artikeln togs ner men den speglades och en dag efter publiceringen en exploit Så här hackar du dig: Den skurkiga världen med exploateringssatserScammers kan använda programvarusviter för att utnyttja sårbarheter och skapa skadlig programvara. Men vad är dessa exploateringssatser? Var kommer de ifrån? Och hur kan de stoppas? Läs mer hade skapats.

Kaminskys DNS-sårbarhet sammanfattar i slutändan kärnan i argumentet till förmån för ansvarsfull, vred information. Vissa sårbarheter - som nolldagars sårbarheter Vad är en sårbarhet i nolldag? [MakeUseOf Explains] Läs mer - är så betydelsefulla att det skulle orsaka betydande skador att offentliggöra dem.

Men det finns också ett tvingande argument till förmån för att inte ge varning på förhand.

Fallet för fullständig avslöjande

Genom att släppa en sårbarhet i det öppna låser du upp en pandoras ruta där obehagliga 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 skäl. För det första är leverantörer ofta ganska långsamma att svara på säkerhetsmeddelanden. Genom att effektivt tvinga handen genom att släppa en sårbarhet i naturen är de mer motiverade att svara snabbt. Ännu värre är vissa benägna att inte offentliggöra Varför företag som håller intrång i hemlighet kan vara ett bra sakMed så mycket information online, oroar vi oss alla för potentiella säkerhetsbrott. Men dessa överträdelser kan hållas hemliga i USA för att skydda dig. Det låter galen, så vad händer? Läs mer det faktum att de levererade sårbar programvara. Full avslöjande tvingar dem att vara ärliga mot sina kunder.

Men det gör det också möjligt för konsumenterna att göra ett informerat val om huruvida de vill fortsätta använda en viss, sårbar programvara. Jag kan föreställa mig att majoriteten inte skulle göra det.

Vad vill leverantörer?

Säljarna gillar verkligen hela avslöjandet.

Det är ju otroligt dålig PR för dem och det sätter deras kunder i riskzonen. De har försökt att stimulera människor att avslöja sårbarheter på ett ansvarsfullt sätt med hjälp av program för bountybounty. Dessa har varit anmärkningsvärt framgångsrika, där Google betalade 1,3 miljoner dollar 2014 ensam.

Även om det är värt att påpeka att vissa företag - som Oracle Oracle vill att du ska sluta skicka dem buggar - varför det är galetOracle är i varmt vatten över ett felaktigt blogginlägg av säkerhetschef Mary Davidson. Denna demonstration av hur Orakles säkerhetsfilosofi avgår från mainstream mottogs inte bra i säkerhetssamhället ... Läs mer - avskräcka människor från att utföra säkerhetsforskning på sin programvara.

Men det kommer fortfarande att finnas människor som insisterar på att använda fullständig avslöjande, antingen av filosofiska skäl eller av sin egen underhållning. Inget bounty-program, oavsett hur generöst, kan motverka det.