Oracle möchte, dass Sie aufhören, sie Bugs zu senden - hier ist, warum das verrückt ist

Oracle ist in heißem Wasser über einen fehlgeleiteten Blogpost von Sicherheitschef Mary Davidson. Diese Demonstration, wie Oracles Sicherheitsphilosophie vom Mainstream abweicht, wurde in der Sicherheitsbranche nicht gut aufgenommen ...

Oracle ist in heißem Wasser über einen fehlgeleiteten Blogpost von Sicherheitschef Mary Davidson.  Diese Demonstration, wie Oracles Sicherheitsphilosophie vom Mainstream abweicht, wurde in der Sicherheitsbranche nicht gut aufgenommen ...
Werbung

Oracle ist diese Woche in heißem Wasser über einen Blogpost von ihrer Sicherheitschef Mary Davidson geschrieben. Obwohl es sich um eine Reihe von Themen handelt, handelt es sich bei der Post hauptsächlich um die Meldung möglicher Sicherheitslücken bei Oracle. Genauer gesagt, warum sollten Sie nicht.

"Vor kurzem habe ich einen großen Aufwärtstrend bei Kunden beobachtet, die unseren Code reverse-engineeren, um zu versuchen, Sicherheitslücken darin zu finden. Aus diesem Grund habe ich viele Briefe an Kunden geschrieben, die mit "hi, howzit, aloha" beginnen, aber enden mit "Bitte befolge deine Lizenzvereinbarung und höre auf, unseren Code bereits zu reverse-engineering".

Davidson erklärt, dass es eine wachsende Anzahl von sicherheitsbewussten Kunden gibt, die Oracle-Software auf der Suche nach Sicherheitsschwachstellen rückentwickeln (oder Berater einstellen, um dies für sie zu tun). Davidson beschuldigt diese Kunden, ihre Lizenzvereinbarungen zu verletzen, keine banalen Sicherheitsvorkehrungen zu treffen, zu versuchen, Oracles Job für sie zu tun, und generell schlechte Menschen zu sein. Wenn der Kunde eine echte Sicherheitslücke gefunden hat, wird Oracle diese beheben.

"Ich hasse es fast, diese Frage zu beantworten, weil ich wiederholen möchte, dass Kunden unseren Code nicht rückentwickeln dürfen und dürfen. [...] wir werden einem Kunden, der ein solches Problem (das er durch Reverse Engineering gefunden hat) einen speziellen (einmaligen) Patch für das Problem melden. Wir werden auch keine Kredite in irgendwelchen von uns herausgegebenen Ratschlägen anbieten. Sie können nicht wirklich erwarten, dass wir "Danke, dass Sie die Lizenzvereinbarung gebrochen haben" sagen. "

Das ging in der Sicherheits-Community nicht gut und die Post wurde schnell abgebaut - allerdings nicht bevor sie einen neuen Hashtag Hashtag Activism hervorbrachte: #stark oder #pointless? Hashtag Aktivismus: #stark oder #pointless? #BringBackOurGirls, #ICantBreathe und #BlackLivesMatter haben im vergangenen Jahr eine breite internationale Berichterstattung erfahren - aber sind Hashtags ein effektives Mittel des Aktivismus? Weiterlesen .

"Überprüfen Sie Enigmas EULA zuerst", sagte Alan Turing. #oraclefanfic

- Thorsten Sick (@ThorstenSick) 11. August 2015

Aber wenn Sie mit der Sicherheitswelt nicht vertraut sind, ist es vielleicht nicht offensichtlich, warum der ursprüngliche Beitrag so fehlgeleitet ist. Deshalb werden wir heute darüber sprechen, wo Oracles Sicherheitsphilosophie vom Mainstream abweicht und warum es ein Problem ist.

Die Kontroverse erklären

Also, was genau ist Reverse Engineering, und warum ist Davidson so besorgt darüber? Wenn Oracle eine Software veröffentlicht, kompilieren sie ihren internen Quellcode in ausführbare Dateien und stellen diese Dateien dann an die Kunden bereit. Compilation ist ein Prozess, der lesbaren Code übersetzt (in Sprachen wie C ++ 3 Websites, um mit C ++ zu beginnen Programmiersprache 3 Websites, um mit dem Lernen zu beginnen C ++ Programmiersprache Das Programmieren kann für viele schwierig sein, auch mit relativ einfachen Programmiersprachen Während Java einfacher ist (wir haben hier zahlreiche Artikel bei MakeUseOf für Java sowie ... Read More) in eine dichtere Binärsprache, die direkt in einen Computerprozessor eingespeist werden kann.

Der Quellcode von Oracle ist nicht öffentlich. Dies soll anderen den Diebstahl ihres geistigen Eigentums erschweren. Es bedeutet jedoch auch, dass es für Kunden sehr schwierig ist, zu überprüfen, ob der Code sicher ist. Hier kommt die Dekompilierung ins Spiel. Grundsätzlich übersetzt sich die Dekompilierung in die andere Richtung und wandelt ausführbare Dateien wieder in menschlich lesbaren Code um. Dies liefert nicht genau den ursprünglichen Quellcode, aber es liefert Code, der auf die gleiche Weise funktioniert - obwohl er aufgrund des Verlustes von Kommentaren und organisatorischer Struktur oft schwer zu lesen ist.

Dies ist das "Reverse-Engineering", auf das sich Davidson bezieht. Oracle ist dagegen, weil sie glauben, dass es ihr geistiges Eigentum gefährdet. Dies ist zumindest ein wenig töricht, weil die Verwendung einer Lizenzvereinbarung, um IP-Diebstahl zu verbieten, ein wenig wie die Verwendung einer streng formulierten Fußmatte ist, um eine Heiminvasion zu verhindern. Die Art von Leuten, die versuchen werden, Ihre Produkte zu klonen, interessiert sich nicht für Lizenzvereinbarungen. 4 Möglichkeiten, einen Endbenutzer-Lizenzvertrag (EULA) zu lesen und zu verstehen 4 Möglichkeiten, einen Endbenutzer-Lizenzvertrag (EULA) zu lesen und zu verstehen Einfacher EULAs oder Endbenutzer-Lizenzverträge sind eines der Übel des modernen Lebens. Das sind endlos wortreiche Absprachen, meist in Kleinschrift geschrieben. Dies sind die Dinge, die Sie blind nach unten scrollen, auf der Suche nach diesem verdammten ... Lesen Sie mehr, und oft sind nicht in Jurisdiktionen, wo Sie diese Vereinbarungen in jedem Fall erzwingen können.

Die Menschheit ist zum Scheitern verurteilt ... #oraclefanfic #justoraclethings pic.twitter.com/e6MOZzkkvq

- CyberAnarchist (@ Cyb3rOps) 12. August 2015

Die Richtlinie betrifft nur legitime Kunden. Die Situation ist ähnlich wie beim Videospiel DRM 6 Orte zum Kaufen DRM-freie Spiele [MUO Gaming] 6 Orte zum Kaufen DRM-freie Spiele [MUO Gaming] Da ich beschlossen habe, keine Spiele von Steam zu kaufen, muss ich andere finden Quellen. Viele von ihnen sind eigentlich schlimmer als Steam. Ubisofts Store ist verwirrend und voller nerviger DRM. Electronic Art's ... Read More, aber irgendwie noch wirkungsloser.

Warum sollten Kunden diese ausführbaren Dateien dekompilieren wollen? Es geht um Sicherheit. Durch den Zugriff auf den Quellcode können Sie nach Fehlern und potenziellen Problemen suchen. Dies geschieht häufig mit Hilfe von Software, die eine "statische Code-Analyse" durchführt - ein automatisiertes Durchlesen des Codes, das bekannte Fehler und gefährliche Software-Praktiken identifiziert, die zu Fehlern führen können. Während es Tools gibt, die die ausführbare Datei direkt analysieren, ermöglicht das Dekompilieren allgemein tiefere Analysen. Diese Art der statischen Analyse ist ein Standardwerkzeug des Sicherheitshandels, und die meisten sicherheitsbewussten Unternehmen verwenden solche Software intern, um Code zu produzieren, der weniger schwerwiegende Fehler enthält.

Oracles Politik bei dieser Art von Analyse ist einfach "tue nicht". Warum? Ich werde Davidson das erklären lassen.

"Ein Kunde kann den Code nicht analysieren, um zu sehen, ob es ein Steuerelement gibt, das den Angriff verhindert, über den das Scan-Tool schreit (was höchstwahrscheinlich ein falsches positives Ergebnis ist). [...] Jetzt sollten wir nicht nur akzeptieren Scan-Berichte als "Beweis dafür, dass es da ist, da", zum Teil, weil, ob Sie statische oder dynamische Analyse sprechen, ein Scan-Bericht ist kein Beweis für eine tatsächliche Schwachstelle. [...] Oh, und wir verlangen, dass Kunden / Berater die Ergebnisse eines solchen Reverse Engineering zerstören und bestätigen, dass sie dies getan haben. "

Mit anderen Worten, das Tool, das ein Ergebnis liefert, ist kein Beweis für einen echten Fehler - und da Oracle diese Tools intern verwendet, hat es keinen Sinn, dass Kunden sie selbst ausführen.

Das große Problem dabei ist, dass diese statischen Code-Analyse-Tools nicht nur existieren, um Bugs auf Sie aufmerksam zu machen. Sie sollen auch als Ziel für Code-Qualität und Sicherheit dienen. Wenn Sie die Codebasis von Oracle in ein statisches Standardtool für die Analyse von Industriestandards stapeln und Hunderte von Seiten von Problemen ausspucken, ist das ein wirklich schlechtes Zeichen.

Die richtige Antwort, wenn ein Tool zur Analyse statischer Codes ein Problem ausspuckt, ist nicht, das Problem zu betrachten und zu sagen: "Oh, nein, das verursacht keinen Bug, weil der-und-so". Die richtige Antwort ist, das Problem zu beheben. Die Dinge, die von statischen Codeanalysewerkzeugen gekennzeichnet werden, sind im Allgemeinen schlechte Praktiken, und Ihre Fähigkeit, zu bestimmen, ob ein bestimmtes Problem tatsächlich einen Fehler verursacht, ist fehlbar. Bei Tausenden von Problemen werden Sie Dinge vermissen. Sie sind besser dran, solche Dinge in Ihrer Codebasis überhaupt nicht zu haben.

Hier ist Oculus CTO John Carmack, der diese Tools aus seiner Zeit bei iD Software lobt. (Im Ernst, lesen Sie den ganzen Aufsatz, es ist interessantes Zeug).

"Wir hatten einen Zeitraum, in dem bei einem der Projekte die Option für die statische Analyse versehentlich für ein paar Monate deaktiviert wurde, und als ich es bemerkte und wieder aktivierte, gab es in der Zwischenzeit viele neue Fehler. [...] Das waren Demonstrationen, bei denen die normalen Entwicklungsoperationen fortwährend diese Fehlerklassen hervorbrachten, und [statische Codeanalyse] schützte uns effektiv vor vielen von ihnen. "

Kurz gesagt, es ist wahrscheinlich, dass viele Kunden von Oracle nicht unbedingt versuchen, bestimmte Fehler zu melden - sie fragten, warum die Codierpraktiken von Oracle so schlecht waren, dass ihre Codebasis mit tausenden von Problemen durchsetzt war, die so grundlegend waren, dass sie herausgefiltert werden konnten durch automatisierte Software.

Ich bin immer noch traurig, dass Sun weg ist. Und wer war das Genie, das sie an Oracle verkaufte? Das ist so, als hätte Darth Vader deine Kinder betrogen.

- Brad Neuberg (@bradneuberg) 15. August 2015

Sicherheit durch Aufkleber

Was sollten sicherheitsbewusste Kunden tun, anstatt statische Analysetools zu verwenden? Glücklicherweise war Davidsons Blogpost zu diesem Thema sehr detailliert. Neben der Befürwortung allgemeiner grundlegender Sicherheitspraktiken macht sie konkrete Vorschläge für die Sicherheit der von ihnen verwendeten Software.

"Es gibt eine Menge Dinge, die ein Kunde tun kann, oder mit Lieferanten über ihre Versicherungsprogramme zu sprechen oder Zertifizierungen für Produkte zu prüfen, für die Good Housekeeping Siegel (oder" gute Code "Siegel) wie Common Criteria existieren Zertifizierungen oder FIPS-140-Zertifizierungen. Die meisten Verkäufer - zumindest die meisten der großen, die ich kenne - haben jetzt ziemlich robuste Versicherungsprogramme (wir wissen das, weil wir alle auf Konferenzen miteinander vergleichen). "

Dies ist eine erschreckende Antwort von einer Organisation so groß wie Oracle. Computersicherheit ist ein sich schnell entwickelndes Feld. Immer wieder gibt es neue Schwachstellen, und die Formalisierung der Sicherheitsanforderungen zu einer Zertifizierung, die alle paar Jahre aktualisiert wird, ist absurd. Sicherheit ist kein Aufkleber. Wenn Sie darauf vertrauen, dass eine wichtige Software auf Basis eines Siegels auf der Verpackung sicher ist, sind Sie unverantwortlich dumm.

Verdammt, statische Analysewerkzeuge werden viel häufiger aktualisiert, als es diese Zertifizierungen tun - in manchen Fällen täglich - und alle Probleme zu beseitigen, die sie auftauchen, reicht nicht aus, um viel Vertrauen in die Sicherheit Ihres Codes zu haben, denn die meisten Sicherheitslücken sind es auch Komplex von diesen Arten von automatisierten Tools erkannt werden.

Der einzige Weg, Vertrauen in Ihre eigene Sicherheit zu haben, besteht darin, Ihren Code der Welt offen zu legen und Hacker zu bitten, sie zu brechen. So arbeiten die meisten großen Softwareunternehmen: Wenn Sie ein Problem mit ihrem Code feststellen, werden sie Sie nicht herablassend auf die Verletzung Ihrer Nutzungsvereinbarung hinweisen. Sie werden dir Geld zahlen. Sie wollen, dass die Leute ihr Bestes geben, um ihre Software ständig zu brechen. Nur so können sie sicher sein, dass ihr Code überhaupt sicher ist.

Diese Programme werden als "Bug Bounty" -Programme bezeichnet und sind die beste Lösung für die Sicherheit auf Unternehmensebene. Sie sind auch zufällig etwas, auf das Davidson ziemlich starke Meinungen hat.

"Bug Bounties sind die neue Boygroup (schön alliterativ, nein?) Viele Unternehmen schreien, in Ohnmacht fallen und Unterwäsche an Sicherheitsforscher werfen [...], um Probleme in ihrem Code zu finden und darauf zu bestehen, dass Sie machen keine Bug Bounties, Ihr Code ist nicht sicher.

Ah, wir finden 87% der Sicherheitslücken selbst, Sicherheitsforscher finden 3% und der Rest wird von Kunden gefunden. [...] Ich dulde keine Bug-Bounties, sondern stelle fest, dass ich auf rein ökonomischer Basis viel Geld bei 3% des Problems investieren würde. "

Auf der Grundlage der Ergebnisse dieser statischen Code-Analysen könnte es sich herausstellen, dass es viel mehr als 3% kosten würde, wenn man sie bezahlt. Aber ich schweife ab. Der eigentliche Punkt ist: Bug Boundies sind nichts für dich, sie sind für uns. Könnten Sie Fehler effizienter finden, wenn Sie dasselbe Geld für interne Sicherheitsexperten ausgeben? Nun, wahrscheinlich nicht - aber lass uns Oracle einen Knochen werfen und annehmen, dass sie es könnten. Sie könnten jedoch auch das Geld nehmen, es abzahlen und dann absolut nichts tun. Wenn die resultierende Sicherheit unterdurchschnittlich ist, werden Kunden erst Jahre später erfahren, wenn ihre Sozialversicherungsnummern auf geheimnisvolle Weise im tiefen Web landen. Wie finde ich aktive Onion-Sites & Warum möchten Sie vielleicht aktive Onion-Sites finden? Warum sollten Onion-Sites, die so genannt werden, weil sie mit ".onion" enden, als Tor-Hidden-Services gehostet werden - eine völlig anonyme Möglichkeit, Websites zu hosten. Weiterlesen .

"Es gibt keine Schwachstelle. Die EULA sagt das." #oraclefanfic pic.twitter.com/cUfafDCWbv

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

Bug-Bounties existieren zur Hälfte, weil sie eine wirklich effektive Art sind, Bugs zu erkennen, und zur Hälfte, weil sie eine Art von Sicherheit sind, die man nicht fälschen kann. Ein Bug-Bounty sagt der Welt glaubhaft zu, dass im Code verbliebene Bugs teurer zu finden sind als das angegebene Bounty.

Bug-Bounties existieren nicht zu Ihrer Bequemlichkeit, Oracle, sie existieren, weil wir Ihnen nicht vertrauen.

Wir sollten auch nicht! Viele große Unternehmen lassen die Sicherheit auf der Strecke bleiben, da die zahlreichen Megabroads Target bis zu 40 Millionen US-Kunden Kreditkarten potenziell gehackt Ziel bestätigt bis zu 40 Millionen US-Kunden Kreditkarten potenziell gehackt Ziel hat gerade bestätigt, dass ein Hack kompromittiert werden könnte die Kreditkartendaten für bis zu 40 Millionen Kunden, die zwischen dem 27. November und dem 15. Dezember 2013 in ihren US-Läden eingekauft haben. Lesen Sie weiter, all zu deutlich. Sie sind der zweitgrößte Softwarehersteller der Welt. Es ist absurd, uns zu bitten, Ihr Wort zu nehmen, dass Ihre Produkte sicher sind.

Was Davidson richtig macht

In Fairness gegenüber Davidson gibt es Elemente, die im Kontext vernünftig sind. Wahrscheinlich nehmen viele ihrer Kunden ambitionierte Audits des Oracle-Codes vor, ohne sich die Zeit zu nehmen, alltägliche Sicherheitsprobleme aus ihren Systemen zu entfernen.

"Advanced Persistent Threats" - erfahrene Hacker-Organisationen, die versuchen, Zugang zu bestimmten Organisationen zu erhalten, um Daten zu stehlen - sind sicherlich gruselig, aber durch die Zahlen sind sie viel weniger gefährlich als die Millionen opportunistischer Amateur-Hacker mit automatisierten Tools. Solche statischen Analysen von kommerzieller Software durchzuführen, wenn Sie keine grundlegenden Sicherheitsmaßnahmen getroffen haben, ähnelt der Installation eines Panikraums, wenn Sie noch kein Schloss an der Eingangstür haben.

Ebenso ist es wahrscheinlich frustrierend und wenig hilfreich, immer wieder mit der gleichen automatisierten Analyse konfrontiert zu werden.

Insgesamt zeigt der Artikel jedoch einige ernsthaft veraltete Ideen zur Systemsicherheit und die Beziehung zwischen Entwicklern und Kunden. Ich schätze, dass Davidsons Job frustrierend ist, aber die Benutzer, die sich sehr um die Sicherheit der von ihnen verwendeten Software kümmern, sind nicht das Problem. Hier ist Präsident von Security Awareness, Ira Winkler:

"Oracle ist eine sehr große und reiche Firma mit Produkten, die weit verbreitet sind und für kritische Anwendungen verwendet werden. Zeitraum. Sie haben die Verantwortung, ihre Software so stark wie möglich zu machen. [...] Es kann viele falsche Positive und damit verbundene Kosten geben, aber das ist ein Faktor von [ihrem Verkauf] viel Software, die viele Benutzer hat. Es sind Geschäftskosten. Ich bin sicher, dass alle Softwarefirmen dieselben falschen positiven Berichte haben. Ich höre nicht, Microsoft et al. sich beschweren. "

Wenn Oracle nicht Tausende von Problemen erhalten möchte, die von statischen Sicherheitstools gefunden werden, sollten sie diese Tausenden von Problemen beheben. Wenn sie genervt sind von Leuten, die immer wieder die selben Nicht-Bugs einwerfen, sollten sie vielleicht ein richtiges Bug-Bounty-Programm haben, das Mechanismen für den Umgang mit wiederholten Einreichungen von Nicht-Problemen hat. Die Kunden von Oracle verlangen nach einem höheren Sicherheitsstandard, und es ist nicht die richtige Antwort, sie dafür zu beschämen.

Auch wenn Oracle den Beitrag abgelehnt und im Allgemeinen abgelehnt hat, zeigt das, dass es überhaupt geschrieben wurde, eine zutiefst fehlgeleitete Sicherheitskultur innerhalb von Oracle. Der Sicherheitsansatz von Oracle priorisiert den Schutz seines eigenen geistigen Eigentums vor der Sicherheit und dem Seelenfrieden seiner Kunden - und wenn Sie Oracle-Software mit kritischen Informationen betrauen, dann sollte das Ihnen das Leben schwer machen.

Was denken Sie? Sind Sie besorgt über Oracles Sicherheitsphilosophie? Denkst du, Davidson wird zu hart behandelt? Lass es uns in den Kommentaren wissen!

In this article