Oracle vil du slutte å sende dem bugs - her er hvorfor det er galt

Oracle er i varmt vann denne uken over et blogginnlegg skrevet av deres sikkerhetshode, Mary Davidson. Stillingen, selv om den dekker en rekke emner, handler mest om bruken av å rapportere mulige sikkerhetsproblemer til Oracle. Spesifikt, hvorfor burde du ikke.

“Nylig har jeg sett en big-ish uptick hos kunder omvendt-engineering vår kode for å forsøke å finne sikkerhetsproblemer i den. Det er derfor jeg har skrevet mange bokstaver til kunder som starter med “hei, hvordan er det, aloha?” men slutte med “Vennligst følg din lisensavtale og hold igjen omvendt engineering vår kode allerede.”

Davidson forklarer at det er et økende antall sikkerhetsbevisste kunder som er omvendt engineering Oracle-programvare ser etter sikkerhetsproblemer (eller ansetter konsulenter til å gjøre det for dem). Davidson anklager disse klientene for å krenke lisensavtalen, å ikke ta verdslige forholdsregler, forsøke å gjøre Oracles jobb for dem, og at de generelt er Bad People. Hvis kunden har funnet et reelt sikkerhetsproblem, vil Oracle fikse det.

“Jeg hater nesten å svare på dette spørsmålet fordi jeg vil gjenta at kundene burde ikke og må ikke omvendt konstruere koden vår. [...] Vi vil ikke gi en kunde som rapporterer et slikt problem (som de fant gjennom reverse engineering) en spesiell (engangs) oppdatering for problemet. Vi vil heller ikke gi kreditt i noen rådgivning vi kan utstede. Du kan egentlig ikke forvente oss å si “takk for at du har brutt lisensavtalen.””

Dette gjorde det ikke gå over godt i sikkerhetssamfunnet, og innlegget ble raskt tatt ned - selv om det ikke var før en ny hashtag Hashtag Activism: #powerful eller #pointless? Hashtag Activism: #powerful eller #pointless? #BringBackOurGirls, #ICantBreathe, og #BlackLivesMatter har sett stor internasjonal dekning i det siste året - men er hashtags et effektivt virkemiddel for aktivisme? Les mer .

"Sjekk Enigmas EULA først", sa Alan Turing. #oraclefanfic

- Thorsten Sick (@ThorstenSick) 11. august 2015

Men hvis du ikke er kjent med sikkerhetsverdenen, er det kanskje ikke klart hvorfor det opprinnelige innlegget er så misvisende. Så, i dag, skal vi snakke om hvor Oracles sikkerhetsfilosofi går fra det vanlige, og hvorfor det er et problem.

Forklare kontroversen

Så, hva er motsatt engineering, og hvorfor er Davidson så bekymret for det? I utgangspunktet, når Oracle slipper et program, de “kompilere” deres interne kildekode til kjørbare filer, og deretter levere disse filene til kundene. Kompilering er en prosess som oversetter menneskelig lesbar kode (på språk som C ++ 3 nettsteder for å komme i gang med å lære C ++ Programmeringsspråk 3 Nettsteder for å komme i gang med å lære C ++ Programmeringsspråk Læring å programmere kan være vanskelig for mange, selv med relativt enkle programmeringsspråk . Mens Java er lettere å komme i gang med (der vi har mange artikler her på MakeUseOf for Java, så vel som ... Les mer) til et tettere binært språk som kan mates direkte inn i en datamaskinprosessor.

Oracle kildekoden er ikke offentlig. Dette er ment å gjøre det vanskeligere for andre å stjele deres immaterielle rettigheter. Det betyr imidlertid også at det er svært vanskelig for kundene å verifisere at koden er sikker. Dette er hvor "dekompilering" kommer inn i spill. I utgangspunktet oversetter de-kompilering i den andre retningen, og konverterer kjørbare filer tilbake til menneskelig lesbar kode. Dette leverer ikke nøyaktig den opprinnelige kildekoden, men den leverer kode som fungerer på samme måte - selv om det ofte er vanskelig å lese på grunn av tap av kommentarer og organisasjonsstruktur.

Dette er “reverse-ingeniør” som Davidson refererer til. Oracle er imot det fordi de tror det setter sin intellektuelle eiendom i fare. Dette er i det minste litt dumt, fordi bruk av en lisensavtale for å forby IP-tyveri er litt som å bruke en sternt ordnet dørmat for å hindre hjeminvasion. De slags mennesker som skal prøve å klone produktene, bryr seg ikke om lisensavtaler. 4 måter å lese og forstå en sluttbruker lisensavtale på. Flere enkle måter å lese og forstå en sluttbruker lisensavtale for (EULA) Flere enkle EULA eller sluttbrukerlisensavtaler er en av evighetene i det moderne liv. Disse er uendelige ordlige avtaler, vanligvis skrevet i liten utskrift. Dette er de tingene du blindt ruller ned, leter etter det darn ... Les mer, og ofte er ikke i jurisdiksjoner hvor du kunne håndheve disse avtalene i alle tilfeller.

Menneskelighet er dømt ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq

- CyberAnarchist (@ Cyb3rOps) 12. august 2015

Politikken påvirker egentlig bare legitime kunder. Situasjonen ligner den av videospill DRM 6 Steder å kjøpe DRM-gratis spill [MUO Gaming] 6 Steder å kjøpe DRM-gratis spill [MUO Gaming] Siden jeg har bestemt meg for ikke å kjøpe spill fra Steam, må jeg finne andre kilder. Mange av dem er faktisk verre enn damp selv. Ubisofts butikk er forvirrende og full av irriterende DRM. Elektronisk kunst er ... Les mer, men på en eller annen måte enda mer ineffektiv.

Hvorfor vil kunder vil dekompilere disse kjørbare? Det handler om sikkerhet. Å ha tilgang til kildekoden lar deg grave gjennom det på jakt etter feil og potensielle problemer. Ofte gjøres dette ved hjelp av programvare som utfører en “statisk kodeanalyse” - En automatisert gjennomlasting av koden, som identifiserer kjente feil og farlig programvarepraksis som har en tendens til å føre til feil. Selv om det er verktøy som analyserer den kjørbare filen direkte, dekompilerer det muligens generelt dypere analyser. Denne typen statisk analyse er et standardverktøy for handel med sikkerhet, og de fleste sikkerhetsbevisste selskaper bruker slik programvare internt for å produsere kode som er mindre sannsynlig å inneholde alvorlige feil.

Oracles politikk for denne typen analyse er ganske enkelt “ikke.” Hvorfor? Jeg vil la Davidson forklare.

“En kunde kan ikke analysere koden for å se om det er en kontroll som forhindrer angrepet skanneverktøyet skriker om (som sannsynligvis er en falsk positiv) [...] Nå skal jeg merke at vi ikke bare aksepterer skanning rapporterer som “bevis på at det er en der, der,” delvis fordi om du snakker statisk eller dynamisk analyse, er en skannerapport ikke et bevis på en faktisk sårbarhet. [...] Å, og vi krever at kunder / konsulenter vil ødelegge resultatene av slik omvendt prosjektering og bekrefte at de har gjort det.”

Med andre ord, verktøyet som gir et resultat, er ikke et bevis på en ekte feil - og siden Oracle bruker disse verktøyene internt, er det ikke noe poeng for kunder som kjører dem på egenhånd.

Det store problemet med dette er at disse statiske kodeanalyseringsverktøyene ikke eksisterer bare for å bringe bugs til din oppmerksomhet. De skal også tjene som mål for kodekvalitet og sikkerhet. Hvis du dumper Oracles kodebase inn i et statisk standardverktøy for industristandard, og det spytter ut hundrevis av sider med problemer, er det et veldig dårlig tegn.

Det riktige svaret, når et statisk kodeanalyseverktøy spretter tilbake et problem, er ikke å se på problemet og si 'å nei, det forårsaker ikke en feil fordi det er slikt.' Det riktige svaret er å gå inn og fikse problemet. Tingene som er flagget av statiske kodeanalyseværktøy, er vanligvis dårlig praksis generelt, og din evne til å avgjøre om et gitt problem faktisk forårsaker en feil, er feil. Over tusenvis av problemer, du kommer til å savne ting. Du har det bedre å ikke ha slike ting i koden din i utgangspunktet.

Her er Oculus CTO John Carmack som synger rosene til disse verktøyene fra sin tid på iD Software. (Seriøst, les hele essayet, det er interessante ting).

“Vi hadde en periode hvor et av prosjektene ved et uhell fikk det statiske analysealternativet slått av i noen måneder, og da jeg la merke til og aktiverte det, var det haug med nye feil som ble innført i mellomtiden. [...] Dette var demonstrasjoner om at de normale utviklingsoperasjonene kontinuerlig produserte disse klassene av feil, og [statisk kodeanalyse] var effektivt å beskytte oss fra mange av dem.”

Kort sagt, det er sannsynlig at mange av Oracles kunder ikke nødvendigvis forsøkte å rapportere spesifikke feil - de spurte hvorfor Oracles kodingspraksis var så dårlig at deres kodebase ble riddled med tusenvis av tusenvis av problemer så grunnleggende at de kunne bli plukket ut av automatisert programvare.

Jeg er fortsatt trist at Sun er borte. Og hvem var geni som solgte dem til Oracle? Det er som å la Darth Vader babysit barna dine.

- Brad Neuberg (@bradneuberg) 15. august 2015

Sikkerhet ved klistremerker

Så, hva skal sikkerhetsrelaterte kunder gjøre, i stedet for å bruke statiske analyseværktøy? Heldigvis var Davidsons blogginnlegg ekstremt detaljert om dette emnet. Bortsett fra å forsvare generelle grunnleggende sikkerhetspraksis, legger hun konkrete forslag til de som er bekymret for sikkerheten til programvaren de bruker.

“[T] her er mange ting en kunde kan gjøre, gosh, faktisk å snakke med leverandører om deres forsikringsprogrammer eller sjekke sertifiseringer for produkter som det er gode housekeeping seler for (eller “god kode” seler) som Common Criteria-sertifiseringer eller FIPS-140-sertifiseringer. De fleste leverandører - i det minste de fleste av de store ishene jeg kjenner - har ganske robuste forsikringsprogrammer nå (vi vet dette fordi vi alle sammenligner notater på konferanser).”

Dette er en forferdelig svar fra en organisasjon så stor som Oracle. Datasikkerhet er et raskt utviklende felt. Nye sikkerhetsproblemer blir funnet hele tiden, og formalisering av sikkerhetskrav til en sertifisering som blir oppdatert hvert par år er absurd. Sikkerhet er ikke et klistremerke. Hvis du stoler på at en del av avgjørende programvare er sikker på grunnlag av et segl på emballasjen, blir du uansvarlig dum.

Heck, statiske analyseværktøy blir oppdatert mye oftere enn disse sertifiseringene gjør - i noen tilfeller daglig - og eliminerer alle problemene de oppdager fortsatt er ikke nok til å ha stor tillit til sikkerheten til koden din, fordi de fleste sårbarheter er for komplekse til å bli oppdaget av disse typer automatiserte verktøy.

Den eneste måten å ha tillit til din egen sikkerhet er å avsløre koden din til verden, og be hackere å prøve å bryte den. Slik fungerer de fleste store programvareselskaper: Hvis du finner et problem med koden, vil de ikke overbevisende snarke deg for å bryte bruksavtalen din. De betaler deg penger. De vil at folk prøver sitt beste for å bryte programvaren hele tiden. Det er den eneste måten de kan ha tillit til at koden deres er i det hele tatt sikker.

Disse programmene kalles “bug bounty” programmer, og de er det beste å skje med sikkerhet på bedriftsnivå i lang tid. De er også tilfeldigvis noe som Davidson har ganske sterke meninger om.

“Bug bounties er det nye guttebandet (pent alliterende, nei?) Mange bedrifter skriker, besvimer og kaster undertøy hos sikkerhetsforskere [...] for å finne problemer i koden deres og insistere på at dette er veien, gå inn i det: hvis du Gjorde ikke feilgods, koden din er ikke sikker.

Ah, vel, vi finner 87% av sikkerhetsproblemene selv, sikkerhetsforskere finner omtrent 3% og resten er funnet av kundene. [...] Jeg sliter ikke med bug-bounties, bare å merke det på en strengt økonomisk basis, hvorfor skulle jeg kaste meg mye penger på 3% av problemet.”

For det første, basert på resultatene av de statiske kodanalysene, kan det vise seg å være mye mer enn 3% hvis du betalte dem. Men jeg går ned. Det virkelige poenget er dette: Bug bounties er ikke for deg, de er for oss. Kan du finne bugs mer effektivt hvis du brukte samme penger på interne sikkerhetseksperter? Vel, sannsynligvis ikke - men la oss kaste Oracle et bein og anta at de kunne. Imidlertid kunne de også ta pengene, banke det, og gjør absolutt ingenting. Hvis den resulterende sikkerheten er underparent, vil kundene bare finne ut om det år fra nå når deres personnummer slår mystisk opp på den dype banen. Hvordan finne aktive løksteder (og hvorfor du kanskje vil). Hvordan finne en aktiv løk Nettsteder (og hvorfor du kanskje vil) Løksteder er vert på Tor-nettverket. Men hvordan finner du aktive løksteder? Og hvilke er de du skal gå til? Les mer .

"Det er ingen sårbarhet. EULA sier det." #oraclefanfic pic.twitter.com/cUfafDCWbv

- Schuyler St. Leger (@DocProfSky) 11. august 2015

Bug bounties eksisterer halv fordi de er en virkelig effektiv måte å identifisere bugs, og halvparten fordi de er en form for sikkerhet du ikke kan falle. En feilgodtgjørelse forteller troverdig verden at eventuelle feil som er igjen i koden, er dyrere å finne enn den oppgitte summen.

Bug bounties eksisterer ikke for din bekvemmelighet, Oracle, de eksisterer fordi vi ikke stoler på deg.

Vi burde heller ikke! Mange store selskaper tillater sikkerhet å falle ved veikanten, da de mange megabreaches-målene bekrefter opptil 40 millioner amerikanske kunder. Kredittkort Potensielt Hacked Target bekrefter opptil 40 millioner amerikanske kunder. Kredittkort Potensielt Hacked Target har nettopp bekreftet at en hack kunne ha kompromittert Kredittkortinformasjonen for opptil 40 millioner kunder som har handlet i sine amerikanske butikker mellom 27. november og 15. desember 2013. Les Mer viser alt for tydelig. Du er den nest største programvarevaren i verden. Det er absurd å be oss om å bare ta ditt ord om at produktene dine er sikre.

Hva Davidson får rett

I rettferdighet til Davidson er det elementer av dette som er rimelige i sammenheng. Sannsynligvis starter mange av sine kunder ambisiøse revisjoner av Oracles kode uten å ta seg tid til å eliminere mer verdslige sikkerhetsproblemer fra deres systemer.

“Avanserte vedvarende trusler” - dyktige hackerorganisasjoner som prøver å få tilgang til bestemte organisasjoner for å stjele data - er absolutt skummelt, men av tallene er de mye mindre farlige enn de millioner av opportunistiske amatørhackere med automatiserte verktøy. Å gjøre disse typer statiske analyser av kommersiell programvare når du ikke har vedtatt grunnleggende sikkerhetsforanstaltninger, er som å installere et panikkrom når du ikke har en lås på inngangsdøren.

På samme måte er det sannsynligvis virkelig frustrerende og unhelpful å bli presentert med den samme automatiserte analysen igjen og igjen og igjen.

Men som en helhet, avslører artikkelen noen seriøst utdaterte ideer om systemsikkerhet og forholdet mellom utviklere og kunder. Jeg setter pris på at Davidsons jobb er frustrerende, men brukere som går ut av deres måte å kontrollere sikkerheten til programvaren de bruker, er ikke problemet. Her er president for sikkerhetsbevissthet, Ira Winkler tar på seg det:

“Oracle er et veldig stort og rikt selskap, med produkter som er bredt distribuert og brukt til kritiske applikasjoner. Periode. De har et ansvar for å gjøre programvaren så sterk som mulig [...] Det kan være mange falske positiver og tilhørende kostnader, men det er en faktor [som selger] mye programvare som har mange brukere. Det er en kostnad for å gjøre forretninger. Jeg er sikker på at alle programvareselskaper har samme falske positive rapporter. Jeg hører ikke Microsoft et al. klag.”

Hvis Oracle ikke vil beholde tusenvis av problemer funnet av statiske sikkerhetsverktøy, bør de kanskje fikse de tusenvis av problemer. Hvis de er irritert av at folk snu i de samme ikke-feilene igjen og igjen, bør de kanskje ha et skikkelig feilprogram som har mekanismer for å håndtere gjentatte innleveringer av ikke-problemer. Oracles kunder klamrer seg for en høyere sikkerhetsstandard, og skamme dem fordi det ikke er detdet riktige svaret.

Selv om Oracle har tatt ned og generelt disavowed innlegget, ble det skrevet i det hele tatt en dybt misguided sikkerhetskultur innenfor Oracle. Oracles tilnærming til sikkerhet prioriterer å beskytte sin egen intellektuelle eiendom over sikkerhet og ro i sinnet til sine kunder - og hvis du overlater Oracle-programvare med kritisk informasjon, bør det skremme bejeezus ut av deg.

Hva tror du? Er du bekymret for Oracles sikkerhetsfilosofi? Tror du at Davidson blir behandlet for hardt? Gi oss beskjed i kommentarene!

Utforsk mer om: Internett-sikkerhet, programvarelisenser.