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 et stort ish uptick hos kunder omvendt-engineering vår kode for å forsøke å finne sikkerhetsproblemer i den. Dette er grunnen til at jeg har skrevet mange brev til kunder som starter med "hei, howzit, aloha", men avslutter med "vennligst følg lisensavtalen din 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 gikk ikke bra ut 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, kan det ikke være åpenbart 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, "compilerer" deres interne kildekode til kjørbare filer, og leverer deretter 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 engineering" 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 (EULA) på. Flere enkelt måter å lese og forstå en sluttbruker Lisensavtale (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 der du kan håndheve disse avtalene i alle fall.
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 automatisk gjennomgang 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 bedrifter bruker slik programvare internt til å produsere kode som er mindre sannsynlig å inneholde alvorlige feil.
Oracle's policy 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 godtar Skann rapporter som "bevis på at det er en der, der", delvis fordi du snakker statisk eller dynamisk analyse, er en skannerapport ikke et bevis på en faktisk sårbarhet. [...] Å, og vi krever at kunder / konsulenter ødelegger resultatene av slik omvendt engineering og bekrefter 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 med at kundene kjører dem alene.
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 analysemodulet 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 mot 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 Good Housekeeping seler for (eller" gode 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 respons fra en organisasjon som er 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 viktig 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 eliminering av alle problemene de stiller seg opp, er ikke nok til å ha stor tillit til sikkerheten til koden din, fordi de fleste sårbarheter også er komplisert å 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 de 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 deres kode og insistere på at dette er veien, gå inn i det: hvis du gjør 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 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 nettet. Hvordan finne aktive løksteder og hvorfor du kanskje vil finne ut hvordan du kan finne aktive løksteder Hvorfor du kan ønske å løk nettsteder, så oppkalt fordi de slutter med ".onion", er vert som Tor skjulte tjenester - en helt anonym måte å være vert for nettsteder. 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 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 distribuert og distribuert 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. klager.”
Hvis Oracle ikke vil fortsette å motta tusenvis av problemer funnet av statiske sikkerhetsverktøy, bør de kanskje rette opp de tusenvis av problemene. 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 riktig svar.
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 hos 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!