Frage:
Wie nützlich sind CVE-Einträge?
Holmes.Sherlock
2017-02-10 00:05:57 UTC
view on stackexchange narkive permalink

Die meisten CVE-Einträge werden nicht durch eine vollständige Erläuterung des Fehlers selbst ergänzt, auch nicht durch einen Proof-of-Concept, der den Fehler demonstriert. Alles, was sie haben, ist eine sehr hochrangige, abstrakte Beschreibung möglicher Nebenwirkungen, z. CVE-2016-8412 gibt an,

Eine Sicherheitsanfälligkeit bezüglich der Erhöhung von Berechtigungen in der Qualcomm-Kamera könnte es einer lokalen böswilligen Anwendung ermöglichen, beliebigen Code im Kontext des Kernels auszuführen. Dieses Problem wird als hoch eingestuft, da zunächst ein privilegierter Prozess kompromittiert werden muss. Produkt: Android. Versionen: Kernel-3.10, Kernel-3.18. Android ID: A-31225246. Referenzen: QC-CR # 1071891.

Die Beschreibung enthält keine nützlichen Informationen, z. der anfällige Quellblock (weil es Android ist), relevante Analysen, mögliche Patches (optional) usw. Sind diese Arten von CVEs aus Sicht der Sicherheitsforschung überhaupt nützlich? Dienen sie einem wirklichen Zweck, abgesehen davon, dass sie möglicherweise ein Index dafür sind, wie fehlerhaft eine Software ist?

Sie scheinen enttäuscht zu sein, dass andere Sicherheitsforscher nicht das gesamte Internet auf einer Platte ausnutzen.Ich vermute, Sie sollten froh sein, dass dies so ist, weil Sie sonst möglicherweise persönlich belästigt worden wären.Auch Diffs sind Gold;)
@J.A.K.Überhaupt nicht enttäuscht.Ein gepatchter CVE (der alle öffentlichen CVEs sind) ist nur für Forschungszwecke von Nutzen
Was ist mit Geldautomaten, auf denen noch XP ausgeführt wird?
Es ist nicht nur Windows XP.Es gibt noch viele Systeme und Dienste, es ist traurig, aber es ist so.
"sogar ein [PoC]" der "gerade" Teil impliziert, dass er unter den Erwartungen liegt.Und ja, die Geldautomaten waren nur ein herausragendes Beispiel für CVEs mit verfügbaren Patches, die in freier Wildbahn praktisch sind.
Sie sind meistens nicht sehr nützlich.Sie werden auf den meisten Websites (einschließlich NIST und MITRE) häufig nur als "reserviert" angezeigt, es fehlen Links zu bestimmten Patches / Commits, die das Problem beheben, und sie sind im Allgemeinen nur relevant, wenn ein bestimmter "Anbieter" (oder eine bestimmte Distribution) ihre eigenen hinzufügtInformationen selbst, aber definitiv nicht hilfreich für Distributionen (insbesondere kleinere) oder andere, um herauszufinden, ob sie betroffen sind, was zurückportiert werden soll usw.
Sechs antworten:
#1
+42
Xander
2017-02-10 00:19:38 UTC
view on stackexchange narkive permalink

Sie sind nützlich, sie sind einfach nicht nützlich, um Exploits zu erstellen. Sie sind auch nicht nützlich, um festzustellen, wie fehlerhaft eine Software ist ... Die Anzahl der CVEs hat keine starke Korrelation mit der Codequalität.

Sie sind nützlich, um als Administrator festzustellen, ob die Versionen eines bestimmten Softwarepakets, das Sie verwenden, für bestimmte bekannte Exploits gepatcht wurden und welches Potenzial besteht Auswirkungen von Exploits, die entdeckt wurden. Auf diese Weise können sie als eines der vielen Tools, mit denen Sie sicherstellen können, dass Ihr Unternehmen das Software-Sicherheitsrisiko ordnungsgemäß verwaltet, direkt in einen Schwachstellenmanagementprozess einfließen.

#2
+21
Arminius
2017-02-10 03:25:47 UTC
view on stackexchange narkive permalink

Der Hauptanwendungsfall für CVE besteht darin, eindeutige Kennungen für Software-Schwachstellen zu haben. Es ist kein gutes Tool, um die Gesamtsicherheit eines Produkts zu messen, und hilft Ihnen nicht bei der eingehenden Analyse eines Fehlers.

Sie sollten sich CVE als Wörterbuch vorstellen Anstelle einer Datenbank, die Schwachstellen Standardnamen zuweist, damit Sie systemübergreifend eindeutig auf sie verweisen können. Machen Sie nicht den Fehler anzunehmen, dass ein CVE-Eintrag eine vollständige Erklärung einer Sicherheitsanfälligkeit oder eine genaue Abschätzung der Auswirkungen enthält.

Die Seite Über CVE macht dies ziemlich deutlich Der Schwerpunkt liegt auf Standardisierung 1:

CVE ist:

  • Ein Name für eine Sicherheitsanfälligkeit oder Gefährdung
  • Eine standardisierte Beschreibung für jede Sicherheitsanfälligkeit oder Gefährdung
  • Ein Wörterbuch anstelle einer Datenbank
  • Wie unterschiedliche Datenbanken und Tools dieselbe Sprache "sprechen" können
  • Der Weg zu Interoperabilität und besserer Sicherheitsabdeckung
  • Eine Grundlage für die Bewertung zwischen Tools und Datenbanken

[...]

Also CVE ist nicht als umfassende Datenbank aller bekannten Schwachstellen in einem Produkt gedacht, da die Einträge weder von Dritten überprüft noch unbedingt vollständig sind. Dies ist vor allem als Übersicht nützlich. Um eine eindeutige Kennung zu erhalten, können Sie den Fehler in einem Patch oder einer Beschreibung beheben.

Dies ist eine großartige Antwort.CVE bietet nicht nur ein gemeinsames Vokabular für Menschen, das bei der Erörterung von Schwachstellen verwendet werden soll, sondern hat auch das Ziel, präzise Kennungen für Maschinen bereitzustellen, die beim Austausch von Schwachstelleninformationen verwendet werden können.Tatsächlich ist es Teil eines viel größeren Programms namens [Security Content Automation Protocol] (https://en.wikipedia.org/wiki/Security_Content_Automation_Protocol), das von der Sicherheitsgemeinschaft des privaten Sektors leider weitgehend übersehen wurde.
Erwähnenswert ist, dass CVE in direktem Zusammenhang mit CVSS und CWE steht, was die Kritikalität der Sicherheitsanfälligkeit und eine standardisierte Beschreibung der Schwachstellen selbst zeigt.Dies kann für andere Zwecke verwendet werden und kann verwendet werden, um die Akzeptanz von Software basierend auf der Risikobereitschaft des Betrachters zu bewerten.
#3
+12
Xiong Chiamiov
2017-02-10 00:23:05 UTC
view on stackexchange narkive permalink

CVEs sind in mehrfacher Hinsicht nützlich.

Erstens und vielleicht am wichtigsten bieten sie einen gemeinsamen Begriff für eine bestimmte Sicherheitsanfälligkeit. Auf diese Weise können Sie auf einfache Weise sicherstellen, dass Sie von der gleichen Android-Sicherheitsanfälligkeit sprechen, wenn jemand sagt, dass Sie diese Android-Sicherheitsanfälligkeit gesehen haben. Dies vereinfacht auch die Suche nach weiteren Informationen zu diesem Problem erheblich.

Wenn Sie sich auf der Seite von NIST zur Sicherheitsanfälligkeit durchklicken, werden CVSS -Informationen angezeigt Wenn Sie mit dem Lesen der Notation vertraut sind, können Sie sich schnell einen Überblick darüber verschaffen, wie wichtig es für Sie ist, die Sicherheitsanfälligkeit in Ihrer Umgebung zu beheben.

#4
+2
NASAhorse
2017-02-10 00:43:57 UTC
view on stackexchange narkive permalink

CVEs sind für mich ein bisschen wie Wörterbuchbegriffe. Es soll in der Lage sein, über eine gemeinsame Aufzählung leicht zu kommunizieren, was etwas ist.

Weitere Informationen dazu, warum sie so geschrieben sind, finden Sie unter https://cve.mitre.org/about/. faqs.html # b4

Ein guter CVE bezieht sich auf OpenSSL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE -2016-6304

Die Beschreibung ist kurz, aber die Seite verweist auf relevante Referenzen, die den CVE weiter erweitern.

In dem CVE, den Sie als verwenden Beispiel: Es gibt einen Link zum Android Security Bulletin, der mehr Informationen und Sicherheitsfokus enthält (obwohl nicht viel erwähnt wird). Wenn ein Exploit verfügbar war, wird er wahrscheinlich nicht freigegeben.

#5
+1
Godzilla74
2017-02-10 00:31:27 UTC
view on stackexchange narkive permalink

Wie bereits gesagt, sind sie nützlich ... es kommt nur darauf an, was Sie tun möchten. Wenn Sie eine Sicherheitsüberprüfung durchführen, wie ich mich meiner Antwort nähere, ist es wichtig, einen Ausgangspunkt zu haben. Wenn Sie etwas wie Nessus oder OpenVAS ausführen, werden Sie feststellen, dass ein bestimmtes CVE mit einem Host korreliert. Von dort aus müssen Sie mithilfe von Exploit-db.com untersuchen, ob Exploits dafür verfügbar sind. Exploits werden nicht immer im CVE aufgeführt, daher ist eine sorgfältige Prüfung erforderlich.

#6
  0
usr-local-ΕΨΗΕΛΩΝ
2017-02-10 17:56:55 UTC
view on stackexchange narkive permalink

CVEs sind für alle Akteure in der Softwarekette (Entwickler, Systemadministratoren, Kunden ...) nützlich, um zu entscheiden, ob Maßnahmen gegen vorhandene Software ergriffen werden sollen oder nicht. Proof of Concepts werden absichtlich redigiert, da das Patchen der tatsächlichen Installationen , wie ich zeigen werde, sehr lange dauert.

In einer theoretischen Welt werden Patches sofort bereitgestellt alle Geräte. Dies garantiert, dass alle Geräte gepatcht und geschützt sind. Dies ist nicht möglich.

Wählen Sie Android ...

  • T0: Eine Sicherheitsanfälligkeit im Linux-Kernel, die sich auf den Android-Kernel auswirkt, wurde gefunden und gepatcht
  • T1: Google patcht AOSP und veröffentlicht den Patch.
  • T2: Mobilfunkhersteller (z. B. LG, Motorola, Samsung) erhalten den Patch und wenden ihn auf ihren benutzerdefinierten Build an.
  • T3: Der Patch wird OTA an Verbraucher geliefert
  • T4: Ein Unternehmen mit Tausenden von Android-Geschäftsgeräten desselben Herstellers stellt das Update für die Arbeitsgeräte bereit.

Wählen Sie Apache ...

Dies ähnelt einem Fall, der mir während meiner Arbeit passiert ist.

  • T0: Eine Sicherheitslücke in Apache wurde gefunden und gepatcht. Apache wird freigegeben.
  • T1 : Ein großes Unternehmen, das Apache für viele Anwendungen verwendet, die intern auf verschiedenen Servern installiert sind, plant das Upgrade
  • T2 auf T100: Alle Apache-Instanzen werden auf den Unternehmenssystemen aktualisiert, wobei Lieferanten und Manager sich treffen und planen müssen ein Testplan

Kurz gesagt,

CVEs sind nützlich, um de Termine "wie alt" und "wie riskant" eine Software ist. Durch die Prüfung des Schweregrads und der betroffenen Komponenten können die IT-Mitarbeiter entscheiden, ob sie beispielsweise vorerst kein Upgrade durchführen, sofort ein Upgrade durchführen und zusätzliche temporäre Sicherheitsmaßnahmen anwenden möchten (z. B. Firewall, Proxy).

In der Unternehmenswelt Das Software-Upgrade weist eine intrinsische Langsamkeit auf. Ich sehe Banken, auf denen Java < = 1.5 ausgeführt wird (wieder nicht später als 1.5 ), weil spätere Versionen nicht zertifiziert wurden und Java 1.7 bereits nicht mehr verfügbar ist. Wir wissen, dass Unternehmen immer noch XP ausführen, weil sie nicht wissen, ob ihre gesamte vorhandene Softwarebasis unter Windows 7 ausgeführt wird, und es nicht einmal wagen, 10 zu versuchen.

Meiner Erfahrung nach kann ein schwerer CVE der Grund sein um ein Software-Upgrade in einem strukturierten Unternehmensszenario zu priorisieren.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...