Sicherheit im Kontext: Wann ist eine CVE keine CVE?

Bei Snyk gibt es einige grundlegende Prinzipien, an denen wir unsere Überlegungen und Entscheidungen rund um Sicherheit ausrichten.

Erstens ist es immer wichtig zu verstehen, vor wem wir uns schützen, denn davon hängt ab, wie wir handeln müssen. Ein Beispiel: Wenn unser Artefakt ein Webserver ist, müssen wir ihn vor nicht vertrauenswürdigen Nutzern schützen. Handelt es sich dagegen um Verschlüsselungssoftware, müssen wir sie selbstverständlich sogar vor Nutzern mit physischem Zugriff auf das System schützen. In jedem dieser Fälle grenzen wir klar ab, wo die Risikogrenze verläuft und worauf wir unsere Aufmerksamkeit richten müssen.

Zweitens gilt: Die Konfiguration ist Teil Ihrer Codebasis. Hat ein Angreifer Zugriff auf Ihre Konfiguration, ist das im Grunde dasselbe, als hätte er Zugriff auf Ihre Codebasis.

Angesichts der Flut verwundbarer Systeme infolge der jüngsten Log4j-2.x-Sicherheitslücke (Log4Shell) ist es verständlich, dass wir als Community immer genauer nach weiteren potenziellen Schwachstellen suchen. Vielleicht sollten wir diese Gelegenheit jedoch auch nutzen, um innezuhalten und nachzudenken, bevor wir jedes potenzielle Sicherheitsproblem in unserem Code vorschnell bewerten. Besonnenere Stimmen könnten zudem darauf hinweisen, dass nicht alles, was Sicherheitsprobleme verursacht, zwangsläufig gleich eingestuft werden sollte.

Ein Beispiel dafür ist die kürzlich erfolgte Zuweisung von CVE-2021-4104 für Log4j 1.x, die sich aus dieser Perspektive betrachten lässt. Für einen Angriff wäre direkter Zugriff auf die Konfigurationsdateien erforderlich, um Einstellungen zu ändern. Ähnliche Diskussionen gibt es inzwischen auch rund um das Projekt Logback sowie in der Node-Community.

Machen wir uns nichts vor: Potenzielle Schwachstellen aufzudecken, ist nach wie vor etwas Gutes. Doch inmitten der medialen Panik ist es auch angebracht, unser eigenes kritisches Denken zu hinterfragen und in der Community erneut gemeinsame Maßstäbe dafür festzulegen, worauf wir uns konzentrieren sollten. Eine weitere Flut potenzieller Schwachstellen kann mehr schaden als nützen: Sie überlastet Sicherheitsteams, die ohnehin schon unter Druck stehen, noch stärker und erschwert die laufenden Branchenbemühungen, Open-Source-Software sicherer zu machen.

CVE kritisch hinterfragen

Die in den obigen Diskussionen angesprochenen Themen werfen einige sehr interessante Fragen auf.

Wenn eine Schwachstelle nur ausgenutzt werden kann, wenn man privilegierten Zugriff auf Dateien innerhalb eines Systems hat: Handelt es sich dann wirklich um eine Schwachstelle? Nahezu jede moderne Software, die über einfache Funktionen hinausgeht, lässt sich so konfigurieren, dass sie unsicher betrieben werden kann. Ein vergleichbares Beispiel wäre, sshd so zu konfigurieren, dass Anmeldungen mit leeren Passwörtern möglich sind. Sollten wir das als neuartige Schwachstelle in sshd betrachten?

Unser Sicherheitsteam nutzt unter anderem den Ansatz, erwartetes und unerwartetes Verhalten voneinander zu unterscheiden. Wenn sich eine Software so konfigurieren lässt, dass sie Remote-Code ausführt, und diese Funktion gut dokumentiert ist, stellt dieses Verhalten dann eine ausnutzbare Schwachstelle dar? Man könnte argumentieren, dass es sich um erwartetes Verhalten und nicht per se um eine Sicherheitslücke handelt.

Sollten wir Software so entwickeln, dass sie keine konfigurierbaren Modi bietet, die unsicher sind? Das mag ein erstrebenswertes Ziel sein, steht aber in gewissem Widerspruch zur Entwicklung von Open-Source-Software in den vergangenen 30 Jahren und mehr. Typische Entwicklungsziele für Open-Source-Software waren größtmögliche Konfigurierbarkeit, um alle Anwendungsfälle abzudecken. Sinnvolle sichere Standardeinstellungen sind in den letzten Jahren zu einem nachrangigen Ziel geworden. Das Grundprinzip war jedoch stets, Nutzern die Möglichkeit zu geben, die Software nach eigenem Ermessen zu konfigurieren – ob sicher oder nicht.

Wir leben heute außerdem in einer Welt, in der CVEs sowohl von Einzelpersonen als auch von Unternehmen leicht gemeldet werden können und zugleich wertvoll sind, weil sie mit Glaubwürdigkeit und Ansehen verbunden sind. Diese einzigartige Kombination kann durchaus zu fragwürdigen Zuweisungen führen. Andererseits kann es nur positiv sein, potenzielle Sicherheitsprobleme ohne Hürden melden zu können. So stehen wir vor einem gewissen Paradoxon.

Als Branche werden wir immer besser darin, Schwachstellen zu erkennen, während wir gleichzeitig immer mehr Software entwickeln. Daher ist das Risiko einer Überlastung leicht zu erkennen.

Schwachstellen in Software korrekt zu identifizieren, zu bewerten und Gegenmaßnahmen bereitzustellen, ist ein äußerst ressourcenintensiver Prozess, der vor allem bei komplexen Fällen überwiegend manuell erfolgt. Ansätze des maschinellen Lernens werden zwar immer nützlicher und KI könnte sich als noch hilfreicher erweisen, doch bei der Diagnose können Computer uns in vielen Fällen (ironischerweise) nur wenig helfen.

Anmerkung der Redaktion (19. Dez. 2021): Seit der Veröffentlichung hat das Logback-Projekt dem oben verlinkten Problem die CVE-2021-42550 zugewiesen. Ausgehend von den in diesem Beitrag dargelegten Gründen wird Snyk zu diesem Zeitpunkt keinen Sicherheitshinweis zu diesem Problem veröffentlichen. Wir werden uns weiterhin mit der Logback-Community austauschen und hoffen, dass sich durch eine offene Diskussion ein Konsens erzielen lässt.

Ein Blick nach vorn

Die hier dargelegten Diskussionspunkte zielen nicht darauf ab, eine bestimmte CVE zu ändern. Vielmehr sollen sie eine Diskussion über die Zukunft der Schwachstellenbewertung anstoßen und darüber, was wir heute und künftig als unsicher betrachten. Leistungsstarke und vielseitige Open-Source-Software für unterschiedlichste Anwendungsfälle zu entwickeln, führt zwangsläufig zu konfigurierbaren Modi mit unterschiedlichem Sicherheitsniveau. Wenn wir diesen Weg weitergehen wollen, tragen auch die Nutzer Verantwortung dafür, sich der möglichen Fallstricke bei der Verwendung bewusst zu sein. Vielleicht liegt die Lösung ebenso sehr in besserer Dokumentation und Aufklärung wie in der Einstufung potenzieller Schwachstellen bei der üblichen Nutzung.

Wir freuen uns auf Ihre Gedanken dazu. Schreiben Sie uns in den sozialen Medien (@snyksec) und lassen Sie uns darüber sprechen.