Gefälschte IGMP Membership Reports an Mitglieder einer Multicastgruppe ermöglichen Angreifern die Unterbrechung des Multicast-Datenverkehrs.

Betroffene Systeme

• Microsoft Windows 98, XP
• Linux 2.4.18
• vermutlich weitere Betriebssysteme mit IGMPv1/v2-Iplementierung

Einfallstor
IGMP Membership Report

Auswirkung
Abbruch der Multicastkommunikation
Denial of Service (DoS)

Typ der Verwundbarkeit
Design Flaw

Gefahrenpotential
mittel
(Hinweise zur Einstufung des Gefahrenpotentials.)

Kontext
Das im RfC2236 beschriebene Internet Group Management Protocol, Version 2 dient Rechnersystemen in IP-Netzen dazu, den benachbarten Routern ihren Zugehörigkeitsstatus zu Multicastgruppen mitzuteilen.

Eine Multicastgruppe wird durch das Senden von IGMP Membership Queries der involvierten Routers an die von Ihnen versorgten Mitglieder (Hosts) der Gruppe sowie der Antwort eines Mitgliedes dieser Gruppe am Leben erhalten. Bei jeder IGMP-Kommunikation zwischen Router und Gruppenmitglied wird jeweils ein Zähler gesetzt nach dessen Ablauf sich die Kommunikation wiederholt. Um unnötige Doubletten zu vermeiden, unterdrücken alle Gruppenmitglieder einen fälligen Membership Report wenn ein Mitglied der Gruppe einen solchen geschickt hat.

Beschreibung
Der Mechanismus zur Unterdrückung von überflüssigen Membership Reports in der IGMPv1/v2-Implementierung der o. g. Betriebssysteme hat einen Design Fehler. Empfängt der Rechner einen fremden Membership Report eines Mitgliedes einer Gruppe in dem auch eigene Prozesse Mitglied sind, so überprüft das IGMP-System nicht, ob die Zieladresse des Paketes, in dem der Membership Report das beherbergende Rechnersystem erreicht, eine Multicast-MAC-Adresse ist.

Dieser Umstand ermöglicht mehrere Denial of Service-Angriffsszenarien:

1. Rechner A und Rechner B (Bösewicht) befinden sich in einer Collision Domain, die vom Router R versorgt wird. Rechner A ist Mitglied der Multicastgruppe 230.0.0.1 und erhält Multicastverkehr von R. R sendet neben dem Multicastverkehr regelmäßig IGMP Membership Queries und erwartet einen IGMP Membership Report eines der Gruppenmitglieder aus der Domain (hier A) um sicherzustellen, daß die Multicastgruppe weiterhin existiert. B hört das Netz ab. Empfängt B eine Query von R so sendet er einen gefälschten IGMP Membership Report direkt (unicast) an As Ethernet-Adresse.

   A empfängt den Report und unterdrückt die Generierung eines eigenen Reports, da er vermutet, daß ein anderer Rechner Interesse an einer Mitgliedschaft in der Multicastgruppe hat und sich mit diesem Report beim Router anmelden möchte. Da As IGMP-Implementierung die Zieladresse des empfangenen Paketes nicht überprüft, erkennt A nicht, daß es sich hierbei um ein gefälschtes Paket handelt, das nur A, nicht aber R erreicht hat.

   R erhält keinen weiteren Membership Report und beendet daher nach Erreichen des Time-Out das Routing von Multicastverkehr für die Gruppe 230.0.0.1 in dieses Netzsegment. B hat A erfolgreich aus der Gruppe ausgeschlossen. Dieser Angriff kann auch bei mehreren Gruppenmitgliedern im Netzsegment durchgeführt werden.

2. A und B sowie weitere Rechner sind an R über eine switched Infrastruktur angeschlossen. Da R sicherstellen muß, daß alle Mitglieder sowie alle potentiellen Mitglieder der Gruppe 230.0.0.1 IGMP-Pakete empfangen können, kann B diese ebenfalls empfangen. Nach Empfang einer Membership Query von R sendet B einen gefälschten Report direkt an die anderen Mitglieder der Gruppe 230.0.0.1, die daraufhin einen Report unterdrücken. R beendet daher nach Erreichen des Time-Out das Routing des Multicastverkehr für die Gruppe 230.0.0.1 in das Subnetz.

3. A und B befinden sich in einer switched Infrastruktur in der ICMP Snooping aktiviert ist. Die teilnehmenden Rechner sehen keine Membership Requests anderer Gruppemmitglieder, da diese von den Switches abgefangen werden. Dies hat zur Folge, daß jeder Rechner auf jede Membership Query antwortet die der Switch wiederum abfängt und als Proxy zum Router agiert.

   B sendet daher auf eine Query von R an alle Rechner des Netzwerkes direkt einen Membership Report, was dazu führt, daß alle Gruppenmitglieder die Generierung eines eigenen Reports unterdrücken. R beendet auch in diesem Fall nach Erreichen des Time-Out das Routing des Multicastverkehrs für die Gruppe 230.0.0.1 in das Subnetz.

IGMPv3 ist von dieser Schwachstelle nicht betroffen, da es keine report suppression unterstützt.

Gegenmaßnahmen

• Krishna Ramachandran von der University of California stellt eine korrigierte Quelldatei igmp.c (changes.html) für Linux 2.4.18 zur Verfügung.
• SGI prüft derzeit, ob diese Schwachstelle in IRIX 6.5 vorliegt
• Reaktionen weiterer Hersteller liegen derzeit nicht vor.

Vulnerability ID

• Es liegt noch keine CVE-Nummer vor.

Weitere Information zu diesem Thema

• RfC2236 Internet Group Management Protocol, Version 2
• Multicast in a Campus Network: CGMP and IGMP Snooping, Cisco Systems Inc.
• SGI Security Advisory (2002-09-18) IGMP multicast report Denial of Service vulnerability

Weitere Artikel zu diesem Thema:

• [SGI/IRIX] DoS durch IGMP-Multicast-Pakete bei SGI IRIX 6.5.x (2001-10-23)
  Spezielle IGMP-Multicast-Pakete führen bei SGI IRIX 6.5.x Systemen zu einem Systemabsturz.

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/