CVE-2024-5535

Zusammenfassung

Issue-Zusammenfassung: Der Aufruf der OpenSSL-API-Funktion SSL_select_next_proto mit einem leeren Puffer für unterstützte Client-Protokolle kann einen Absturz verursachen oder dazu führen, dass Speicherinhalte an den Peer gesendet werden. Auswirkungs-Zusammenfassung: Ein Puffer-Overread kann eine Reihe potenzieller Folgen haben, wie unerwartetes Anwendungsverhalten oder einen Absturz. Insbesondere könnte dieses Problem dazu führen, dass bis zu 255 Bytes beliebiger privater Daten aus dem Speicher an den Peer gesendet werden, was zu einem Verlust der Vertraulichkeit führt. Allerdings sind nur Anwendungen betroffen, die die SSL_select_next_proto-Funktion direkt mit einer Liste von unterstützten Client-Protokollen der Länge 0 aufrufen. Dies wäre normalerweise nie ein gültiges Szenario und liegt typischerweise nicht unter der Kontrolle eines Angreifers, kann aber versehentlich im Falle eines Konfigurations- oder Programmierfehlers in der aufrufenden Anwendung auftreten. Die OpenSSL-API-Funktion SSL_select_next_proto wird typischerweise von TLS-Anwendungen verwendet, die ALPN (Application Layer Protocol Negotiation) oder NPN (Next Protocol Negotiation) unterstützen. NPN ist älter, wurde nie standardisiert und ist zugunsten von ALPN veraltet. Wir glauben, dass ALPN deutlich weiter verbreitet ist als NPN. Die Funktion SSL_select_next_proto akzeptiert eine Liste von Protokollen vom Server und eine Liste von Protokollen vom Client und gibt das erste Protokoll zurück, das in der Serverliste erscheint und auch in der Clientliste vorkommt. Im Falle keiner Überschneidung zwischen den beiden Listen gibt sie das erste Element der Clientliste zurück. In beiden Fällen signalisiert sie, ob eine Überschneidung zwischen den beiden Listen gefunden wurde. In dem Fall, in dem SSL_select_next_proto mit einer Clientliste der Länge Null aufgerufen wird, erkennt sie diese Bedingung nicht und gibt den Speicher unmittelbar nach dem Zeiger auf die Clientliste zurück (und meldet, dass es keine Überschneidung in den Listen gab). Diese Funktion wird typischerweise aus einem serverseitigen Anwendungs-Callback für ALPN oder einem clientseitigen Anwendungs-Callback für NPN aufgerufen. Im Falle von ALPN ist die vom Client gelieferte Protokollliste von libssl garantiert niemals von der Länge Null. Die Server-Protokollliste stammt von der Anwendung und sollte normalerweise niemals erwartungsgemäß von der Länge Null sein. In diesem Fall, wenn die SSL_select_next_proto-Funktion wie erwartet aufgerufen wurde (mit der vom Client gelieferten Liste, die in den Parametern client/client_len übergeben wird), ist die Anwendung nicht anfällig für dieses Problem. Wenn die Anwendung versehentlich mit einer Serverliste der Länge Null konfiguriert wurde und versehentlich diese Serverliste der Länge Null in den Parametern client/client_len übergeben hat und zusätzlich versäumt hat, eine „keine Überschneidung“-Antwort korrekt zu behandeln (was normalerweise zu einem Handshake-Fehler bei ALPN führen würde), dann ist sie anfällig für dieses Problem. Im Falle von NPN erlaubt das Protokoll dem Client, opportunistisch ein Protokoll auszuwählen, wenn es keine Überschneidung gibt. OpenSSL gibt im Falle keiner Überschneidung das erste Client-Protokoll zurück, um dies zu unterstützen. Die Client-Protokollliste stammt von der Anwendung und sollte normalerweise niemals erwartungsgemäß von der Länge Null sein. Wenn die SSL_select_next_proto-Funktion jedoch versehentlich mit einem client_len von 0 aufgerufen wird, wird stattdessen ein ungültiger Speicherzeiger zurückgegeben. Wenn die Anwendung diese Ausgabe als das opportunistische Protokoll verwendet, kommt es zum Verlust der Vertraulichkeit. Dieses Problem wurde als geringe Schwere eingestuft, da Anwendungen am wahrscheinlichsten anfällig sind, wenn sie NPN anstelle von ALPN verwenden – aber NPN ist nicht weit verbreitet. Es erfordert außerdem einen Anwendungs-Konfigurations- oder Programmierfehler. Schließlich läge dieses Problem typischerweise nicht unter der Kontrolle eines Angreifers, was eine aktive Ausnutzung unwahrscheinlich macht. Die FIPS-Module in 3.3, 3.2, 3.1 und 3.0 sind von diesem Problem nicht betroffen. Aufgrund der geringen Schwere dieses Problems geben wir derzeit keine neuen Versionen von OpenSSL heraus. Der Fix wird in den nächsten Versionen enthalten sein, sobald diese verfügbar sind.