Eine Schwachstelle im IGMP-Code des Linux-Kernels kann zum Absturz des Systems führen.
Das Internet Group Management Protocol (IGMP) dient zum Verwalten von Multicast-Gruppen und ist auf allen Hosts verfügbar, die Multicasting unterstützen. Wie bei Broadcasting auch werden bei Multicast IP-Pakete unter einer IP-Adresse an mehrere Hosts gleichzeitig versandt. Der Unterschied liegt darin, dass bei Multicasting nicht an alle Hosts, sondern nur an bestimmte Multicast-Gruppen gesendet wird. IGMP bietet die Möglichkeit, diese Gruppen dynamisch zu erzeugen und zu löschen, wobei die genaue Verwaltung von Routern übernommen wird.
Hierbei kommen Multicast-Protokolle wie DVMRP, MOSPF und PIM zum Einsatz. Das Vervielfältigen der IP-Pakete eines Senders wird dann automatisch vom Router übernommen. IGMP kommt nur bei IPv4-Multicasting zum Einsatz. Bei IPv6 wird diese Funktionalität von ICMPv6 beziehungsweise dem darin integrierten Multicast Listener Discovery (MLD) übernommen.
Derzeit existieren drei verschiedene IGMP-Versionen. In der Version 1 ist das Abmelden aus einer Multicast-Gruppe nicht explizit implementiert, und ein Host wird nach einem festgelegten Timeout einfach wieder aus der Gruppe entfernt. Dies wurde in Version 2 geändert, wo sich ein Host durch eine Leave Message von einer Gruppe abmelden kann. In Version 3 lassen sich zusätzlich auch Quellen von Multicast-Daten spezifizieren, was hauptsächlich aus Sicherheitsgründen aufgenommen wurde.
Eine Schwierigkeit beim Implementieren von IGMP in Netzwerk-Stacks von Betriebssystemen besteht darin, dass die drei Versionen teilweise inkompatible Nachrichtenformate besitzen. Ein Beispiel hierfür ist der Eintrag für die Maximum Response Time. Diese ist in Version 1 fest spezifiziert (10 Sekunden), während sie in Version 2 und 3 Teil einer IGMP-Nachricht ist. Außerdem sind durch die Zusatzinformation in Version 3 deren Nachrichten länger als die von Version 1 oder 2. Sind verschiedene Multicast-Router in einem Netzwerk vorhanden, so wird gewöhnlich die niedrigste Versionsnummer für die gemeinsame Kommunikation verwendet. Offensichtlich ist es sehr wichtig, dass der Netzwerk-Stack eines Betriebssystems eine einwandfrei funktionierende Auswahllogik für die Versionsnummer des IGMP besitzt, da es andernfalls zu Problemen kommen kann.
Genau ein solches Problem hat sich in den Linux-Kernel eingeschlichen. Anfang Januar hat Ben Hutchings einen Crash seines Rechners auf der Debian Bug-Mailingliste gemeldet. Nach einigem Suchen stellte sich heraus, dass dieser im IGMP-Teil des Kernels auftritt, wie sein Backtrace zeigt:
... [16111.048524] divide error: 0000 [#1] SMP ... [16111.052013] Call Trace: [16111.052013] <IRQ> [16111.052013] [<ffffffff812c166e>] ? igmp_rcv+0x480/0x515 [16111.052013] [<ffffffff81297cdf>] ? ip_local_deliver_finish+0x137/0x1a4 [16111.052013] [<ffffffff8126f54f>] ? __netif_receive_skb+0x3e3/0x415 [16111.052013] [<ffffffff81270dc0>] ? netif_receive_skb+0x63/0x69 [16111.052013] [<ffffffffa03c4775>] ? ieee80211_frame_allowed+0x68/0xc3 [mac80211] [16111.052013] [<ffffffffa03c4b33>] ? ieee80211_deliver_skb+0xbb/0xf1 [mac80211] [16111.052013] [<ffffffffa03c5d67>] ? ieee80211_rx_handlers+0xf19/0x1755 [mac80211] ...
Im ersten Teil wird noch ein “divide error” gemeldet, das heißt, der Absturz enstand durch eine ungültige Division.
Wie sich herausstellte lässt sich dieser Fehler auf Fixes in der Kernel Version 2.6.36 zurückführen (hier und hier), die die Auswahllogik für die IGMP-Versionsnummer betrafen. Genauer gesagt entsteht das Problem durch den zweiten Fix. Dieser hat nämlich zur Folge, dass die Max Response Time einer v3-Nachricht, die nach einer v2-Nachricht empfangen wird, falsch verarbeitet wird. Das führt dazu, dass eine Division durch 0 im Kernel durchgeführt wird.
Ein Exploit für diese Sicherheitslücke wurde ebenfalls veröffentlicht. Damit lassen sich Denial-of-Service-Attacken gegen betroffen Linux-Systeme durchführen. Anfällig hierfür sind allerdings nur Systeme mit aktivierten IPv4-Multicast-Listener. Der Exploit konstruierte einfach IGMPv2- und spezielle IGMPv3-Pakete (mit Max Response Time = 0) und sendet sie an das Opfer. Dies löst dann einen Absturz des Kernels aus.
Der Fix für diese Schwachstelle ist in den Kernel-Versionen 3.0.17, 3.1.9 und 3.2.1 enthalten.
