Zscaler Blog

Hintergrund 

Am 1. Dezember 2022 wurde eine Sicherheitslücke durch Stapelüberlauf (CVE-2022-23093) im Ping-Dienstprogramm des FreeBSD-Betriebssystems (in allen unterstützten Versionen) entdeckt. Das Problem betrifft eine Sicherheitslücke durch Pufferüberlauf in der Funktion „pr_pack()“ in ping(8). Diese Sicherheitslücke kann ausgenutzt werden, um einen Stapelüberlauf zu verursachen, der zu einem Absturz führen oder eine Remote-Code-Ausführung in Ping auslösen könnte.

Welches Risiko besteht konkret?

Die folgenden Details wurden in der Sicherheitswarnung von FreeBSD veröffentlicht:

Ping liest rohe IP-Pakete aus dem Netzwerk, um Antworten in der Funktion „pr_pack()“ zu verarbeiten. Im Rahmen der Verarbeitung einer Antwort muss Ping den IP-Header, den ICMP-Header und gegebenenfalls ein „zitiertes Paket“ rekonstruieren, das das Paket darstellt, das einen ICMP-Fehler verursacht hat. Das zitierte Paket hat wiederum einen IP-Header und einen ICMP-Header.

Die Funktion pr_pack() kopiert die empfangenen IP- und ICMP-Header zur weiteren Verarbeitung in Stack-Puffern. Dabei entsteht das Problem, weil das mögliche Vorhandensein von IP-Options-Headern nach dem IP-Header weder in der Antwort noch in dem zitierten Paket berücksichtigt wird. Sind diese IP-Optionen vorhanden, überläuft pr_pack() den Zielpuffer um bis zu 40 Bytes.

Welche Versionen sind betroffen?

Diese Sicherheitslücke betrifft alle derzeit unterstützten Versionen von FreeBSD.

Wie können Sie Ihre Organisation schützen?

Wenn Sie FreeBSD-Kunde sind, empfehlen wir Ihnen, schnellstmöglich die folgenden Maßnahmen zu ergreifen:

• Überprüfen Sie, ob Ihre aktuelle Version angreifbar ist. 
• Aktualisieren Sie auf die neueste verfügbare gepatchte Version.
• In Fällen, in denen ein Upgrade nicht durchführbar ist, besteht die Möglichkeit, den Patch auf die aktuelle Version zurückzuportieren. Es können auch weitere Gegenmaßnahmen ergriffen werden – beispielsweise können Sie ICMP-Pakete mit IP-Optionen über Stateful Firewalls blockieren, die Ping-Nutzung auf anfälligen Hosts auf geschützte Konten beschränken und einen ganzheitlichen Sicherheitsstatus mit einer Defense-in-Depth-Strategie implementieren, um abnormale Aktivitäten auf Hosts zu erkennen und darauf zu reagieren.

Die Zscaler Cloud ist nicht gefährdet

Nach eingehender Prüfung hat ThreatLabz festgestellt, dass die Servicekomponenten der Zscaler-Plattform nicht von dieser Sicherheitslücke betroffen sind. Den entsprechenden Beitrag von ThreatLabz finden Sie hier.

Darüber hinaus basiert die Zscaler-Plattform auf einer ganzheitlichen Zero-Trust-Architektur, die umfassende Abwehrmaßnahmen gegen Angriffe auf die Lieferkette sowie kompromittierte User bietet und derartige Sicherheitsvorfälle folgendermaßen verhindert:

• Sie lässt keine lateralen Bewegungen zu: Indem User direkt mit Anwendungen und nicht mit dem Netzwerk verbunden werden, wird das Schadenspotenzial im Falle eines erfolgreichen Angriffs begrenzt.
• Sie blockiert kompromittierte Konten und Insider-Bedrohungen: Wenn es einem Angreifer gelingt, sich Zugang zu den Anmeldedaten von Mitarbeitern zu verschaffen, wird durch Inline-Überprüfung der Zugriff auf unternehmensinterne Anwendungen verhindert. Mithilfe der integrierten Deception Technology lassen sich auch geschickte Angreifer entlarven.
• Sie verhindert Datenverluste: Zscaler überprüft sowohl in Übertragung befindliche als auch ruhende Daten, um deren Diebstahl im Zuge eines laufenden Angriffs zu unterbinden.

Nähere Informationen zur Sicherheitslücke

• Das Ping-Dienstprogramm, das mit einem IPv4-Ziel (IPv4-Host oder IPv4-Mcast-Gruppe) gestartet wird, verwendet das obligatorische ECHO_REQUEST-Datagramm des ICMP-Protokolls, um eine ICMP-ECHO_RESPONSE von einem Host oder Gateway zu erhalten. ECHO_REQUEST-Datagramme („Pings“) bestehen aus einem IP- und einem ICMP-Header, gefolgt von einer „struct timeval“-Struktur und einer beliebigen Anzahl von „Pad“-Bytes, die zum Ausfüllen des Pakets verwendet werden.

• „Ping liest rohe IP-Pakete aus dem Netzwerk, um Antworten in der Funktion ‚pr_pack()‘ zu verarbeiten. Im Rahmen der Verarbeitung einer Antwort muss ping den IP-Header, den ICMP-Header und gegebenenfalls ein ‚zitiertes Paket‘ rekonstruieren, das das Paket darstellt, das einen ICMP-Fehler verursacht hat. Das zitierte Paket hat wiederum einen IP-Header und einen ICMP-Header“, gab FreeBSD in einer Sicherheitswarnung bekannt.

• „Die Funktion pr_pack() kopiert die empfangenen IP- und ICMP-Header zur weiteren Verarbeitung in Stack-Puffern. Dabei entsteht das Problem, weil das mögliche Vorhandensein von IP-Options-Headern nach dem IP-Header weder in der Antwort noch in dem zitierten Paket berücksichtigt wird. Sind diese IP-Optionen vorhanden, überläuft pr_pack() den Zielpuffer um bis zu 40 Bytes.“

Technische Analyse

Das Ping-Dienstprogramm wird im Userspace ausgeführt. Wenn ein User den Ping-Befehl ausführt, ruft er die Binärdatei unter /sbin/ping auf. Der Code ist in der FreeBSD-Quelle verfügbar. Die anfällige Funktion pr_pack() gibt die Antwortinformationen des ICMP-Pakets an stdout aus, ähnlich dem bekannten String:

64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=86.4 ms

Im Netzwerk sieht das ICMP-Paket (sowohl Anfrage als auch Antwort) folgendermaßen aus:

Die Header im Diagramm oben sind die IP-Header mit einem optionalen Optionsfeld. Im Falle eines Angriffs werden diese IP-Optionen aktiviert und mit Bytes ungleich Null gefüllt.

In einigen Fällen, beispielsweise wenn ein ICMP-Paket auf dem Weg zum Zielhost falsch formatiert oder absichtlich verändert wird und die IP-Optionen in der ursprünglichen Echo-Anforderung aktiviert sind, kann die anfällige Funktion pr_pack() nicht genügend Platz auf dem Stack zuweisen, um IP-Optionen zu berücksichtigen, was zum Überlaufen des Stacks führt.

In diesen Fällen kann die Antwort des Zielhosts auch ein „zitiertes Paket“ im Datenteil enthalten (das erfasst, welches Paket genau den ICMP-Fehler verursacht hat) und die Funktion pr_pack() überläuft den Stack in ähnlicher Weise, wenn das zitierte Paket ICMP-Header enthält.

Der Pufferüberlauf tritt in Zeile 1156 und Zeile 1161 in der Funktion pr_pack() auf (definiert in ping.c). Das sieht folgendermaßen aus:

Der Wert von hlen wird ohne Prüfung des IP-Options-Headers berechnet, wobei eine standardmäßige Länge des IP-Paket-Headers von 20 Byte zugrunde gelegt wird. Die Funktion memcpy in der ICP-Struktur führt zum Pufferüberlauf.

Quellenangaben

1. https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc
2. https://vuldb.com/?id.214613