Kea DHCP hat sich in den letzten Jahren als moderner Ersatz für die traditionelle ISC DHCP-Software etabliert und wird in zahlreichen Linux- und BSD-Distributionen verwendet. Doch eine eingehende Prüfung der Kea-Softwareversion 2. 6. 1 zeigte erhebliche lokale Schwachstellen auf, die sowohl bei Linux als auch bei BSD-Systemen zu Sicherheitsrisiken führen können. Diese Schwachstellen eröffnen Angreifern die Möglichkeit, lokale Privilegien zu eskalieren, Systemdateien zu manipulieren, Logdateien umzuleiten oder sogar Logikfehler auszunutzen, die zur Dienstverweigerung führen. Angesichts der breiten Nutzung von Kea in Server- und Netzwerkinfrastrukturen ist das Verständnis dieser Probleme von zentraler Bedeutung für Administratoren und Sicherheitsexperten. Die Architektur von Kea gliedert sich in drei Hauptdienste, die für DHCPv4, DHCPv6 und DHCP-Dynamic DNS zuständig sind.
Zentral für die Steuerung ist der kea-ctrl-agent, der standardmäßig auf dem lokalen Host einen HTTP-REST-API-Dienst auf Port 8000 anbietet. Dieses API erlaubt die Konfiguration sowie Administration der einzelnen DHCP-Dienste. Interessanterweise ist dieses API in vielen Standardkonfigurationen uneingeschränkt für alle Nutzer des Systems zugänglich und erfordert keine Authentifizierung. Dies stellt eine der grundlegenden Ursachen für viele der entdeckten Sicherheitslücken dar, da ohne Zugangsbeschränkungen jedweder lokale Benutzer umfassende Kontrolle über die DHCP-Dienste erlangen kann. Ein besonders gravierender Schwachpunkt zeigt sich im Zusammenhang mit dem Befehl set-config. Hier besteht die Möglichkeit, sogenannte Hook-Bibliotheken einzubringen, die beim Start der Kea-Dienste geladen werden. Durch manipulierte Hook-Libraries kann ein unprivilegierter Benutzer schädlichen Code mit den Rechten des Kea-Dienstes ausführen.
Da die Kea-Services häufig mit Root-Rechten laufen, ist die Ausnutzung dieser Lücke mit einer vollständigen lokalen Root-Übernahme verbunden. Selbst wenn die Dienste mit eingeschränkten Benutzerrechten betrieben werden, kann durch diese Methode der Einfluss auf die Dienste und deren Netzwerkkapazitäten übernommen werden. Eine weitere kritische Schwachstelle betrifft die Funktion zum Schreiben von Konfigurationsdateien über den config-write-Befehl. Ein Angreifer kann beliebige Dateien auf dem System überschreiben, vorausgesetzt der Kea-Dienst verfügt über entsprechende Schreibrechte. Dies öffnet Türen für die Manipulation wichtiger Systemdateien oder das Einschleusen schädlicher Konfigurationen. Die Möglichkeit, Logdateien auf beliebige Pfade umzuleiten, erhöht den Schaden zusätzlich, da Vertraulichkeiten verletzt oder fälschlich sensitives Debug-Logging aktiviert werden kann, was weiterführende Angriffe begünstigt.
Auch dieser Angriffsvektor ist vornehmlich lokal ausnutzbar, kann jedoch zu einem Denial-of-Service oder zur Umgehung von Systemintegritätsmechanismen führen. Ein unerwartetes Problem ergibt sich aus dem Umgang mit UNIX Domain Sockets, welche zur Kommunikation zwischen kea-ctrl-agent und den einzelnen Kea-Diensten verwendet werden. Da viele Distributionen die Socket-Dateien im öffentlichen Verzeichnis /tmp ablegen, kann ein lokaler Angreifer dort eine bösartige Socket-Datei anlegen, die als Kea-Service getarnt ist. Sollte ein legitimer Administrator versuchen, Befehle an einen nicht aktiven Kea-Dienst zu schicken, kann der Angreifer diese Anfragen abfangen, manipulieren oder täuschen. Diese Art des Service-Spoofings ermöglicht es, Administrationsbefehle umzuleiten oder sensible Daten abzugreifen. Zudem kann das Vorhandensein von präventiv von Angreifern angelegten Socket- oder Lock-Dateien den Start legitimer Kea-Dienste verhindern, was zu einem lokalen Denial-of-Service führt.
Zusätzlich zu diesen aktiven Angriffsmöglichkeiten offenbaren viele Installationen eine passive Informationslecksituation durch unsichere Zugriffsrechte auf DHCP-Lease-Dateien in Verzeichnissen wie /var/lib/kea oder auf Kea-Logdateien in /var/log/kea. Weltweit lesbare Rechte ermöglichen es jedem lokalen Benutzer, sensible Netzwerkzustände oder Protokollinformationen einzusehen, was in manchen Umgebungen als erhebliche Datenschutzlücke angesehen werden muss. Obwohl keine aktive Eskalation hieraus direkt möglich ist, stellt der ungeschützte Zugriff auf derartige Daten einen Verstoß gegen gängige Sicherheitsprinzipien dar. Die Prüfung der Situation in verschiedenen populären Linux- und BSD-Distributionen verdeutlicht die vielfältigen Auswirkungen. Arch Linux oder FreeBSD sind beispielhaft vollumfänglich von allen relevanten Schwachstellen betroffen.
Debian und Ubuntu zeigen hingegen eine eingeschränkte Gefährdung, da sie Kea als Nicht-Root-Dienste betreiben und teilweise Sicherheitsmechanismen wie AppArmor einsetzen. Dennoch sind auch hier potentielle Angriffspfade vorhanden, die durch Umgehung oder Fehlkonfiguration ausgenutzt werden können. Fedora, openSUSE oder Gentoo zeigen wiederum unterschiedliche Varianten in der Konfiguration, was sich auf die individuellen Risiken auswirkt. Der Angriff auf Debian-Systeme verdeutlicht beispielhaft, wie komplex das Sicherheitsbild ist. Die Verwendung von AppArmor als Schutzmaßnahmen schränkt die möglichen Angriffe ein, doch wurde gezeigt, dass sich diese Profile mit bestimmten Techniken überwinden lassen können. So kann ein Angreifer durch das Setzen spezieller Zugriffslisten (Access Control Lists) auf dem eigenen Home-Verzeichnis die Ausführung manipulierter Hook-Bibliotheken trotz AppArmor indirekt ermöglichen.
Dies unterstreicht die Notwendigkeit, neben Software-Fixes auch auf Betriebssystemebene nachzubessern. Auf Seiten der Herausgeber und Maintainer von Kea hat diese Analyse zu wichtigen Maßnahmen geführt. Es wurden Bugfix Releases veröffentlicht, die spezifisch die problematischen Funktionen einschränken. Dazu gehört die konsequente Begrenzung der erlaubten Pfade für Hook-Bibliotheken, Konfigurations- und Logdateien, die jetzt nur noch aus oder in vertrauenswürdige Systemverzeichnisse lesen oder schreiben dürfen. Wichtiger noch ist die Einführung einer durchgängigen Authentifizierung auf der REST-API, um unbefugte Änderungen an den Diensten zu verhindern. Die Standardpfade für UNIX Domain Sockets wurden aus dem unsicheren /tmp in geschützte Verzeichnisse wie /var/run/kea verschoben, die keine weltweiten Schreibrechte besitzen. Zudem wurden die Dateirechte der Log- und Statusverzeichnisse restriktiver gestaltet, um Datenlecks zu vermeiden.
Diese Änderungen sind in aktuellen Kea-Versionen wie 2. 3 und 2. 7. 9 bereits enthalten. Neben der unmittelbaren Behebung dieser kritischen Schwachstellen sind auch weiterführende Sicherheitsempfehlungen relevant. Die Kea REST-API setzt das HTTP Basic Auth Verfahren ein, wobei möglicherweise Timing-Angriffe bei der Passwortprüfung noch nicht komplett ausgeschlossen sind. Ein sichereres Verfahren mit konstantzeitiger Vergleichsfunktion wird empfohlen, um Angriffe über statistische Laufzeitanalysen zu unterbinden. Auch sollte die Speicherung von Klartext-Passwörtern in der Kea-Konfiguration vermieden werden, da deren Offenlegung bei API-Konfigurationsabfragen einen weiteren Angriffsvektor darstellt. Es wird geraten, Passwörter in separaten, gut geschützten Dateien zu speichern und nur durch Referenzen in die Konfiguration zu integrieren.
Für Systemadministratoren bedeutet dies, die Kea-Installation umgehend auf eine gepatchte Version zu aktualisieren und die Konfiguration kritisch zu überprüfen. Die Aktivierung von Authentifizierung auf der REST-API muss Pflicht sein, ansonsten ist das System praktisch völlig offen für lokale Angriffe. Das Vermeiden von Socket-Pfaden in öffentlichen Verzeichnissen, die Restriktion der Zugriffsrechte auf Log- und State-Verzeichnisse und der Einsatz von Sicherheitsmechanismen wie AppArmor oder SELinux ergänzen die Schutzmaßnahmen. Die regelmäßige Kontrolle der Verzeichnisse auf unerwartete Dateien oder Sockets ist ebenfalls angezeigt. Insgesamt zeigt die Untersuchung der Kea DHCP-Software exemplarisch, wie moderne, flexiblere Netzwerkdienste auch mit neuen Angriffsflächen einhergehen können, gerade wenn sie mit vollen Systemrechten agieren und mangelhaft abgesicherte Schnittstellen bereitstellen.
Die Kombination aus ungeschütztem REST-API-Zugriff, fehlenden Zugriffsrestriktionen auf Systemressourcen und der Möglichkeit, eigenen Code als Hook-Library zu laden, führt zu einem gravierenden Sicherheitsrisiko. Mit den nun vorliegenden Patches und den beschriebenen Absicherungsmaßnahmen lässt sich das Risiko maßgeblich reduzieren. Nicht zuletzt unterstreicht der Fall Kea DHCP die Bedeutung von koordinierten Sicherheitsprüfungen im Open-Source-Umfeld und eines umfassenden Security Lifecycle Managements bei weit verbreiteten Netzwerkdiensten. Betreiber sollten frühzeitig Updates integrieren und die Patchzyklen der verwendeten Software aktiv beobachten. Die offene Kommunikation der Sicherheitslücken durch Teams wie das SUSE Security Team, die Zusammenarbeit mit den Maintainer-Communities und das rechtzeitige Einbeziehen der Distributionsbetreuer spielen eine essenzielle Rolle, um die Sicherheit der Infrastruktur langfristig zu gewährleisten und Angriffsflächen zu minimieren.
