WEBVTT NOTE Erzeugt von tools/build-timing-from-voice.py 00:00:00.000 --> 00:00:07.019 Eine Webseite antwortet: Fehler fünfhundert. Irgendwas ist schiefgegangen. Die Anfrage ist abgebrochen. 00:00:07.339 --> 00:00:16.625 Frage an dich: Ist danach wieder alles sauber? Die meisten sagen ja. Und genau das war zwanzig Jahre lang der blinde Fleck. 00:00:16.875 --> 00:00:23.759 Zwei Sicherheitslücken, Oktober zwanzig sechsundzwanzig. Ihr Spitzname: P H P to Shell. 00:00:24.079 --> 00:00:36.874 Sie stecken nicht in einem Programm, das jemand schlecht geschrieben hat. Sie stecken im Kern von P H P selbst. Es sind zwei verwandte Fehler; wir bauen hier den Weg des einen Schritt für Schritt auf. Ohne Vorwissen. 00:00:37.624 --> 00:00:44.753 Stell dir eine Restaurantküche vor. Vorne im Lokal nimmt der Kellner Bestellungen an. Das ist der Webserver. 00:00:45.073 --> 00:00:54.078 In der Küche stehen ein paar Köche. Jeder Koch ist ein Arbeitsprozess. Verwaltet werden sie von einem Programm, das F P M heißt. 00:00:54.398 --> 00:01:05.984 Und jetzt der Punkt, auf den alles hinausläuft: Die Köche gehen nach einer Bestellung nicht nach Hause. Derselbe Koch kocht die nächste Bestellung. Und die nächste. Hunderte Male. 00:01:06.734 --> 00:01:17.558 Jeder Koch hat eine Werkbank. Darauf liegt alles, was zu dieser einen Bestellung gehört: die Zutaten, die Zettel, die Zwischenergebnisse. Das ist der Anfragespeicher. 00:01:17.878 --> 00:01:28.276 Am Ende der Bestellung wird die Werkbank freigegeben. Freigegeben heißt aber nur: Der Platz darf neu vergeben werden. Die Bank selbst bleibt stehen, genau da, wo sie war. 00:01:29.026 --> 00:01:35.893 An der Wand hängt noch etwas: ein Notizbrett. Darauf notiert der Koch Dinge, die länger gelten sollen als eine Bestellung. 00:01:36.213 --> 00:01:47.220 Zum Beispiel: Die Zutaten für Tisch sieben liegen vorne links auf der Bank. Dieser Zettel ist keine Kopie. Er ist ein Verweis. Er sagt nur, wo etwas liegt. 00:01:47.970 --> 00:01:55.503 Im Normalfall läuft das Aufräumen in einer bestimmten Reihenfolge ab. Erst wird der Zettel abgehängt. Dann wird die Bank geräumt. 00:01:55.823 --> 00:02:02.830 Diese Reihenfolge ist die ganze Sicherheit. Solange sie stimmt, zeigt nie ein Zettel auf eine Stelle, die schon weg ist. 00:02:03.580 --> 00:02:11.974 Jetzt kommt der schwere Fehler. Ein fataler Fehler in P H P ist kein höfliches Rückmelden. Es ist ein Notausgang. 00:02:12.294 --> 00:02:19.397 Das Programm springt mitten aus der Arbeit heraus, direkt zum Ausgang. In der Fachsprache heißt dieser Sprung long jump. 00:02:19.717 --> 00:02:26.053 Und alles, was zwischen dem Sprung und dem Ausgang gestanden hätte, läuft nicht. Auch nicht der Schritt: Zettel abhängen. 00:02:26.803 --> 00:02:35.036 Die Bestellung endet trotzdem. Der Platz auf der Werkbank wird freigegeben — in einem Zug, nicht Stück für Stück. Abgeräumt wird dabei nichts. 00:02:35.356 --> 00:02:44.525 Aber der Zettel hängt noch an der Wand. Und er zeigt weiter auf eine Stelle, auf der jetzt nichts mehr liegt. So ein Zettel hat einen Namen: ein hängender Zeiger. 00:02:45.275 --> 00:02:49.854 Nächste Bestellung. Derselbe Koch, dieselbe Küche, dieselbe Werkbank. 00:02:50.174 --> 00:03:05.467 Er legt neue Zutaten auf die Bank. Freie Plätze werden bevorzugt wieder vergeben, also landen die neuen Zutaten mit guter Chance genau dort, wo vorher die alten lagen. Sicher ist das nicht. Merk dir das, wir kommen darauf zurück. 00:03:05.787 --> 00:03:23.261 Dann liest ein Handgriff den alten Zettel. Einer von denen, die PHP bei jeder neuen Anfrage automatisch macht, noch bevor irgendein Programm läuft. Der Zettel sagt: Vorne links liegen die Zutaten für Tisch sieben. Vorne links liegt auch wirklich etwas. Es ist nur nicht das, was der Zettel meint. 00:03:23.581 --> 00:03:34.278 Genau das ist der Fehler mit dem englischen Namen Use after free. Benutzung nach dem Freigeben. Das Programm arbeitet weiter mit Speicher, den es längst zurückgegeben hat. 00:03:35.028 --> 00:03:47.706 Deshalb braucht ein Angriff zwei Anfragen. Die erste Anfrage legt den Zettel und sorgt für den Absturz. Die zweite Anfrage füllt die Werkbank mit eigenen Daten und lässt den Zettel darauf zeigen. 00:03:48.026 --> 00:04:00.082 Und jetzt kommt der Schritt, der aus einem Datenfehler einen Angriff macht. Nicht jeder Zettel sagt nur, wo etwas liegt. Manche sagen: Als Nächstes ist dieses Rezept dran. 00:04:00.402 --> 00:04:20.331 Wenn an dieser Stelle die Daten des Angreifers liegen, dann bestimmt er, womit PHP weiterarbeitet. Über mehrere solcher Schritte kann daraus am Ende ein fremder Befehl werden. Wie genau, hängt vom Einzelfall ab. Die Hersteller bewerten es als das Schlimmste, was passieren kann: Der Server führt aus, was von außen kommt. 00:04:20.651 --> 00:04:29.381 Zwei Dinge müssen also zusammenkommen: ein Zettel, der zu lange hängt, und ein Koch, der weiterarbeitet. Beides ist Alltag, kein Unfall. 00:04:30.131 --> 00:04:40.492 Und damit kommen wir zur wichtigsten Frage überhaupt. Nicht nur bei dieser Lücke, sondern bei jeder: Was muss eigentlich alles zusammenkommen, damit so etwas wirklich ausgenutzt werden kann? 00:04:40.812 --> 00:04:54.479 Fünf Dinge. Und zwar alle gleichzeitig. Erstens: ein Zettel, der überhaupt hängen bleibt. Zweitens: ein Fehler, der mitten im Aufräumen herausspringt und dabei die Lücke erst aufreißt. 00:04:54.799 --> 00:05:11.140 Drittens: ein Prozess, der danach weiterlebt. Viertens: die nächste Anfrage muss ausgerechnet bei diesem einen Prozess landen. Und fünftens: die eigenen Daten müssen genau auf dem frei gewordenen Platz zu liegen kommen. 00:05:11.460 --> 00:05:23.175 Jede einzelne Bedingung ist eine Hürde. So läuft der häufigste Weg, und deshalb gilt der Angriff offiziell als schwierig. Nur: Schwierig ist nicht dasselbe wie unmöglich. 00:05:23.495 --> 00:05:37.951 Ein Angreifer darf es zehntausend Mal probieren. Ein Fehlversuch kostet ihn nichts. Ein einziger Treffer kostet dich alles. Genau deshalb ist schwer auszunutzen kein Grund zu warten. 00:05:38.701 --> 00:05:46.937 Und hier kommt die Stelle, an der es für Betreiber unangenehm wird. Du denkst jetzt vielleicht: Mein Code hat gar keinen fatalen Fehler. 00:05:47.257 --> 00:06:00.428 Das muss er auch nicht. Der Angreifer bringt den Fehler mit. Er stellt eine Anfrage so, dass P H P beim Einlesen der Anfrage der Speicher ausgeht. Speicher voll ist auch ein fataler Fehler. 00:06:00.748 --> 00:06:16.267 Dieses Einlesen passiert, bevor die erste Zeile deines Programms läuft. Und wo das nicht reicht, genügt eine ganz alltägliche Stelle im Programm: eine Sitzung, die geladen wird, ein gespeicherter Wert, der ausgepackt wird. Nichts davon ist ein Fehler in deinem Code. 00:06:16.587 --> 00:06:30.686 Dazu kommt eine Funktion, die seit Jahren in fast jeder Standard-Einstellung an ist: der Fortschrittsanzeiger beim Hochladen von Dateien. Er arbeitet schon während des Einlesens. Deshalb ist er in diesen Lücken der erste, der auf den alten Zettel schaut. 00:06:31.436 --> 00:06:42.561 Noch ein verbreiteter Irrtum, und der ist wichtig. Viele Server zeigen Fehler nicht an. Die Anzeige ist aus, der Besucher sieht nur eine höfliche Seite. 00:06:42.881 --> 00:06:51.363 Das hilft hier nichts. Die Anzeige entscheidet nur, was der Besucher liest. Der Zettel bleibt trotzdem hängen. Der Schaden passiert innen, nicht am Bildschirm. 00:06:52.113 --> 00:07:06.885 Was hilft, ist eine einzige Sache: das Update. P H P acht Punkt fünf Punkt zwölf, acht Punkt vier Punkt siebenundzwanzig, acht Punkt drei Punkt sechsunddreißig, acht Punkt zwei Punkt fünfunddreißig. 00:07:07.205 --> 00:07:17.713 Alles andere verkleinert nur die Trefferfläche. Den Fortschrittsanzeiger abschalten nimmt einen Weg weg, nicht den Fehler. Es gibt noch andere, die auf den Zettel schauen. 00:07:18.033 --> 00:07:35.077 Und ein Filter davor, eine Schutzmauer im Netz, muss erkennen, was er sieht. Dieser Angriff sieht aber aus wie ganz normaler Verkehr. Dazu kommt: Wer die Adresse des Servers kennt, kann an der Mauer vorbeigehen, solange der Server direkte Zugriffe überhaupt annimmt. 00:07:35.397 --> 00:07:47.187 Deshalb haben in diesen Tagen Städte, Kliniken und Behörden ihre Seiten freiwillig abgeschaltet. Nicht weil sie angegriffen wurden. Sondern weil Abschalten schneller ging als Patchen. 00:07:47.937 --> 00:07:51.819 Drei Dinge zum Mitnehmen, und die gelten weit über P H P hinaus. 00:07:52.139 --> 00:08:09.793 Erstens: Wo Prozesse wiederverwendet werden, überlebt Zustand länger, als man denkt. Zweitens: Der Fehlerpfad ist Teil der Sicherheit, nicht ein Randfall. Drittens: Code, der scheinbar nie erreicht wird, ist die liebste Abkürzung eines Angreifers. 00:08:10.543 --> 00:08:16.513 Wenn dir das Video beim Verstehen geholfen hat: Genau so erklären wir auch Mathe, Physik und Informatik. 00:08:16.833 --> 00:08:19.944 Wir helfen helfen. Nachhilfe-Vermittlung Punkt com.