Inside Fastly: Ein Blick auf unseren Prozess zur Behebung von Sicherheitslücken

Wir sind immer wieder von den Entwicklern beeindruckt, die unsere Plattform nutzen, um Großartiges zu schaffen. Besonders freuen wir uns, wenn wir von diesen auf Fehler hingewiesen werden. Beispiel: Der Experte Emil Lerner hatte einen für uns sehr interessanten Fehler entdeckt und entsprechend einen Bericht an unser Programm zur Offenlegung von Sicherheitslücken gesendet. 

Wir wollten diese Gelegenheit nutzen, um Ihnen einen Einblick in unseren Prozess zur Behebung von Sicherheitslücken zu geben und das Team vorzustellen. Schließlich lernt man am besten von anderen, was funktioniert und warum. 

In diesem Blogpost erfahren Sie, um welche Art von Sicherheitslücke es sich handelte, wie wir sie in nur einer Woche nach der Triage komplett beheben konnten und warum wir so schnell eine Lösung parat hatten. Die von der Cybersecurity and Infrastructure Security Agency (CISA) empfohlene Zeitspanne zur Behebung von Fehlern beträgt 30 Tage. Wir haben es aber innerhalb von nur sieben Tagen ab der Triage geschafft.

Bevor wir ins Detail gehen, möchten wir noch darauf hinweisen, dass es zu keinem Zeitpunkt Hinweise darauf gab, dass diese Sicherheitslücke für Angriffe auf Kunden instrumentalisiert wurde.

Unser Team

Das Vulnerability Remediation Team ist Teil unserer Sicherheitsabteilung. Seine Aufgabe ist es, erkannte Schwachstellen zu analysieren und das interne Entwicklerteam bei deren Behebung zu unterstützen. Zur Beobachtung und Behebung von Sicherheitslücken arbeiten wir eng mit Sicherheitsexperten und unseren internen Entwicklerteams zusammen. Wir konzentrieren uns auf einige wenige Bereiche. So sind wir in der Lage, gründlich und schnell zu arbeiten. 

Zum einen sind wir bestrebt, unseren Triage-Prozess für Sicherheitslücken laufend zu verbessern. Er ist dazu da, dass wir gemeldete Probleme innerhalb von fünf Arbeitstagen analysieren und reproduzieren können. Dies entspricht der Hälfte der Zeit, die in der Regel für die Triage veranschlagt wird.  

Zum anderen stellen wir im Rahmen des Triage-Prozesses für Sicherheitslücken sicher, dass unser Entwicklerteam so viele Informationen wie möglich erhält, um das Problem beheben zu können. Wir müssen also die Meldung sehr sorgfältig kommunizieren und dem Entwicklerteam eine Methode an die Hand geben, mit der es das Problem so schnell wie möglich reproduzieren kann, idealerweise sogar automatisch. 

Außerdem stellen wir nur die besten Entwickler ein (bei Interesse hier klicken). Unser Team ist sehr kompetent und besitzt umfassende Expertise in der Programmierung auf Systemebene und fundierte Kenntnissen der Netzwerkprotokolle. Dank seiner Prozesse und Workflows kann es Meldungen prüfen und schnell Maßnahmen ergreifen, was auch bei dieser spezifischen Sicherheitslücke der Fall war.

Die Sicherheitslücke

Die am 23. November 2021 gemeldete Sicherheitslücke bezieht sich auf die serverseitige HTTP/3-Implementierung in H2O, einem optimierten HTTP-Server mit HTTP/1-, HTTP/2- und HTTP/3-Unterstützung. An diesem Open-Source-Projekt sind wir maßgeblich beteiligt. Wenn der H2O-Server nun mehrere QUIC-Frames in bestimmter Reihenfolge empfängt, könnte er so überlistet werden, dass er nicht initialisierten Speicher als empfangene HTTP/3-Frames behandelt. 

Wird H2O dann als Reverse Proxy verwendet, kann ein Angreifer diese Sicherheitslücke ausnutzen und den Reverse Proxy dazu veranlassen, den internen H2O-Zustand an vom Angreifer oder von Dritten kontrollierte Backend-Server zu senden, wie in folgender Grafik dargestellt. Der Angreifer kann nicht steuern, was genau vom H2O-Server kommt. Zum Beispiel können es Nutzeranfragen, Antworten auf diese oder andere Daten sein, die sich im zuvor freigegebenen H2O-Speicher befinden.

Diese Sicherheitslücke wird als CVE-2021-43848 bezeichnet und betrifft nur Kunden, die HTTP3 auf Fastly aktiviert haben, und hier auch nur diejenigen Services, die über HTTP3 laufen. Wie bereits erwähnt, gibt es keinerlei Hinweise darauf, dass diese Sicherheitslücke für einen entsprechenden Angriff instrumentalisiert wurde.

Fehlerbehebung

Das Team, das die Erst-Triage durchführte, erhielt und bestätigte die Meldung und leitete diese anschließend für eine detaillierte technische Analyse an das Triage-Team für Sicherheitslücken weiter. 

Nach Prüfung der Meldung und Reproduktion des Problems konnten unsere Entwickler die Sicherheitslücke bestimmen, eine Lösung entwickeln und diese innerhalb eines Tages in einer Testumgebung bereitstellen. Wir stellten fest, dass bei der Aktualisierung des HTTP3 Receive Buffers von H2O über h2o_http3_update_recvbuf in lib/http3/common.c der für den Buffer verwendete Speicher vor Wiederverwendung nicht gelöscht wurde, wenn die Buffergröße kleiner als der neue Buffer war. 

Das Triage-Team für Sicherheitslücken führte eine erneute Prüfung durch und bestätigte, dass die Codeänderungen das Problem behoben hatten. Der Rollout-Prozess wurde eingeleitet und abgeschlossen. Nachstehend der zeitliche Ablauf im Überblick:

• 23. November 2021: Ein Experte meldet das Problem.

• 24. November 2021: Das Team für die Erst-Triage erhält die Meldung.

• 29. November 2021: Das Triage-Team für Sicherheitslücken schließt seine Analyse ab und bestätigt die Reproduzierbarkeit des Fehlers.

• 1. Dezember 2021: Das Entwicklerteam erstellt eine Lösung zur Behebung des Fehlers und eine Testumgebung. Das Triage-Team für Sicherheitslücken führt erneute Tests durch, um die Lösung zu prüfen, und setzt sich anschließend mit dem Experten in Verbindung, um sich das Schließen der Sicherheitslücke anhand der vorgeschlagenen Codeänderung bestätigen zu lassen.

• 8. Dezember 2021: Das Rollout der Lösung ist abgeschlossen.

Fazit

Am Ende haben wir Emil Lerner für diese Meldung belohnt und möchten uns recht herzlich bei ihm bedanken. (Seine komplette Meldung finden Sie hier.) Und wie Sie im obigen Zeitablauf sehen können, hat der gesamte Prozess nur etwa zwei Wochen gedauert, worauf wir wirklich stolz sind.