it-swarm.com.de

Wie nützlich sind CVE-Einträge?

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 Staaten,

Eine Sicherheitsanfälligkeit bezüglich der Erhöhung von Berechtigungen in der Qualcomm-Kamera kann 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 Analyse, möglicher Patch (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?

27
Holmes.Sherlock

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 welche Auswirkungen Exploits möglicherweise haben . 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.

42
Xander

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 ein Wörterbuch vorstellen und nicht als eine 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 ziemlich deutlich, dass der Fokus auf Standardisierung liegt :

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 statt einer Datenbank
  • Wie unterschiedliche Datenbanken und Tools dieselbe Sprache "sprechen" können
  • Der Weg zu Interoperabilität und besserer Sicherheitsabdeckung
  • Eine Basis für die Bewertung zwischen Tools und Datenbanken

[...]

CVE ist daher 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. Es ist meistens als Übersicht nützlich und um eine eindeutige Kennung zu haben, können Sie den Fehler in einem Patch oder einer Beschreibung beheben.

21
Arminius

CVEs sind in mehrfacher Hinsicht nützlich.

Erstens, und vielleicht am wichtigsten, bieten sie einen gemeinsamen Begriff für eine bestimmte Sicherheitsanfälligkeit. Dies macht es einfach sicherzustellen, dass, wenn jemand sagt "Haben Sie gesehen, dass Android Sicherheitslücke"), Sie über die gleiche Android Sicherheitslücke. Außerdem wird die Suche nach weiteren Informationen zu diesem Problem erheblich vereinfacht.

Zweitens, wenn Sie sich zu NIST-Seite über die Sicherheitsanfälligkeit durchklicken, enthält es CVSS Informationen, die, wenn Sie mit dem Lesen vertraut sind Die Notation macht es einfach, einen schnellen Überblick darüber zu erhalten, wie wichtig es für Sie ist, die Sicherheitsanfälligkeit in Ihrer Umgebung zu beheben.

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, das Sie als Beispiel verwenden, gibt es einen Link zu Android Security Bulletin, das mehr Informationen und Sicherheitsfokus enthält (obwohl nicht viel erwähnt wird). Wenn es einen Exploit gab verfügbar, dann ist es wahrscheinlich nicht geteilt.

2
NASAhorse

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 untersuchen, ob Exploits dafür verfügbar sind, indem Sie beispielsweise Exploit-db.com verwenden. Exploits werden nicht immer im CVE aufgeführt, daher ist eine sorgfältige Prüfung erforderlich.

1
Godzilla74

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 es, wie ich zeigen werde, lange dauert, das tatsächliche Installationen zu patchen.

In einer theoretischen Welt werden Patches sofort auf allen Geräten bereitgestellt. Dies garantiert, dass alle Geräte gepatcht und geschützt sind. Das ist unmöglich.

Wählen Sie Android ...

  • T0: Eine Sicherheitslücke 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 Business-Gerä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 bis T100: Alle Apache-Instanzen werden auf den Unternehmenssystemen aktualisiert, wobei Lieferanten und Manager einen Testplan einhalten und planen müssen

Zusamenfassend

CVEs sind nützlich, um festzustellen, "wie alt" und "wie riskant" eine Software ist. Durch Untersuchen 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 gibt es eine intrinsische Langsamkeit beim Software-Upgrade. Ich sehe Banken laufen Java <= 1.5 (wieder nicht später als 1.5), weil spätere Versionen nicht zertifiziert wurden und Java 1.7 ist bereits das Ende des Lebens. Wir wissen, dass Unternehmen immer noch XP laufen, weil sie nicht wissen, ob alle ihre vorhandene Software-Basis läuft unter Windows 7, nicht einmal wagen 10 zu versuchen.

Ein schwerer CVE kann meiner Erfahrung nach der Grund sein, einem Software-Upgrade in einem strukturierten Unternehmensszenario Priorität einzuräumen.