Nachdem letzte Woche ein Advisory zu "der schlimmsten Schwachstelle in curl seit Langem" angekündigt wurde, konnten verängstigte, verschlafene und chronisch unterkoffeinierte Admins und Security-Spezialisten nach der gestrigen Veröffentlichung den Schaden begutachten. Die gute Nachricht: Die Apokalypse ist an uns vorüber gegangen. Die schlechte Nachricht: Mit dem CVSS(v2) Score lässt sich die Schwere einer Schwachstelle nicht immer ausreichend abbilden.

Nachfolgend ein (sehr) kurzer Blick auf die Schwachstelle selbst und warum trotz eines CVSS-Scores von 7.8 kein Grund besteht, eine Notwasserung der Beinkleider zu veranlassen.

Die Schwachstelle

Ich werde diese Sektion kurz halten, die schmutzigen technischen Details kann man hier nachlesen. Die Schwachstelle resultiert daraus, dass libcurl unter bestimmten Voraussetzungen einen sehr langen Hostnamen anstatt der aufgelösten Adresse an eine Variable übergibt und per memcopy() den Heap-Buffer sprengt und eventuell RCE erlaubt. So weit, so ungustiös. Die Voraussetzungen dafür sind jedoch alles andere als gängige Praxis, man muss schon ein wenig Arbeit investieren um diese zu schaffen:

•  Ein entsprechend langer Hostname muss an curl übergeben werden. Eine wirksame Input-Validation verhindert das schon mal.
• curl muss sich mit einem SOCKS 5 Proxy verbinden um den Bug zu triggern. Diese Konstellation hab ich tatsächlich in einer Produktionsumgebung noch nie gesehen. Das heißt nicht, dass es sie nicht gibt, aber sieht für mich nach wildem Flickwerk aus und ist offensichtlich auch nicht die allerbeste Idee.

 Ich erlaube mir an dieser Stelle, die Zusammenfassung vom SANS ISC abzukupfern schamlos zu stehlen:

This is only a valid exploit if you take unvalidated data and create an HTTP request via a SOCKS5 proxy to a hostname created from the unvalidated data. My recommendation is to upgrade without haste.

  Schrecken, Angst und Panik

Jaja, ich weiß, CVSSv2-Score 7.8 (lt. Tenable). An dieser Stelle möchte ich den Maintainer von curl - Daniel "Badger" Stenberg - zitieren:

The severity level is a blunt tool. This is a HIGH severity problem but there is still going to be a large chunk of users who will not be affected by these problems.

"Blunt tool" trifft es ziemlich genau. Der CVSS-Score ist nicht der Weisheit letzter Schluss, es ist ein Hilfsmittel um die Einschätzung zu erleichtern und in keinster Weise granular (oder auch nur eindeutig) genug um jede Schwachstelle ausreichend einschätzen zu können. In Wahrheit werden  zwei verschiedene Personen vermutlich unterschiedliche Scores berechnen. Nachfolgend zeige ich das am Beispiel dieser Schwachstelle.

Sehen wir uns einmal den Vektor an:

AV:N/AC:L/Au:N/C:N/I:N/A:C

• Access Vektor: N, Network - Also kurz: über das public Internet ausnutzbar. OK.
• Access Complexity: L, Low

Specialized access conditions do not exist. [...] The affected configuration is default or ubiquituous.

Nein, eher nicht. Ändern wir das mal auf M, Medium (The affected configuration is non-default and is not commonly configured).

• Authentication: N, None - OK
• Confidentiality: N, None - Damit bin ich nicht einverstanden, wenn der Angriff erfolgreich ist, gehe ich aufgrund einer RCE mit zumindest User-Rechten von einem teilweisen Impact auf die Confidentiality aus. Ändern wir das auf P, Partial.
• Integrity: N, None - Hier ebenso, mit einer RCE mit User-Rechten sehe ich die Integrity zumindest teilweise kompromittiert. - Ebenfalls P, Partial.
• Availability: C, Complete - Sollte der Bug ausgelöst werden, wird das curl-Kommando vermutlich abschmieren, inwiefern der darüberliegende Dienst komplett den Geist aufgeben soll, erschließt sich mir nicht. Nehmen wir in dem Fall mal eine teilweise Beeinträchtigung der Availability an - P, Partial.

Und damit haben wir unseren neuen CVSSv2-Vektor

AV:N/AC:M/Au:N/C:P/I:P/A:P

und einen neuen Score von 6.8 und damit nur noch Medium. Sollte man das weiterspielen wollen und den Impact auf die Availability als None einstufen, landen wir bei 5.8, also im mittleren Medium-Feld. Der Definition für Access Complexity folgend, könnte man diese sogar auf High setzen, denn da heißt es:

The vulnerable configuration is seen very rarely in practice.

Und plötzlich sind wir bei einem CVSSv2-Score von 4.0 und das ist gerade mal am untersten Ende von Medium.

Abschließend möchte ich anmerken, dass Daniel Stenberg den Vorfall vorbildlich behandelt hat, durch die initiale Einstufung als High ist auch niemandem ein Schaden entstanden, eher im Gegenteil - es wurde entsprechend Aufmerksamkeit geschaffen und patchen sollte man das ja schon. Es besteht aber auch kein Grund zur Panik, es sei denn man hat wirklich ein Faible für obskure Konfigurationen, wild zusammengehackte Shell-Scripts und lebt gerne gefährlich.

In diesem Sinne: Gut is gangen, nix is gschehen.