Falscher CVE-Eintrag: Die kritische curl-Lücke, die keine war

Inhaltsverzeichnis

CVE-Einträge – oder kurz CVEs – sind die Basis für systematische Arbeit mit Sicherheitslücken. Damit wird jeder Schwachstelle eine Nummer und auch gleich einen Schweregrad zugeteilt, damit alle wissen, worüber man gerade redet. Doch allzu sehr verlassen kann man sich darauf nicht, wie jetzt der Maintainer des Open-Source-Projekts curl feststellen musste.

Der mysteriöse CVE-2020-19909

Daniel Stenberg erhielt kürzlich eine Mail, die ihn darauf hinwies, dass in "seinem" Projekt offenbar seit Jahren eine überaus kritische Lücke existiert, für die es immer noch keinen Patch gebe. Und in der Tat: Der offiziell vom zuständigen MITRE veröffentlichte CVE-2020-19909 beschrieb einen Integer-Überlauf mit einem CVSS-Wert von 9.8 von maximal 10 – also quasi maximal kritisch. In der Update-Historie des curl-Projekts fand der jedoch keine Erwähnung und wäre damit nach wie vor ungefixt.

Die Jahreszahl 2020 scheint tatsächlich auf ein altes Problem hinzuweisen. Und Integer-Überläufe führen wirklich häufig zu kritischen Problemen. Denn Computer fangen nach der Maximalgröße einer Variablen wieder von vorn an: MAXINTEGER+1 ergibt 0. Wenn der Zahlenwert etwa zur Anforderung von Speicher zum Einsatz kommt, kann der Angreifer durch Eingabe unsinnig großer Zahlen dafür sorgen, dass viel zu wenig Speicher reserviert wird und anschließend seine Daten Speicherbereiche hinter dem dafür vorgesehenen Puffer überschreiben. Das führt dann oft zum Einschleusen und Ausführen bösartigen Codes (Remote Code Execution, RCE). Die CVSS-Einstufung erschien also auf den ersten Blick plausibel. Hatte das curl-Team da wirklich so heftig geschlampt?

Auf den zweiten Blick

Stenberg irritierte der Eintrag gerade deshalb, da ihm kein solch kritisches Problem in curl bekannt war und er sich bei seiner Entwicklerehre gepackt fühlte. Anhand der Kurzbeschreibung konnte er dann den wahrscheinlich gemeinten Bug lokalisieren. Es gab nämlich 2019 tatsächlich einen Integer Overflow Bug im Code, der den Wert von --retry-delay betraf. Durch Angabe unsinnig großer Werte konnte ein Angreifer dafür sorgen, dass curl einen fehlgeschlagenen Abruf einer Seite statt nach Wochen oder Monaten bereits nach wenigen Sekunden erneut versucht. Die Entwickler behoben den Fehler damals recht zügig, stuften das aber nicht als sicherheitsrelevant ein. Eine Entscheidung, die man nachvollziehen kann; wie man damit Remote Code Execution erreichen sollte, ist jedenfalls nicht nachvollziehbar.

Des Rätsels Lösung ist, dass das CVE-System auf sehr wackeligen Beinen steht. Es kann nämlich prinzipiell jede Person oder Organisation jederzeit solche CVE-Nummern reservieren und dann zu einem beliebigen Zeitpunkt einem selbst dazu erklärten Sicherheitsproblem zuweisen. Die gemeinnützige MITRE als oberste Verwaltungsinstanz nimmt lediglich sehr rudimentäre Plausibiltäts-Prüfungen vor und übernimmt ansonsten die Angaben des Einreichers kommentarlos. Genauer beschreibt das CVE-System der heise-Security-Artikel Schubladen für Schwachstellen: Das CVE-System im Überblick. In diesem Fall nutzte ein anonymer Einreicher das aus, um eine angeblich kritische Lücke zu dokumentieren.

Vorsicht bei CVE und CVSS

Mittlerweile hat Stenberg bei der MITRE gegen diesen Eintrag Protest eingelegt, was auch dort jetzt auch dokumentiert ist ("DISPUTED"). Wer mit CVEs arbeitet, sollte im Hinterkopf behalten, dass die Einträge nur als eindeutige Referenz dienen, die bestätigen kann, wovon gerade die Rede ist. Auf die Bewertungen kann und sollte man sich nicht verlassen, sondern dafür vielmehr die Advisories von Herstellern oder den Entdeckern einer Sicherheitslücke zurate ziehen. Im Idealfall können sich die beiden sogar auf eine gemeinsame Bewertung etwa via CVSS einigen.

(ju)