Oracle ønsker, at du holder op med at sende dem bugs - her er hvorfor det er vanvittigt

Oracle er i varmt vand denne uge over et blogindlæg skrevet af deres sikkerhedschef Mary Davidson. Selvom indlægget dækker en række emner, handler det mest om praksis med at rapportere mulige sikkerhedssårbarheder til Oracle. Specifikt hvorfor du ikke skulle.

“For nylig har jeg set en stor ish uptick i kundernes omvendte konstruktion af vores kode for at forsøge at finde sikkerhedssårbarheder i den. Dette er grunden til, at jeg har skrevet en masse breve til kunder, der starter med “hej, howzit, aloha” men slutt med “skal du overholde din licensaftale og stoppe omvendt konstruktion af vores kode allerede.”

Davidson forklarer, at der er et voksende antal af sikkerhedsbevidste kunder, der er reverse-engineering Oracle-software på udkig efter sikkerhedssårbarheder (eller ansætter konsulenter til at gøre det for dem). Davidson beskylder disse klienter for at have overtrådt deres licensaftaler, for ikke at tage almindelige sikkerhedsforholdsregler, for at forsøge at gøre Oracle's job for dem og for generelt at være dårlige mennesker. Hvis kunden har fundet en reel sårbarhed, mens Oracle ordner det.

“Jeg hader næsten ikke at besvare dette spørgsmål, fordi jeg vil gentage, at kunderne ikke skal og ikke må omvendt konstruere vores kode. […] Vi vil ikke give en kunde, der rapporterer et sådant problem (som de fandt gennem reverse engineering), en speciel (engangs) patch til problemet. Vi giver heller ikke kredit i nogen af ​​de vejledninger, vi måtte udstede. Du kan ikke rigtig forvente, at vi siger det “tak for brud på licensaftalen.””

Dette gjorde ikke gå godt over i sikkerhedsfællesskabet, og indlægget blev hurtigt fjernet - skønt ikke før gyden en ny hashtag Hashtag Activism: # kraftfuld eller # pointless? Hashtag-aktivisme: # kraftfuld eller #pointless? #BringBackOurGirls, #ICantBreathe og #BlackLivesMatter har set en bred international dækning det seneste år - men er hashtags et effektivt middel til aktivisme? .

”Kontroller Enigmas EULA først” sagde Alan Turing. #oraclefanfic

- Thorsten Sick (@ThorstenSick) 11. august 2015

Men hvis du ikke er bekendt med sikkerhedsverdenen, er det måske ikke indlysende, hvorfor det originale indlæg er så vildledt. Så i dag skal vi tale om, hvor Oracle's filosofi om sikkerhed afviger fra mainstream, og hvorfor det er et problem.

Forklaring af kontroversen

Så hvad er egentlig reverse engineering, og hvorfor er Davidson så bekymret over det? Grundlæggende, når Oracle frigiver et stykke software, de “udarbejde” deres interne kildekode i eksekverbare filer, og leverer derefter disse filer til kunderne. Compilation er en proces, der oversætter menneskelig læsbar kode (på sprog som C ++ 3 websteder for at komme i gang med at lære C ++ Programmeringssprog 3 Websteder til at komme i gang med at lære C ++ Programmeringssprog At lære at programmere kan være svært for mange, selv med relativt lette programmeringssprog Mens Java er lettere at komme i gang med (hvor vi har adskillige artikler her på MakeUseOf til Java såvel som ...) til et tættere binært sprog, der kan føres direkte til en computerprocessor.

Oracle's kildekode er ikke offentlig. Dette er beregnet til at gøre det vanskeligere for andre at stjæle deres intellektuelle ejendom. Det betyder dog også, at det er meget vanskeligt for kunder at kontrollere, at koden er sikker. Det er her 'dekompilering' spiller ind. Grundlæggende oversættes de-kompilering i den anden retning og konverterer eksekverbare filer tilbage til menneskelig læsbar kode. Dette leverer ikke nøjagtigt den originale kildekode, men det leverer kode, der fungerer på samme måde - skønt det ofte er vanskeligt at læse på grund af tab af kommentarer og organisationsstruktur.

Dette er “reverse-engineering” som Davidson henviser til. Oracle er imod det, fordi de mener, at det sætter deres intellektuelle ejendom i fare. Dette er i det mindste lidt tåbeligt, for at bruge en licensaftale til at forbyde IP-tyveri er lidt som at bruge en strengt formuleret dørmatte for at forhindre invasion af hjemmet. Den slags mennesker, der vil prøve at klone dine produkter, er ligeglade med licensaftaler 4 måder at læse og forstå en slutbrugerlicensaftale (EULA) lettere 4 måder at læse og forstå en slutbrugerlicensaftale (EULA) Nemmere EULAs eller licensaftaler til slutbruger er en af ​​ondskaberne i det moderne liv. Dette er uendelige kløgtige aftaler, som regel skrevet med et lille tryk. Dette er de ting, du blindt ruller ned og leder efter den darn ... og ofte ikke er i jurisdiktioner, hvor du under alle omstændigheder kunne håndhæve disse aftaler.

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

- CyberAnarchist (@ Cyb3rOps) 12. august 2015

Politikken påvirker virkelig kun legitime kunder. Situationen ligner situationen med videospil DRM 6 steder at købe DRM-gratis spil [MUO gaming] 6 steder at købe DRM-gratis spil [MUO gaming] Da jeg har besluttet ikke at købe spil fra Steam, er jeg nødt til at finde andre kilder. Mange af dem er faktisk værre end Steam selv. Ubisofts butik er forvirrende og fuld af irriterende DRM. Elektronisk kunst…, men på en eller anden måde endnu mere ineffektiv.

Hvorfor ønsker kunder at dekompilere disse eksekverbare? Det handler om sikkerhed. At have adgang til kildekoden giver dig mulighed for at grave igennem det på udkig efter fejl og potentielle problemer. Ofte gøres dette ved hjælp af software, der udfører en “statisk kode analyse” - en automatisk gennemlæsning af koden, der identificerer kendte fejl og farlig softwarepraksis, der har tendens til at føre til fejl. Selvom der er værktøjer, der analyserer den eksekverbare fil direkte, så dekompilerer den mulighed for generelt dybere analyser. Denne form for statisk analyse er et standardværktøj til handel med sikkerhed, og de fleste sikkerhedsbevidste virksomheder bruger sådan software internt til at producere kode, som mindre sandsynligt indeholder store bugs.

Oracle's politik for denne slags analyse er ganske enkelt “gør ikke.” Hvorfor? Jeg lader Davidson forklare.

“En kunde kan ikke analysere koden for at se, om der er en kontrol, der forhindrer angrebet, som scanningsværktøjet skriger om (hvilket sandsynligvis er en falsk positiv) […] Nu skal jeg bemærke, at vi ikke kun accepterer scanning rapporter som “bevis for, at der er en der, der,” til dels fordi uanset om du taler om statisk eller dynamisk analyse, er en scanningsrapport ikke et bevis på en faktisk sårbarhed. […] Åh, og vi kræver, at kunder / konsulenter ødelægger resultaterne af sådan reverse engineering og bekræfter, at de har gjort det.”

Med andre ord er værktøjet, der viser et resultat, ikke et bevis på en rigtig fejl - og da Oracle bruger disse værktøjer internt, er der ingen mening i, at kunder kører dem på egen hånd.

Det store problem med dette er, at disse værktøjer til analyse af statisk kode ikke findes bare for at bringe bugs til din opmærksomhed. De skal også tjene som et mål for kodekvalitet og sikkerhed. Hvis du dumper Oracle's kodebase i et branchestandard statisk analyseværktøj, og det spytter hundrede sider med problemer, er det et rigtig dårligt tegn.

Det rigtige svar, når et statisk kodeanalyseværktøj spytter tilbage et problem, er ikke at se på problemet og sige 'åh nej, det forårsager ikke en fejl, fordi sådan-og-sådan.' Det rigtige svar er at gå ind og løse problemet. De ting, der er markeret med statiske kodeanalyseværktøjer, er normalt dårlig praksis generelt, og din evne til at bestemme, om et givet problem faktisk forårsager en fejl, er fejlbar. Over tusinder af problemer vil du gå glip af ting. Det er bedre for dig at ikke have sådanne ting i din kodebase i første omgang.

Her synger Oculus CTO John Carmack ros for disse værktøjer fra hans tid hos iD Software. (Læs alvorligt hele essayet, det er interessante ting).

“Vi havde en periode, hvor et af projekterne ved et uheld fik den statiske analysemulighed slået fra i et par måneder, og da jeg bemærkede det og aktiverede det igen, var der bunker af nye fejl, der blev introduceret i mellemtiden. […] Dette var demonstrationer af, at de normale udviklingsoperationer kontinuerligt producerede disse klasser af fejl, og [statisk kodeanalyse] effektivt beskyttede os mod mange af dem.”

Kort sagt er det sandsynligt, at mange af Oracle's kunder ikke nødvendigvis forsøgte at rapportere specifikke fejl - de spurgte hvorfor Oracle's kodningspraksis var så dårlig, at deres kodebase blev fyldt med tusinder på tusinder af spørgsmål så basale, at de kunne vælges af automatiseret software.

Jeg er stadig ked af, at Solen er væk. Og hvem var det geni, der solgte dem til Oracle? Det er som at lade Darth Vader babysætte dine børn.

- Brad Neuberg (@bradneuberg) 15. august 2015

Sikkerhed af klistermærker

Så hvad skal sikkerhedsrelaterede kunder gøre i stedet for at bruge statiske analyseværktøjer? Heldigvis var Davidsons blogindlæg ekstremt detaljerede om dette emne. Bortset fra at gå ind for generel grundlæggende sikkerhedspraksis, fremsætter hun konkrete forslag til dem, der er bekymrede for sikkerheden i den software, de bruger.

“[T] her er en masse ting, som en kunde kan lide, f.eks. Snak med leverandører om deres forsikringsprogrammer eller kontrol af certificeringer for produkter, som der er god husholdningssæler til (eller “god kode” sæler) som fælles kriterier-certificeringer eller FIPS-140-certificeringer. De fleste leverandører - i det mindste de fleste af de store ish dem, jeg kender - har nogenlunde robuste forsikringsprogrammer nu (vi ved det, fordi vi alle sammenligner noter på konferencer).”

Dette er en gruopvækkende svar fra en organisation så stor som Oracle. Computersikkerhed er et hurtigt udviklende felt. Nye sårbarheder findes hele tiden, og formalisering af sikkerhedskrav til en certificering, der bliver opdateret hvert par år, er absurd. Sikkerhed er ikke et klistermærke. Hvis du har tillid til, at et stykke afgørende software er sikkert på grundlag af et segl på emballagen, bliver du uansvarligt dum.

Heck, statiske analyseværktøjer bliver opdateret meget hyppigere end disse certificeringer gør - i nogle tilfælde dagligt - og fjerner alle de problemer, de dukker op stadig er ikke nok til at have stor tillid til sikkerheden i din kode, fordi de fleste sårbarheder er for komplekse til at blive opdaget af disse slags automatiserede værktøjer.

Den eneste måde at have tillid til din egen sikkerhed er at udsætte din kode for verden og bede hackere om at prøve at bryde den. Sådan fungerer de fleste store softwarevirksomheder: Hvis du finder et problem med deres kode, snarker de ikke nedladende mod dig for at have overtrådt din brugsaftale. De betaler dig penge. De vil have mennesker, der prøver deres bedste for at bryde deres software hele tiden. Det er den eneste måde, de kan have nogen tillid til, at deres kode overhovedet er sikker.

Disse programmer kaldes “bugbelønning” programmer, og de er den bedste ting, der sker med sikkerhed på virksomhedsniveau i lang tid. De er også tilfældigtvis noget, som Davidson har ret stærke meninger om.

“Bug-gaver er det nye drengeband (pænt alliterativ, nej?) Mange virksomheder skrig, besvimer og kaster undertøj til sikkerhedsforskere […] for at finde problemer i deres kode og insisterer på, at This Is The Way, Walk In It: Hvis du laver ikke fejlbeløb, din kode er ikke sikker.

Ah, ja, vi finder 87% af sikkerhedssårbarheder selv, sikkerhedsforskere finder ca. 3%, og resten findes af kunder. […] Jeg adskiller ikke bugbelønninger, men bemærker bare, at på et strengt økonomisk grundlag, hvorfor skulle jeg kaste en masse penge på 3% af problemet.”

For begyndere, baseret på resultaterne af disse statistiske kodeanalyser, kan det vise sig at være meget mere end 3%, hvis du betalte dem. Men jeg tager af. Det egentlige punkt er dette: bugbelønninger er ikke for dig, de er til os. Kunne du finde fejl mere effektivt, hvis du brugte de samme penge på eksperter med intern sikkerhed? Nå, sandsynligvis ikke - men lad os kaste Oracle en knogle og antage, at de kunne. De kunne imidlertid også tage penge, bankere dem og derefter gøre absolut intet. Hvis den resulterende sikkerhed er underordnet, vil kunderne kun finde ud af det år fra nu, hvor deres sociale sikkerhedsnumre på mystisk vis vinder op på den dybe web. Sådan finder du aktive. Onion Dark Websites (Og hvorfor du muligvis vil) Sådan Find aktive. Onions mørke websteder (og hvorfor du muligvis vil) Den mørke web består delvis af .onion-websteder, der er vært på Tor-netværket. Hvordan finder du dem, og hvor skal man hen? Følg mig… .

"Der er ingen sårbarhed. EULA siger det." #oraclefanfic pic.twitter.com/cUfafDCWbv

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

Bug-belønninger findes halvt, fordi de er en virkelig effektiv måde at identificere bugs på, og halvdelen fordi de er en form for sikkerhed, som du ikke kan forfalde. En bounty-fortælling fortæller troværdigt verden, at eventuelle fejl, der er tilbage i koden, er dyrere at finde end den angivne bounty.

Der findes ikke fejl i bounties for din bekvemmelighed, Oracle, de findes, fordi vi ikke har tillid til dig.

Vi bør heller ikke! Masser af store virksomheder tillader, at sikkerhed falder ved vejen, da de mange megabreaches Mål bekræfter op til 40 millioner amerikanske kunder Kreditkort Potentielt hacket Mål Bekræfter op til 40 millioner amerikanske kunder Kreditkort Potentielt hacket Mål har netop bekræftet, at et hack kunne have kompromitteret kreditkortoplysningerne for op til 40 millioner kunder, der har handlet i sine amerikanske butikker mellem 27. november og 15. december 2013. viser alt for tydeligt. Du er den næststørste softwareproducent i verden. Det er absurd at bede os bare tage ordet om, at dine produkter er sikre.

Hvad Davidson får ret

I retfærdighed overfor Davidson er der elementer af dette, der er rimelige i sammenhæng. Mange af deres klienter begynder sandsynligvis ambitiøse revisioner af Oracle's kode, uden at de tager sig tid til at fjerne mere jordiske sikkerhedsproblemer fra deres systemer.

“Avancerede vedvarende trusler” - dygtige hackerorganisationer, der prøver at få adgang til specifikke organisationer til at stjæle data - er bestemt skræmmende, men med antallet af er de meget mindre farlige end de millioner af opportunistiske amatørhacker med automatiserede værktøjer. At udføre disse slags statiske analyser af kommerciel software, når du ikke har vedtaget grundlæggende sikkerhedsforanstaltninger, er meget som at installere et panikrum, når du endnu ikke har en lås på hoveddøren..

Ligeledes er det sandsynligvis virkelig frustrerende og uhensigtsmæssigt at blive præsenteret for den samme automatiserede analyse igen og igen og igen.

Dog taget som en helhed, afslører artiklen nogle alvorligt forældede ideer om systemsikkerhed og forholdet mellem udviklere og kunder. Jeg værdsætter, at Davidsons job er frustrerende, men brugere, der går ud af deres måde at verificere sikkerheden for den software, de bruger, er ikke problemet. Her er præsident for sikkerhedsbevidsthed, Ira Winklers overtagelse af det:

“Oracle er en meget stor og rig virksomhed med produkter, der distribueres vidt og bruges til kritiske applikationer. Periode. De har et ansvar for at gøre deres software så stærk som muligt […] Der kan være en masse falske positive og tilknyttede omkostninger, men det er en faktor til [deres salg] af en masse software, der har mange brugere. Det koster at drive forretning. Jeg er sikker på, at alle softwarevirksomheder har de samme falske positive rapporter. Jeg hører ikke Microsoft et al. klager.”

Hvis Oracle ikke ønsker at fortsætte med at modtage tusinder af problemer, der findes af statiske sikkerhedsværktøjer, burde de måske gøre det ordne de tusinder af problemer. Hvis de er irriterede over, at folk igen og igen vender de samme ikke-bugs tilbage, skal de måske have et ordentligt bug-bounty-program, der har mekanismer til at håndtere gentagne indsendelser af ikke-problemer. Oracels kunder kæmper for en højere sikkerhedsstandard, og at skamme dem for det er det ikkedet rigtige svar.

Selvom Oracle har taget stilling og generelt afviste stillingen, afslører det, at det overhovedet var skrevet, en dybt vildledt sikkerhedskultur inden for Oracle. Oracle's tilgang til sikkerhed prioriterer at beskytte deres egen intellektuel ejendom i forhold til deres kunders sikkerhed og tryghed - og hvis du overlader Oracle-software til kritisk information, skal det skræmme bejeezusen ud af dig.

Hvad synes du? Er du bekymret for Oracle's filosofi om sikkerhed? Tror du, at Davidson bliver behandlet for hårdt? Fortæl os det i kommentarerne!