Oracle wil dat je stopt met het versturen van die bugs - hier is waarom dat gek is

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 een grote opleving van klanten gezien in het reverse-engineeren van onze code om te proberen er beveiligingskwetsbaarheden in te vinden. Dit is de reden waarom ik veel brieven heb geschreven aan klanten die beginnen “hoi, howzit, aloha” maar eindig met “volg alstublieft uw licentieovereenkomst en stop onze code al reverse engineering.”

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 te 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 nogmaals wil benadrukken 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 echt verwachten dat we het zeggen “bedankt voor het verbreken van de licentieovereenkomst.””

Dit deed niet het goed doen 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, zij “compileren” hun interne broncode in uitvoerbare bestanden en deze vervolgens aan klanten te bezorgen. 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 meerdere artikelen hebben op MakeUseOf voor Java evenals ... 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 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 uw producten probeert 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 je bent vaak niet in jurisdicties 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” - een geautomatiseerde doorlezing van de code, die bekende bugs en gevaarlijke softwarepraktijken identificeert die 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 standaardinstrument voor de handel in beveiliging, en de meeste beveiligingsbewuste bedrijven gebruiken dergelijke software intern voor het produceren van code die minder snel ernstige bugs bevat.

Oracle's beleid voor dit soort analyses is eenvoudig “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) [...] Nu moet ik opmerken dat we niet alleen scannen accepteren rapporteert als “bewijs dat er daar een is,” gedeeltelijk omdat, of u nu spreekt van 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, het hulpprogramma dat een resultaat oplevert, is geen bewijs van een echte bug - en aangezien Oracle deze hulpmiddelen intern gebruikt, heeft het geen zin dat klanten ze zelf 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 analysehulpprogramma 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 het zo en zo'. 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 statische analyse-optie 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 continu deze klassen fouten produceerden, en [statische code-analyse] 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 Sun 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 zeer 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, zoals, echt 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 vertrouwt dat een stuk cruciale software veilig is op basis van een zegel op de verpakking, ben je onverantwoordelijk dom.

Heck, statische analysehulpmiddelen worden veel vaker bijgewerkt dan deze certificeringen - in sommige gevallen dagelijks - en elimineren alle problemen die ze tegenkomen nog steeds is niet voldoende om veel vertrouwen te hebben in de beveiliging van uw code, omdat de meeste kwetsbaarheden te complex zijn om te worden gedetecteerd door dit soort geautomatiseerde hulpmiddelen.

De enige manier om een ​​vertrouwen te hebben in je eigen veiligheid is door je 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 genoemd “bug bounty” programma's en ze zijn het beste wat er in een lange tijd met beveiliging op bedrijfsniveau is gebeurd. Ze zijn ook, toevallig, iets waar Davidson behoorlijk sterke meningen over heeft.

“Bugbounties zijn de nieuwe jongensband (mooi alliteratief, nee?) Veel bedrijven schreeuwen, bezwijken en gooien ondergoed naar beveiligingsonderzoekers [...] om problemen in hun code te vinden en erop aan te dringen dat This Is The Way, Walk In It: if you doen 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 ondermaats is, komen klanten er pas over jaren vanaf wanneer hun sofinummers op mysterieuze wijze op het deep-web terechtkomen. Hoe vind ik actieve uiensites (en waarom zou u dat willen) Actieve ajuin vinden Sites (en waarom u maar wilt) Uienwebsites worden gehost op het Tor-netwerk. Maar hoe vind je actieve Uien-sites? En naar welke moet je gaan? 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 creditcardinformatie voor maximaal 40 miljoen klanten die tussen 27 november en 15 december 2013 in de Amerikaanse winkels 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 van hun systemen te elimineren..

“Gevorderde persistente dreigingen” - 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 hulpmiddelen. Het uitvoeren van dit soort statische analyses van commerciële software wanneer je geen basisbeveiligingsmaatregelen hebt genomen, lijkt veel op het installeren van een paniekruimte 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 kritieke 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 beveiligingstools niet wilt blijven ontvangen, moeten ze dat misschien wel repareer die duizenden problemen. Als ze geïrriteerd zijn door mensen die steeds weer dezelfde niet-bugs inleveren, 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 beveiligingsstandaard en ze worden beschaamd omdat dat niet het geval ishet goede antwoord.

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 toevertrouwt, zou dat de bejeezus uit 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 comments!

Ontdek meer over: Online beveiliging, softwarelicenties.