Oracle staat deze week in het warme water boven een blogpost geschreven door hun beveiligingschef, Mary Davidson. Het bericht, hoewel het een scala aan onderwerpen behandelt, gaat meestal over de praktijk van het melden van mogelijke beveiligingsproblemen met Oracle. In het bijzonder, waarom zou je dat niet moeten doen.
"Onlangs heb ik gezien dat een grote opleving van klanten onze code reverse-engineering geeft om te proberen er beveiligingskwetsbaarheden in te vinden. Dit is de reden waarom ik veel brieven aan klanten heb geschreven die beginnen met "hi, howzit, aloha" maar eindigen met "voldoe aan uw licentieovereenkomst en stop reverse engineering onze code, al."
Davidson legt uit dat er een groeiend aantal beveiligingsbewuste klanten zijn die reverse-engineering zijn van Oracle-software die op zoek is naar beveiligingskwetsbaarheden (of consultants inhuren om het voor hen te doen). Davidson beschuldigt deze klanten van het schenden van hun licentieovereenkomsten, van het niet nemen van alledaagse veiligheidsmaatregelen, van het proberen te doen van Oracle voor hen, en van het algemeen slechte mensen zijn. Als de klant een echte kwetsbaarheid heeft gevonden, zal Oracle het probleem oplossen.
"Ik heb er bijna een hekel aan om deze vraag te beantwoorden, omdat ik wil herhalen dat klanten onze code niet moeten reverse-engineeren en niet mogen reverse-engineeren. [...] we zullen een klant die een probleem (dat ze via reverse engineering vonden) niet een speciale (eenmalige) patch voor het probleem melden. We geven ook geen krediet in eventuele adviezen die we zouden kunnen geven. Je kunt niet van ons verwachten dat je zegt "bedankt voor het verbreken van de licentieovereenkomst." "
Dit ging niet goed in de beveiligingsgemeenschap en de post werd snel verwijderd, hoewel niet voordat een nieuwe hashtag werd uitgebracht. Hashtag Activism: #powerful of #pointless? Hashtag-activisme: #powerful of #pointless? #BringBackOurGirls, #ICantBreathe en # BlackLivesMatter hebben het afgelopen jaar veel internationale aandacht gekregen - maar zijn hashtags een effectief middel voor activisme? Lees verder .
"Controleer eerst de EULA van Enigma", zei Alan Turing. #oraclefanfic
- Thorsten Sick (@ThorstenSick) 11 augustus 2015
Maar als u niet bekend bent met de beveiligingswereld, is het misschien niet duidelijk waarom het oorspronkelijke bericht zo misleid is. Dus vandaag gaan we praten over waar de veiligheidsfilosofie van Oracle afwijkt van de mainstream en waarom het een probleem is.
De controverse uitleggen
Wat is precies reverse engineering en waarom is Davidson er zo bezorgd over? Kort gezegd, wanneer Oracle een stukje software uitbrengt, "compileren" ze hun interne broncode in uitvoerbare bestanden en vervolgens leveren ze die aan klanten. Compilatie is een proces dat door mensen leesbare code vertaalt (in talen zoals C ++ 3 Websites Aan de slag met leren C ++ Programming Language 3 Websites Aan de slag met leren C ++ Programmeren Taal Leren programmeren kan voor velen moeilijk zijn, zelfs met relatief eenvoudige programmeertalen . Terwijl Java gemakkelijker is om mee aan de slag te gaan (waar we hier talloze artikelen hebben op MakeUseOf voor Java en ... Lees meer) in een dichtere binaire taal die direct in een computerprocessor kan worden ingevoerd.
De broncode van Oracle is niet openbaar. Dit is bedoeld om het voor anderen moeilijker te maken om hun intellectuele eigendom te stelen. Het betekent echter ook dat het erg moeilijk is voor klanten om te controleren of de code veilig is. Dit is waar 'decompilatie' in het spel komt. Kort gezegd vertaalt de-compilatie zich in de andere richting door uitvoerbare bestanden om te zetten in leesbare code. Dit levert niet precies de originele broncode op, maar het levert wel code die op dezelfde manier functioneert - hoewel het vaak moeilijk te lezen is, vanwege het verlies van opmerkingen en de organisatiestructuur.
Dit is de 'reverse-engineering' waar Davidson het over heeft. Oracle is ertegen omdat ze denken dat het hun intellectuele eigendom in gevaar brengt. Dit is op zijn minst een beetje dwaas, omdat het gebruik van een licentieovereenkomst om IP-diefstal te verbieden, een beetje lijkt op het gebruik van een deurmat met een streng geformuleerd wachtwoord om binnendringen van het huis te voorkomen. Het soort mensen dat probeert uw producten te klonen, maakt zich niet druk om licentieovereenkomsten 4 manieren om een licentieovereenkomst voor eindgebruikers (EULA) te lezen en te begrijpen Gemakkelijker 4 Manieren om een eindgebruikerslicentieovereenkomst (EULA) te lezen en te begrijpen Gemakkelijker EULA's of Licentieovereenkomsten voor eindgebruikers zijn een van de kwaden van het moderne leven. Dit zijn eindeloos veelzeggende afspraken, meestal in kleine lettertjes geschreven. Dit zijn de dingen die je blindelings naar beneden scrolt, op zoek naar dat verdomde ... Lees meer en vaak zijn ze niet in rechtsgebieden waar je die overeenkomsten in elk geval zou kunnen afdwingen.
De mensheid is gedoemd ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq
- CyberAnarchist (@ Cyb3rOps) 12 augustus 2015
Het beleid is alleen van toepassing op legitieme klanten. De situatie is vergelijkbaar met die van videogame DRM 6 plaatsen om DRM-vrije games te kopen [MUO Gaming] 6 plaatsen om DRM-vrije games te kopen [MUO Gaming] Aangezien ik heb besloten geen games van Steam te kopen, moet ik andere vinden bronnen. Velen van hen zijn eigenlijk slechter dan Steam zelf. De winkel van Ubisoft is verbluffend en vol vervelende DRM. Electronic Art's ... Lees meer, maar op de een of andere manier zelfs minder effectief.
Waarom zouden klanten dit uitvoerbare bestand willen decompileren? Het draait allemaal om beveiliging. Met toegang tot de broncode kun je er doorheen zoeken op zoek naar fouten en mogelijke problemen. Vaak wordt dit gedaan met behulp van software die een "statische code-analyse" uitvoert - een geautomatiseerde doorlezing van de code, die bekende bugs en gevaarlijke softwarepraktijken identificeert die meestal tot bugs leiden. Hoewel er tools zijn die het uitvoerbare bestand direct analyseren, maakt decompileren het mogelijk voor diepere analyses. Dit soort statische analyse is een standaardtool voor de handel in beveiliging, en de meeste beveiligingsbewuste bedrijven gebruiken dergelijke software intern om code te produceren die minder snel ernstige bugs bevat.
Oracle's beleid voor dit soort analyses is eenvoudigweg "niet doen". Waarom? Ik zal Davidson het uitleggen.
"Een klant kan de code niet analyseren om te zien of er een besturingselement is dat voorkomt dat de aanval door de scanner wordt geschreeuwd (wat hoogstwaarschijnlijk een vals positief bericht is) [...] Ik moet er rekening mee houden dat we niet alleen accepteren scanrapporten als "bewijs dat er een daar is, daar", deels omdat of u het nu hebt over statische of dynamische analyse, een scanrapport geen bewijs is van een daadwerkelijke kwetsbaarheid. [...] Oh, en we eisen van klanten / consultants dat ze de resultaten van dergelijke reverse engineering vernietigen en bevestigen dat ze dit hebben gedaan. "
Met andere woorden, de tool die een resultaat oplevert, is geen bewijs van een echte bug - en aangezien Oracle deze hulpmiddelen intern gebruikt, heeft het geen zin om ze alleen te gebruiken.
Het grote probleem hiermee is dat deze hulpmiddelen voor analyse van statische code niet bestaan om bugs onder uw aandacht te brengen. Ze moeten ook dienen als een doelwit voor de kwaliteit en veiligheid van de code. Als u Oracle's codebasis dumpt in een standaard statische analysetool en honderden pagina's met problemen doorsluist, is dat een heel slecht teken.
De juiste reactie, wanneer een statische codeanalysetool een probleem terugspoelt, is niet om naar het probleem te kijken en te zeggen 'oh nee, dat veroorzaakt geen bug omdat die-en-die.' Het juiste antwoord is om in te gaan en het probleem op te lossen. De dingen die worden gemarkeerd door statische codeanalysetools zijn over het algemeen slechte praktijken in het algemeen en uw vermogen om te bepalen of een bepaald probleem daadwerkelijk een fout veroorzaakt, is feilbaar. Bij duizenden problemen mis je dingen. Het is beter om dergelijke dingen niet in je codebasis te hebben.
Hier is Oculus CTO John Carmack die de lof zingt van deze tools uit zijn tijd bij iD Software. (Serieus, lees het hele essay, het is interessant spul).
"We hadden een periode waarin een van de projecten per ongeluk de optie voor statische analyse een paar maanden had uitgeschakeld en toen ik het zag en weer inschakelde, waren er stapels nieuwe fouten die in de tussentijd waren geïntroduceerd. [...] Dit waren demonstraties dat de normale ontwikkelingsbewerkingen voortdurend deze klassen fouten produceerden, en [statische codeanalyse] beschermde ons effectief tegen veel van hen. "
Kort gezegd is het waarschijnlijk dat veel van de klanten van Oracle niet per se specifieke bugs probeerden te rapporteren - ze vroegen waarom de codeerpraktijken van Oracle zo slecht waren dat hun codebasis met duizenden en duizenden problemen zat, zo eenvoudig dat ze konden worden uitgezocht door geautomatiseerde software.
Ik ben nog steeds bedroefd dat de zon weg is. En wie was het genie dat hen aan Oracle verkocht? Dat is alsof je Darth Vader laat oppassen voor je kinderen.
- Brad Neuberg (@bradneuberg) 15 augustus 2015
Beveiliging door Stickers
Wat moeten klanten met beveiligingsproblemen doen in plaats van statische analysetools te gebruiken? Gelukkig was de blogpost van Davidson erg gedetailleerd over dat onderwerp. Naast het pleiten voor algemene basisbeveiligingspraktijken, doet ze concrete suggesties voor de betrokkenen over de veiligheid van de software die ze gebruiken.
"[T] hier zijn een heleboel dingen die een klant kan doen, gosh, eigenlijk praten met leveranciers over hun verzekeringsprogramma's of het controleren van certificeringen voor producten waarvoor er Good Housekeeping-zegels zijn voor (of" goede code "zegels) zoals Common Criteria certificeringen of FIPS-140-certificeringen. De meeste leveranciers - althans de grote, weet ik - hebben nu vrij robuuste assurance-programma's (we weten dit omdat we allemaal aantekeningen op conferenties vergelijken). "
Dit is een gruwelijke reactie van een organisatie zo groot als Oracle. Computerbeveiliging is een snel evoluerend veld. Er worden voortdurend nieuwe kwetsbaarheden gevonden en het formuleren van beveiligingsvereisten in een certificering die om de paar jaar wordt bijgewerkt, is absurd. Beveiliging is geen sticker. Als je erop vertrouwt dat een stuk cruciale software veilig is op basis van een zegel op de verpakking, ben je onverantwoordelijk dom.
Statische analysetools worden veel vaker bijgewerkt dan deze certificeringen - in sommige gevallen dagelijks - en het elimineren van alle problemen die ze tegenkomen is nog niet genoeg om veel vertrouwen te hebben in de beveiliging van uw code, omdat de meeste kwetsbaarheden te groot zijn. complex om te worden gedetecteerd door dit soort geautomatiseerde hulpmiddelen.
De enige manier om een vertrouwen te hebben in uw eigen veiligheid is door uw code aan de wereld bloot te stellen en hackers te vragen het te breken. Dit is de manier waarop de meeste grote softwarebedrijven werken: als u een probleem met hun code vindt, zullen ze niet neerbuigend naar u snakken vanwege het overtreden van uw gebruiksovereenkomst. Ze zullen je geld betalen. Ze willen dat mensen hun best doen om hun software de hele tijd te breken. Het is de enige manier waarop ze kunnen vertrouwen dat hun code helemaal veilig is.
Deze programma's worden "bug bounty" -programma's genoemd en ze zijn het beste wat er in een lange tijd met beveiliging op bedrijfsniveau gebeurt. Ze zijn ook, toevallig, iets waar Davidson behoorlijk sterke meningen over heeft.
"Bugbounties zijn de nieuwe jongensband (mooi alliteratief, nee?) Veel bedrijven schreeuwen, flauwen en gooien ondergoed naar veiligheidswetenschappers [...] om problemen in hun code te vinden en erop aan te dringen dat This Is The Way, Walk In It: if u doet geen bugbiedingen, uw code is niet beveiligd.
Ach, we vinden zelf 87% van de beveiligingskwetsbaarheden, beveiligingsonderzoekers vinden ongeveer 3% en de rest wordt gevonden door klanten. [...] Ik laat buggelden niet vallen, alleen maar op een strikt economische basis, waarom zou ik veel geld gooien voor 3% van het probleem. "
Om te beginnen, op basis van de resultaten van die statische codeanalyses, kan het blijken dat u veel meer dan 3% bent als u ze betaalde. Maar ik dwaal af. Het echte punt is dit: bug bounties zijn niet voor jou, ze zijn voor ons. Kun je bugs efficiënter vinden als je hetzelfde geld besteedt aan interne beveiligingsexperts? Nou, waarschijnlijk niet - maar laten we Oracle een bot geven en aannemen dat ze het kunnen. Ze konden echter ook het geld nemen, het bankieren en dan helemaal niets doen. Als de resulterende beveiliging sub-pari is, zullen klanten er pas over jaren achter komen wanneer hun sofinummers op mysterieuze wijze op het deep-web terechtkomen. Hoe vind ik actieve uienwebsites en waarom zou u naar actieve uiensites kunnen zoeken & Waarom u misschien wilt dat UI-sites, zo genoemd omdat ze eindigen op ".onion", worden gehost als Tor-verborgen services - een volledig anonieme manier om websites te hosten. Lees verder .
"Er is geen kwetsbaarheid, de EULA zegt het." #oraclefanfic pic.twitter.com/cUfafDCWbv
- Schuyler St. Leger (@DocProfSky) 11 augustus 2015
Bugbounties bestaan voor de helft omdat ze een echt effectieve manier zijn om bugs te identificeren, en de andere omdat ze een vorm van beveiliging zijn die je niet kunt neppen. Een bug bounty vertelt de wereld geloofwaardig dat eventuele fouten in de code duurder zijn om te vinden dan de vermelde bounty.
Bugbounties bestaan niet voor uw gemak, Oracle, ze bestaan omdat we u niet vertrouwen.
Dat zouden we ook niet moeten doen! Veel grote bedrijven zorgen ervoor dat beveiliging buiten spel staat, omdat de talloze megabereikdoelen een bevestiging zijn van maximaal 40 miljoen Amerikaanse klanten Creditcards Potentieel gehackt doel bevestigt maximaal 40 miljoen Amerikaanse klanten Creditcards Potentieel gehackt doel heeft zojuist bevestigd dat een hack gecompromitteerd kan zijn de creditcardgegevens voor maximaal 40 miljoen klanten die tussen 27 november en 15 december 2013 in de winkels in de Verenigde Staten hebben gewinkeld. Lees Meer overzichtelijk weergegeven. U bent de op één na grootste softwarebouwer ter wereld. Het is absurd om ons te vragen om gewoon te geloven dat uw producten veilig zijn.
Wat Davidson goed krijgt
In alle eerlijkheid tegenover Davidson zijn er elementen die redelijk zijn in de context. Waarschijnlijk beginnen veel van hun klanten aan ambitieuze audits van de Oracle-code, zonder de tijd te nemen om meer alledaagse beveiligingsproblemen uit hun systemen te verwijderen.
"Advanced Persistent Threats" - bekwame hackerorganisaties die proberen toegang te krijgen tot specifieke organisaties om gegevens te stelen - zijn zeker eng, maar door de cijfers zijn ze een stuk minder gevaarlijk dan de miljoenen opportunistische amateur-hackers met geautomatiseerde tools. Het uitvoeren van dit soort statische analyses van commerciële software wanneer je geen basisbeveiligingsmaatregelen hebt genomen, lijkt veel op het installeren van een paniekkamer wanneer je nog geen slot op de voordeur hebt.
Evenzo is het waarschijnlijk echt frustrerend en nutteloos om steeds weer dezelfde geautomatiseerde analyse te krijgen.
Over het geheel genomen onthult het artikel echter enkele ernstig verouderde ideeën over systeembeveiliging en de relatie tussen ontwikkelaars en klanten. Ik stel het op prijs dat het werk van Davidson frustrerend is, maar dat gebruikers geen raad weten met de beveiliging van de software die ze gebruiken. Hier is president van Security Awareness, Ira Winkler's kijk erop:
"Oracle is een zeer groot en rijk bedrijf, met producten die wijd verspreid zijn en worden gebruikt voor kritische toepassingen. Periode. Ze hebben de verantwoordelijkheid om hun software zo sterk mogelijk te maken [...] Er kunnen veel valse positieven en bijbehorende kosten zijn, maar dat is een factor van [hun verkoop] veel software met veel gebruikers. Het is een kost om zaken te doen. Ik weet zeker dat alle softwarebedrijven dezelfde fout-positieve rapporten hebben. Ik hoor Microsoft et al. Niet. klagen.”
Als Oracle duizenden problemen die worden gevonden door statische beveiligingshulpmiddelen niet wilt blijven ontvangen, moeten ze misschien die duizenden problemen oplossen. Als ze geïrriteerd zijn door mensen die steeds weer dezelfde niet-bugs gebruiken, moeten ze misschien een goed bugbounty-programma hebben met mechanismen voor het behandelen van herhaalde indieningen van niet-problemen. De klanten van Oracle vragen om een hogere standaard van beveiliging, en ze worden beschaamd omdat het niet het juiste antwoord is.
Hoewel Oracle het bericht heeft verwijderd en in het algemeen de post verworpen heeft, onthult het dat het helemaal is geschreven en onthult een diep misleide beveiligingscultuur binnen Oracle. Oracle's benadering van beveiliging geeft prioriteit aan het beschermen van hun eigen intellectuele eigendom ten opzichte van de veiligheid en gemoedsrust van hun klanten - en als u Oracle-software belangrijke informatie zou geven, zou dat de bejeezus van u moeten afschrikken.
Wat denk je? Maak je je zorgen over Oracle's veiligheidsfilosofie? Denk je dat Davidson te hard wordt behandeld? Laat het ons weten in de reacties!