CVE-2020-5208 in Wazuh: Warum ipmitool 1.8.19 unter Ubuntu 24.04 als verwundbar erscheint

Einleitung

Bei der Bewertung von Schwachstellen in Linux-Umgebungen reicht ein Vergleich der installierten Softwareversion mit der Upstream-Versionsangabe häufig nicht aus. Distributionen pflegen eigene Pakete, übernehmen Sicherheitspatches per Backport und veröffentlichen distributionsspezifische Statusinformationen. Dadurch kann eine vermeintlich eindeutige Aussage wie „ab Version 1.8.19 behoben“ im konkreten Betriebssystemkontext zu einem anderen Ergebnis führen.

Ein typisches Beispiel ist CVE-2020-5208 in ipmitool. Obwohl das Upstream-Projekt Version 1.8.19 als korrigierte Version nennt, kann Wazuh das Paket auf Ubuntu 24.04 LTS weiterhin als verwundbar einstufen. Das ist nicht zwangsläufig ein Fehler in Wazuh, sondern kann aus der Sicherheitsbewertung des Distributionsherstellers resultieren.

Der Fall zeigt, wie wichtig es ist, bei Wazuh-Funden sowohl das durch Syscollector erfasste Paket als auch den zugrunde liegenden Hersteller-Feed zu prüfen.

Ausgangslage / Problemstellung

Auf einem mit Wazuh überwachten Ubuntu-24.04-System wurde für das Paket ipmitool die Schwachstelle CVE-2020-5208 angezeigt. Das Softwareinventar meldete eine installierte Version aus der Versionslinie 1.8.19.

Diese Kombination wirkte zunächst widersprüchlich:

Die Beschreibung der CVE nennt ipmitool-Versionen vor 1.8.19 als betroffen.
Das Upstream-Sicherheitsadvisory führt 1.8.19 als korrigierte Version.
Auf dem betroffenen Ubuntu-System war bereits eine 1.8.19-Version installiert.
Wazuh führte die Schwachstelle trotzdem als aktiv.

Die für die Untersuchung erforderlichen Informationen waren bereits zentral im Wazuh Dashboard verfügbar. Ein direkter Zugriff auf den Endpoint war zunächst nicht notwendig. Entscheidend war jedoch, nicht nur einen zusammengefassten Bericht zu betrachten, sondern den konkreten Paketdatensatz und den zugehörigen Vulnerability-Detection-Eintrag.

Für die Analyse werden mindestens folgende Angaben benötigt:

Betriebssystem und Release, beispielsweise Ubuntu 24.04 LTS
Paketname
vollständige Paketversion einschließlich Ubuntu-Revision
Paketarchitektur
Paketformat
betroffener Wazuh Agent
CVE-ID
Status und Quelle der Schwachstellenbewertung

Technische Analyse

Sicherheitsauswirkung von CVE-2020-5208

CVE-2020-5208 betrifft mehrere Funktionen von ipmitool, die Daten von entfernten IPMI-Systemen nicht ausreichend validieren. Manipulierte Antworten eines über das Netzwerk angesprochenen IPMI-Geräts können Speicherüberläufe verursachen. Abhängig vom ausgeführten Code und vom Betriebskontext sind ein Absturz oder die Ausführung von Schadcode auf dem System möglich, auf dem ipmitool läuft.

Besonders kritisch ist der Einsatz mit erhöhten Berechtigungen. Wird ipmitool als root oder über privilegierte Automatisierungsprozesse ausgeführt, kann eine erfolgreiche Ausnutzung entsprechend weitreichende Auswirkungen haben. Das Upstream-Projekt nennt Version 1.8.19 als gepatchte Version und empfiehlt als vorübergehende Risikoreduzierung, ipmitool nicht privilegiert und nicht gegen nicht vertrauenswürdige IPMI-Geräte einzusetzen. Einen vollständigen Workaround gibt es laut Advisory nicht.

Warum die Upstream-Version allein nicht ausreicht

Bei Linux-Distributionen muss zwischen der Upstream-Version und der vollständigen Paketversion der Distribution unterschieden werden.

Eine Paketversion wie

1.8.19-7build2

besteht beispielsweise aus:

1.8.19: Upstream-Version
-7build2: distributionsspezifische Debian- beziehungsweise Ubuntu-Revision

Der Hersteller kann Patches zurückportieren, einzelne Änderungen abweichend integrieren, Pakete neu bauen oder die Betroffenheit anhand der tatsächlich ausgelieferten Quellen bewerten. Deshalb ist die numerische Upstream-Version allein kein zuverlässiger Nachweis dafür, dass eine CVE in einem bestimmten Distributionspaket behoben ist.

Der Status von CVE-2020-5208 verdeutlicht dies besonders gut. Canonical führt das Paket für Ubuntu 24.04 LTS ausdrücklich als „Vulnerable“. Ubuntu 22.04 LTS wird dagegen als „Not affected“ bewertet. Für Ubuntu 20.04 LTS wurde die Schwachstelle bereits in 1.8.18-8ubuntu0.1 behoben – also in einer Paketversion, deren Upstream-Anteil kleiner als 1.8.19 ist.

Damit können gleichzeitig folgende Aussagen korrekt sein:

Das Upstream-Projekt hat die Schwachstelle mit Version 1.8.19 behoben.
Eine Distribution kann eine ältere Upstream-Version durch einen Backport absichern.
Ein Distributionshersteller kann ein Paket mit derselben Upstream-Version weiterhin als betroffen kennzeichnen.
Ein Vulnerability Scanner kann auf Basis des Hersteller-Feeds deshalb einen Fund erzeugen.

Wie Wazuh die Schwachstelle ermittelt

Die Wazuh-Erkennung beginnt auf dem Endpoint. Der Wazuh Agent verwendet das Syscollector-Modul, um unter anderem folgende Daten zu erfassen:

Betriebssystem
Betriebssystemversion
installierte Pakete
Paketversionen
Architekturen
Paketformate

Diese Informationen werden an den Wazuh Server übertragen. Die Vulnerability-Detection-Komponente korreliert das Inventar anschließend mit den Schwachstelleninformationen der Wazuh Cyber Threat Intelligence Platform.

Wazuh CTI konsolidiert Informationen verschiedener Quellen. Für unterstützte Ubuntu-Versionen gehören dazu insbesondere die Sicherheitsinformationen von Canonical. Wird das konkrete Ubuntu-Paket im Hersteller-Feed als betroffen geführt, kann Wazuh die Schwachstelle als aktiv anzeigen, auch wenn eine allgemeine Upstream-Beschreibung Version 1.8.19 als korrigiert bezeichnet.

Der Fund ist daher nicht als einfacher Versionsvergleich nach dem Muster

installierte Version >= 1.8.19

zu verstehen. Betriebssystem, Paketname, Distributionsversion, Paketrevision und die Angaben des jeweiligen Security Providers fließen in die Bewertung ein.

IT Hygiene und Vulnerability Detection erfüllen unterschiedliche Aufgaben

Für eine belastbare Analyse müssen zwei Ansichten miteinander verglichen werden.

Unter Security operations > IT Hygiene > Software > Packages befindet sich das von Syscollector erfasste Softwareinventar. Dort sollte nach ipmitool gesucht und der vollständige Paketdatensatz geöffnet werden. Die Ansicht zeigt, was auf dem Endpoint tatsächlich installiert ist.

Unter Threat intelligence > Vulnerability Detection > Inventory wird dagegen angezeigt, welche Schwachstellen Wazuh mit diesem Inventar verknüpft hat. Ein geeigneter Filter ist beispielsweise:

package.name: ipmitool AND vulnerability.id: CVE-2020-5208

Die erste Ansicht beantwortet somit die Frage „Welche Software ist installiert?“. Die zweite beantwortet die Frage „Welche bekannte Schwachstelle wurde diesem Paket zugeordnet?“.

Ein exportierter PDF-Bericht kann für Dokumentationszwecke nützlich sein, ersetzt aber nicht die Prüfung der zugrunde liegenden Paket- und Vulnerability-Datensätze.

Lösung / Best Practices

1. Vollständigen Paketdatensatz in IT Hygiene prüfen

Im Wazuh Dashboard wird zunächst der betroffene Agent ausgewählt. Anschließend erfolgt die Navigation zu:

Security operations
└── IT Hygiene
    └── Software
        └── Packages

Dort wird nach folgendem Paket gesucht:

ipmitool

Zu dokumentieren sind mindestens:

agent.name
host.os.name
host.os.version
package.name
package.version
package.architecture
package.type
package.vendor

Besonders wichtig ist package.version. Die Angabe sollte vollständig einschließlich Ubuntu-Revision übernommen werden. Eine verkürzte Darstellung wie „1.8.19“ kann entscheidende Paketinformationen ausblenden.

2. Vulnerability-Detection-Eintrag korrelieren

Danach wird unter Threat intelligence > Vulnerability Detection > Inventory nach der CVE und dem Paket gefiltert:

package.name: ipmitool AND vulnerability.id: CVE-2020-5208

Im Detailfenster sollten folgende Felder kontrolliert werden:

vulnerability.id
vulnerability.status
vulnerability.severity
vulnerability.description
package.name
package.version
host.os.name
host.os.version

Je nach Wazuh-Version enthält der Eintrag zusätzlich Informationen darüber, warum das Paket als betroffen bewertet wurde, sowie einen Verweis auf Wazuh CTI.

3. Herstellerstatus statt ausschließlich Upstream-Version prüfen

Für Ubuntu-Systeme ist anschließend die Canonical-CVE-Seite für das konkrete Release zu prüfen.

Für CVE-2020-5208 lautet die relevante Kombination:

Paket:  ipmitool
Release: Ubuntu 24.04 LTS
Status: Vulnerable

Solange Canonical diesen Status veröffentlicht und keine korrigierte Ubuntu-Paketversion nennt, ist der Wazuh-Fund aus Sicht des Hersteller-Feeds nachvollziehbar. Die installierte Upstream-Version 1.8.19 allein reicht nicht aus, um den Fund als False Positive zu schließen. Canonical definiert den Status „Vulnerable“ ausdrücklich als ein Paket, das für das jeweilige Ubuntu-Release von der Schwachstelle betroffen ist.

4. Paketinformationen direkt auf dem Endpoint verifizieren

Steht ein administrativer Zugriff zur Verfügung, können Paketversion und Updatequelle zusätzlich lokal geprüft werden:

dpkg-query -W -f='${Package}\t${Version}\t${Architecture}\n' ipmitool

apt-cache policy ipmitool

Die erste Abfrage zeigt die tatsächlich installierte vollständige Version. apt-cache policy zeigt zusätzlich die installierte Version, den verfügbaren Kandidaten und die verwendeten Paketquellen.

Anschließend sollte ein reguläres Systemupdate durchgeführt werden:

sudo apt update
sudo apt upgrade

Canonical empfiehlt, Sicherheitskorrekturen über die regulären Ubuntu-Paketquellen einzuspielen und nicht einzelne Binärpakete oder Bibliotheken aus fremden Releases herauszulösen.

Ist nach dem Update keine neuere korrigierte Paketversion verfügbar und wird das Paket weiterhin als verwundbar geführt, liegt derzeit keine über den verwendeten Repository-Kanal verfügbare vollständige Behebung vor.

5. Keine nicht unterstützte Upstream-Version über das Ubuntu-Paket installieren

Das manuelle Kompilieren einer neueren Upstream-Version kann den Versionskonflikt scheinbar lösen, führt in verwalteten Umgebungen jedoch häufig zu neuen Problemen:

Das Paket ist nicht mehr durch apt verwaltet.
Abhängigkeiten können von den Ubuntu-Paketständen abweichen.
Sicherheitsupdates des Distributionsherstellers greifen nicht mehr zuverlässig.
Syscollector kann parallel weiterhin das alte Distributionspaket erkennen.
Automatisierte Patch- und Compliance-Prozesse verlieren ihre eindeutige Paketzuordnung.

Eine manuell installierte Binärdatei sollte daher nicht als Standardlösung betrachtet werden. Erforderliche Abweichungen müssen über einen kontrollierten Build-, Test-, Signierungs- und Lifecycle-Prozess verwaltet werden.

6. Kompensierende Maßnahmen anwenden

Ist noch kein korrigiertes Paket verfügbar, sollte geprüft werden, ob ipmitool überhaupt benötigt wird.

Wird es nicht benötigt, kann das Paket entfernt werden:

sudo apt remove ipmitool

Vor der Entfernung ist zu prüfen, ob Hardwareüberwachung, Bare-Metal-Automatisierung, Monitoring-Plugins oder Wartungsskripte von ipmitool abhängen.

Ist eine Entfernung nicht möglich, sind mindestens folgende Maßnahmen sinnvoll:

ipmitool nur bei konkretem Bedarf ausführen.
Die Ausführung mit root soweit technisch möglich vermeiden.
IPMI-Kommunikation auf ein separates Managementnetz beschränken.
Ausgehende Verbindungen zu IPMI-Interfaces über Firewall-Regeln oder ACLs begrenzen.
Nur bekannte und administrativ kontrollierte BMC- beziehungsweise IPMI-Zielsysteme zulassen.
Automatisierungsjobs und Skripte auf unnötige privilegierte Aufrufe prüfen.
Aufrufe von ipmitool protokollieren und überwachen.

Diese Maßnahmen reduzieren die Angriffsfläche, ersetzen aber keine Herstellerkorrektur. Das Upstream-Advisory weist ausdrücklich darauf hin, dass keine vollständige Umgehung existiert.

7. Syscollector-Aktualisierung sicherstellen

Damit Wazuh eine Paketänderung erkennt, muss Syscollector die Paketinformationen erneut erfassen. Die Paketinventarisierung ist in der Standardkonfiguration aktiviert:

<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <os>yes</os>
  <packages>yes</packages>
</wodle>

Die entscheidenden Optionen sind:

<disabled>no</disabled>
<scan_on_start>yes</scan_on_start>
<os>yes</os>
<packages>yes</packages>

Nach einer Paketaktualisierung kann entweder das konfigurierte Scanintervall abgewartet oder der Wazuh Agent kontrolliert neu gestartet werden:

sudo systemctl restart wazuh-agent

Mit aktiviertem scan_on_start wird beim Start eine neue Inventarisierung angestoßen. Das Standardintervall für Syscollector beträgt eine Stunde.

8. Ergebnis erneut bewerten

Nach der Synchronisation werden beide Ansichten erneut geprüft:

Unter IT Hygiene > Software > Packages muss die erwartete Paketversion erscheinen.
Unter Vulnerability Detection > Inventory wird kontrolliert, ob CVE-2020-5208 weiterhin aktiv ist.
Wurde das Paket entfernt oder durch eine laut Hersteller-Feed korrigierte Version ersetzt, sollte der aktive Inventareintrag nach der Verarbeitung verschwinden beziehungsweise als gelöst erfasst werden.
Bleibt der Canonical-Status für Ubuntu 24.04 auf „Vulnerable“, kann die Schwachstelle trotz unveränderter Upstream-Versionsbewertung weiterhin aktiv bleiben.

Eine manuelle Löschung des Vulnerability-Index oder eine globale Unterdrückung der CVE wäre keine technische Behebung. Falls das Risiko akzeptiert werden muss, sollte dies über den etablierten Risk-Acceptance-Prozess dokumentiert werden. Dabei sollten betroffene Systeme, Kompensationsmaßnahmen, Verantwortliche und ein Wiedervorlagedatum festgehalten werden.

Lessons Learned / Best Practices

Distributionsstatus hat Vorrang vor vereinfachten Versionsvergleichen

Bei distributionsverwalteten Paketen ist die Bewertung des Betriebssystemherstellers regelmäßig aussagekräftiger als eine isolierte Upstream-Versionsgrenze. Backports führen dazu, dass ältere Versionen sicher sein können. Abweichende Paketstände oder Herstellerbewertungen können umgekehrt dazu führen, dass eine nominell korrigierte Upstream-Version weiterhin als betroffen gilt.

Immer die vollständige Paketversion erfassen

Für eine Schwachstellenanalyse müssen Versionsangaben einschließlich Epoch, Debian- beziehungsweise Ubuntu-Revision und Build-Suffix dokumentiert werden. Nur damit lässt sich ein Paket eindeutig einem Hersteller-Advisory zuordnen.

Inventar und Schwachstellenbewertung getrennt untersuchen

IT Hygiene liefert den technischen Ist-Zustand des Endpoints. Vulnerability Detection liefert die daraus abgeleitete Sicherheitsbewertung. Erst der Vergleich beider Datensätze ermöglicht eine belastbare Analyse.

Hersteller-Feeds regelmäßig neu bewerten

Ein aktiver Fund kann sich durch eine Aktualisierung des Schwachstellen-Feeds ändern, auch wenn auf dem Endpoint noch keine Änderung erfolgt ist. Umgekehrt reicht ein Paketupdate nur dann zur Bereinigung aus, wenn die neu installierte Version im Hersteller-Feed als nicht betroffen oder korrigiert bewertet wird.

Risikoreduktion nicht mit Remediation verwechseln

Netzwerksegmentierung, eingeschränkte Berechtigungen und kontrollierte Zielsysteme senken die Wahrscheinlichkeit einer Ausnutzung. Die Schwachstelle selbst ist damit jedoch nicht beseitigt. Solche Maßnahmen müssen als kompensierende Kontrollen und nicht als Patch dokumentiert werden.

Wazuh-Funde nicht vorschnell als False Positive schließen

Ein Unterschied zwischen Upstream-Advisory und Wazuh-Anzeige ist zunächst ein Untersuchungsanlass. Vor einer Ausnahme müssen mindestens Paketrevision, Betriebssystemrelease, Herstellerstatus und Wazuh-Inventardaten überprüft werden.

Fazit

Dass Wazuh CVE-2020-5208 für ipmitool 1.8.19 unter Ubuntu 24.04 LTS anzeigt, ist nicht automatisch ein Erkennungsfehler. Während das Upstream-Projekt Version 1.8.19 als korrigiert bezeichnet, führt Canonical das Paket für Ubuntu 24.04 weiterhin als verwundbar. Wazuh korreliert das von Syscollector erfasste Softwareinventar mit distributionsspezifischen Sicherheitsinformationen und kann deshalb zu einer anderen Bewertung als ein einfacher Upstream-Versionsvergleich kommen.

Für eine belastbare Entscheidung müssen das konkrete Paket unter IT Hygiene > Software > Packages, der Eintrag unter Vulnerability Detection > Inventory und der Herstellerstatus gemeinsam betrachtet werden. Ist noch kein korrigiertes Ubuntu-Paket verfügbar, bleiben die Entfernung des Pakets, die Einschränkung seiner Nutzung oder dokumentierte kompensierende Kontrollen die sinnvollsten Maßnahmen.