Schlagwort-Archive: Schwachstellen-Management

Neue Schwachstelle in Linux(-Paket) gefunden! Bin ich betroffen?

Es ist nur eine Frage der Zeit, bis die Fachpresse oder ein CERT über eine neue Schwachstelle im Linux-Kern oder einem der anderen für Linux verfügbaren Pakete berichtet. Diese Schwachstellen werden meist unter einer sogenannten CVE-Nummer geführt, welche die jeweilige Schwachstelle eindeutig referenziert.

In diesem Artikel beschreibe ich, wie ihr mit Hilfe der CVE-Nummer herausfinden könnt, ob euer System betroffen ist und wie ihr die aktualisierte Paketversion identifiziert, welche gegen die beschriebene Schwachstelle abgesichert ist. Der Text ist in Abschnitte gegliedert, welche die entsprechende Vorgehensweise für die Distributionen Debian (Link zum Abschnitt), RHEL (Link zum Abschnitt) und Ubuntu (Link zum Abschnitt) beschreiben.

Debian Security Bug Tracker

Unter der URL https://security-tracker.debian.org/tracker/ befindet sich der Security Bug Tracker des Debian-Projekts. Am Ende der Bug-Tracking-Seite gibt es ein Suchfeld, über welches man nach einer CVE-Nummer suchen kann.

screenshot-debian-security-bug-tracker
Screenshot: Security Bug Tracker

Der folgende Screenshot zeigt das Suchergebnis für CVE-2021-33909.

screenshot-search-result-cve-2021-33909
Screenshot: Ergebnis der Suche nach CVE-2021-33909

In der unter der Überschrift „Vulnerable and fixed Packages“ dargestellten Tabelle werden die verwundbaren und abgesicherten Paketversionen für die aktuell unterstützten Debian-Releases aufgeführt. So ist in diesem Fall das Paket für den Linux-Kern in Version 4.19.194-1 verwundbar, während mit der aktualisierten Version 4.19.194-3 eine abgesicherte Version bereitsteht.

Um nun zu sehen, welche Version auf dem eigenen System läuft, kann man z.B. das folgende Kommando verwenden, welches die Version des laufenden Kernels ausgibt:

tronde@host:~$ uname -v
#1 SMP Debian 4.19.194-2 (2021-06-21)

Da es sich bei der laufenden Version nicht um die abgesicherte Version handelt, ist davon auszugehen, dass das System verwundbar ist. Ein Update ist hier also angeraten.

Der folgende Code-Block zeigt, dass ein entsprechendes Update auch bereits angeboten wird (Ausgabe gekürzt):

tronde@host:~$ apt list --upgradable
Auflistung... Fertig
[...]
linux-image-4.19.0-17-amd64/stable 4.19.194-3 amd64 [aktualisierbar von: 4.19.194-2]
[...]

Für ein Nicht-Kernel-Paket sieht der Ablauf ein wenig anders aus. Nehmen wir dazu beispielhaft eine Schwachstelle im Paket systemd. Dazu suchen wir im Security Bug Tracker nach CVE-2021-33910.

screenshot-search-result-cve-2021-33910
Screenshot: Suchergebnis zu CVE-2021-33910

Die systemd-Paketversion 241-7~deb10u7 ist also gegen diese Schwachstelle verwundbar, während Version 241-7~deb10u8 abgesichert ist. Eine Möglichkeit, sich die installierte Version anzeigen zu lassen, besteht mit dem Befehl dpkg -l <PAKETNAME>, wobei die Spalte „Version“ die relevante Versionsnummer enthält:

tronde@host:~$ dpkg -l systemd
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name           Version       Architektur  Beschreibung
+++-==============-=============-============-=================================
ii  systemd        241-7~deb10u7 amd64        system and service manager

Der Ausgabe ist zu entnehmen, dass auch in diesem Fall die verwundbare Version installiert ist. Auch hier stehen Updates für mehrere Pakete zur Verfügung:

tronde@host:~$ apt list --upgradable | grep systemd

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libpam-systemd/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]
libsystemd0/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]
systemd-sysv/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]
systemd/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]

Ich empfehle an dieser Stelle, alle angebotenen Updates zu installieren, da diese in aller Regel mehr Vorteile als Nachteile für das aktuelle System bedeuten.

Red Hat CVE Database

Red Hat bietet unter der URL https://access.redhat.com/security/security-updates/#/cve eine Datenbank zur Suche nach CVEs an. Ruft man die URL auf, so werden existierende CVEs in umgekehrt chronologischer Reihenfolge angezeigt. Über das Suchfeld kann gezielt nach CVE-Nummern gesucht werden. Die Ergebnisse werden anschließend in tabellarischer Form präsentiert.

rh-cve-database
Screenshot: Red Hat CVE Database

Mit einem Klick auf die CVE-Nummer gelangt man auf eine Seite, welche die Schwachstelle im Detail beschreibt und darüber hinaus Informationen zur Mitigation und abgesicherten Paketen bietet. Der folgende Screenshot zeigt einen Auszug dieser Seite für CVE-2021-33909. Darin ist eine Tabelle dargestellt, welcher die betroffenen Plattformen und die jeweiligen Paketnamen zu entnehmen sind. Die Tabelle lässt sich über das Suchfeld weiter filtern und nach Spalten sortieren. So kann man leichter einen Überblick über alle von der Schwachstelle betroffenen Pakete der eigenen Plattform bekommen.

screenshot-affected-pkgs-and-issued-errata
Screenshot: Affected Packages and Issued Red Hat Security Errata for CVE-2021-33909

Red Hat behebt sicherheitsrelevante Probleme mit Hilfe sogenannter Red Hat Security Advisories (RHSA). Der Spalte Errata der obigen Tabelle ist das jeweilige RHSA zu entnehmen. Ein Klick darauf führt zur jeweiligen Beschreibung des RHSA. Es ist nicht unüblich, dass ein RHSA mehrere Schwachstellen adressiert, wie das Beispiel RHSA-2021:2725 zeigt. Darüber hinaus bieten die RHSA Informationen, welche Pakete aktualisiert wurden und ob ein Neustart des Systems erforderlich ist, um eine Schwachstelle zu schließen.

In dem hier gewählten Beispiel ist das RHEL7-Kernel-Paket kernel-3.10.0-1160.36.2.el7.x86_64.rpm gegen CVE-2021-33909 abgesichert. Folgender Befehl zeigt mir, dass dieses Paket auf meinem RHEL7-System noch nicht verwendet wird:

[tronde@rhel7 ~]$ uname -r
3.10.0-1160.31.1.el7.x86_64

Alternativ kann man die Paketversion auch mit dem Kommando rpm -qa | grep <PAKETNAME> ermitteln. Dieses Kommando funktioniert auch für Nicht-Kernel-Pakete.

[tronde@rhel7 ~]$ rpm -qa | grep kernel
kernel-3.10.0-1160.31.1.el7.x86_64
kernel-devel-3.10.0-1160.24.1.el7.x86_64
kernel-devel-3.10.0-1160.31.1.el7.x86_64
kernel-3.10.0-1160.24.1.el7.x86_64
texlive-l3kernel-svn29409.SVN_4469-45.el7.noarch
kernel-headers-3.10.0-1160.31.1.el7.x86_64
kernel-3.10.0-1160.21.1.el7.x86_64
abrt-addon-kerneloops-2.1.11-60.el7.x86_64
kernel-devel-3.10.0-1160.21.1.el7.x86_64
kernel-tools-libs-3.10.0-1160.31.1.el7.x86_64
kernel-tools-3.10.0-1160.31.1.el7.x86_64

Dank des RHEL-Paket-Managers YUM bzw. DNF und der in den Repositories bereitgestellten Metainformationen, müssen jedoch nicht mühsam Versionsnummern manuell abgeglichen werden. Die Kenntnis der CVE-Nummer oder des RHSA genügen. Der erste Code-Block zeigt, wie ein RHEL7-System gegen CVE-2021-33909 abgesichert werden kann (Ausgabe gekürzt):

[tronde@rhel7 ~]$ sudo yum --cves=CVE-2021-33909 update
[sudo] Passwort für tronde: 
Geladene Plugins: langpacks, nvidia, product-id, search-disabled-repos,
                : subscription-manager
[...]
7 package(s) needed (+0 related) for security, out of 27 available
Abhängigkeiten werden aufgelöst
--> Transaktionsprüfung wird ausgeführt
---> Paket bpftool.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket bpftool.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
--> Abhängigkeitsauflösung beendet
--> Transaktionsprüfung wird ausgeführt
---> Paket kernel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
--> Abhängigkeitsauflösung beendet

Abhängigkeiten aufgelöst

================================================================================
 Package            Arch    Version                  Paketquelle          Größe
================================================================================
Installieren:
 kernel             x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    50 M
 kernel-devel       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    18 M
Aktualisieren:
 bpftool            x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.5 M
 kernel-headers     x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   9.0 M
 kernel-tools       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
 kernel-tools-libs  x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.0 M
 python-perf        x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
Entfernen:
 kernel             x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   64 M
 kernel-devel       x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   38 M

Transaktionsübersicht
================================================================================
Installieren   2 Pakete
Aktualisieren  5 Pakete
Entfernen      2 Pakete

Gesamtgröße: 110 M
Is this ok [y/d/N]:

Mit diesem einen Befehl ist es möglich, gezielt alle betroffenen Pakete zu aktualisieren, um die Schwachstelle zu schließen. Sollen in einem Durchgang mehrere CVEs geschlossen werden, so können mehrere CVE-Nummern durch Kommata getrennt angegeben werden.

Ebenso ist es möglich, mit den RHSA-Nummern zu arbeiten, wie der folgende Code-Block zeigt (Ausgabe gekürzt):

[tronde@rhel7 ~]$ sudo yum --advisory=RHSA-2021:2725 update
Geladene Plugins: langpacks, nvidia, product-id, search-disabled-repos,
                : subscription-manager
[...]
7 package(s) needed (+0 related) for security, out of 27 available
Abhängigkeiten werden aufgelöst
--> Transaktionsprüfung wird ausgeführt
---> Paket bpftool.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket bpftool.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
--> Abhängigkeitsauflösung beendet
--> Transaktionsprüfung wird ausgeführt
---> Paket kernel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
--> Abhängigkeitsauflösung beendet

Abhängigkeiten aufgelöst

================================================================================
 Package            Arch    Version                  Paketquelle          Größe
================================================================================
Installieren:
 kernel             x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    50 M
 kernel-devel       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    18 M
Aktualisieren:
 bpftool            x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.5 M
 kernel-headers     x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   9.0 M
 kernel-tools       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
 kernel-tools-libs  x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.0 M
 python-perf        x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
Entfernen:
 kernel             x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   64 M
 kernel-devel       x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   38 M

Transaktionsübersicht
================================================================================
Installieren   2 Pakete
Aktualisieren  5 Pakete
Entfernen      2 Pakete

Gesamtgröße: 110 M
Is this ok [y/d/N]:

Auch hier können mehrere RHSA (oder auch RHBA und RHEA) durch Kommata getrennt angegeben werden. Die dargestellten Kommandos funktionieren selbstverständlich auch unter RHEL 8.

Damit ist es möglich, Schwachstellen gezielt und mit minimalen Auswirkungen auf das System zu schließen. Ich persönlich empfehle jedoch, das Patch-Fenster zu nutzen und sofern möglich alle verfügbaren Updates zu installieren. Denn in der Regel ist der Nutzen durch aktualisierte Pakete größer, als das Risiko eines potenziellen Schadens.

Die Paketmanager YUM und DNF bieten, Dank der von Red Hat bereitgestellten Metainformationen in den Repos, vielfältige Möglichkeiten, um die Installation oder Aktualisierung von Paketen granular zu steuern. Weiterführende Informationen finden sich den Manpages yum(8) und dnf(8).

In wie weit sich die hier beschriebene Vorgehensweise auch für CentOS Stream bzw. Fedora eignet, kann ich nicht sagen, da ich diese noch nicht untersucht habe.

Ubuntu CVE reports

Canonical stellt für Ubuntu unter der URL https://ubuntu.com/security/cve eine CVE-Datenbank bereit, in der sich der Status von Schwachstellen über deren CVE-Nummer recherchieren lässt.

screenshot-ubuntu-cve-reports-search
Screenshot: Ubuntu CVE reports search

Eine Suche nach einer CVE-Nummer führt zu einer Seiten mit einen Statusreport, welcher betroffene Pakete in den jeweiligen Releases und deren Status aufführt. Der folgende Screenshot zeigt dies beispielhaft für den CVE-2021-33909 und das Paket linux:

status-cve-2021-33909
Screenshot: Status des Paket ‚linux‘ zum CVE-2021-33909

Der Spalte „Status“ ist die Versionsnummer der abgesicherten Paketversion zu entnehmen. Die Vorgehensweise, um herauszufinden, welche Paketversion aktuell auf dem eigenen System installiert ist, entspricht der für Debian und kann im dortigen Abschnitt nachgelesen werden.

Zusammenfassung

Zumindest die im Rahmen dieses Artikels getesteten Distributionen bieten Webseiten, auf denen man sich zum Stand von Schwachstellen informieren kann. Dabei kann die in der Fachpresse oder vom CERT kommunizierte CVE-Nummer für eine gezielte Suche nach Informationen zur jeweiligen Schwachstelle verwendet werden.

Mir persönlich haben die Möglichkeiten von YUM und DNF zur granularen Steuerung und gezielten Mitigation von Schwachstellen am besten gefallen. Dabei sei jedoch erwähnt, dass ich längst nicht alle Distributionen und deren Paketwerkzeuge betrachtet habe.

Schwachstellen-Management mit Red Hat Insights

Nach der Einführung in Red Hat Insights und dem Blick auf den Advisor nehme ich in diesem Artikel das Schwachstellen-Management von Insights unter die Lupe.

shows-rh-insights-dashboard
Bild 1: Übersicht im Insights Dashboard

Bereits das Dasboard zeigt eine Box namens Vulnerability. Bild 1 zeigt, dass wir offensichtlich von 13 Schwachstellen betroffen sind. Diese sehen wir uns jetzt näher an. Dies geht wie üblich über den Link in der Box oder im Menü am linken Rand.

In der Vulnerability-Ansicht erwartet uns die gewohnte tabellarische Ansicht (vgl. Bild 2). Hier werden CVEs mit ihrer ID, dem Datum der Veröffentlichung, einer Bewertung des Impacts, dem CVSS base score und der Anzahl der betroffenen Systeme aufgeführt. Darüber hinaus hat man die Möglichkeit ein Business Risk und einen Status für ausgewählte oder alle CVEs zu vergeben (siehe gelbe Markierung in Bild 2).

rh-insights-vulnerability-view
Bild 2: Übersicht gefundener Schwachstellen mit Angabe von Impact, CVSS score und betroffener Systeme

Während man mit dem Business Risk festlegt, wie hoch man das Risiko einschätzt (vgl. Bild 3), hinterlegt man beim Status, wie mit der Behandlung der Schwachstelle(n) verfahren wird (siehe Bild 4).

edit-vulnerability-business-risk
Bild 3: Bewertung des Business Risk
rh-insights-edit-vulnerability-status
Bild 4: Mit Hilfe des Status kann der Bearbeitungsstand dokumentiert werden.

Wie im Advisor erhält man auch hier zu jeder CVE-ID eine Detailansicht mit Beschreibung des CVE, Bewertung und Übersicht der Angriffsvektoren (siehe Bild 5), sowie Verweisen zur Wissensdatenbank von Red Hat, wo ausführliche Informationen rund um den CVE und existierende Erratas zu finden sind.

rh-insights-cve-view-details
Bild 5: Detailansicht eines ausgewählten CVE

Bewertung des Schwachstellen-Managements

Stand heute betreiben wir kein aktives Schwachstellen-Management. Um ein gewisses Niveau an Sicherheit zu gewährleisten, nutzen wir ein Patchmanagement für RHEL, welches ich aus Bordmitteln unter Nutzung der Ansible Engine entwickelt habe. Dieses sorgt dafür, dass verfügbare Red Hat Security Advisories einmal im Monat auf allen RHEL-Systemen zwangsinstalliert werden, sofern diese noch fehlen.

Diesem Patch-Management ist es zu verdanken, dass auf den 13 angebundenen Testsystemen auch insgesamt nur 13 Schwachstellen gefunden wurden und darunter keine mit einem Score >= 8 gewesen ist.

Unter den im Dashboard aufgeführten Systemen waren Systeme einer Testinfrastruktur, die nicht an das zentrale Patchmanagement angebunden sind und nur unregelmäßig gepatcht werden. Insights hat mir hier vor Augen geführt, dass das Risiko viel zu groß ist, dass diese Systeme einfach vergessen werden. Deshalb wurden diese Hosts nun auch umgehend mit ins Patchmanagement aufgenommen.

Deutlich interessanter finde ich, dass mich Insights auf die CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 und CVE-2019-11091 aufmerksam gemacht hat.

Diese Schwachstellen haben gemeinsam, dass sie sich nicht einfach durch die Installation eines Updates schließen lassen. Da es sich um virtuelle Maschinen (VM) auf einem vSphere-Cluster handelt ist eine Kombination von Maßnahmen erforderlich, um die Schwachstellen zu mitigieren.

In diesem konkreten Fall müssen die betroffenen VMs lediglich einmal Aus- und wieder Eingeschaltet werden, da ein Teil der Mitigation in vSphere bereits vorhanden war. Dadurch werden neue CPU-Funktionen an das Gast-Betriebssystem propagiert und die Mitigation ist abgeschlossen.

Leider muss ich eingestehen, dass diese Schwachstellen ohne Insights noch lange Zeit unentdeckt geblieben wären.

Nun muss ich davon ausgehen, dass in unserer Umgebung noch weitere verwundbare Systeme existieren. Da ich diese nicht an Insights anbinden darf, werde ich diese mit einem von Red Hat bereitgestellten Skript ausfindig machen. Das Red Hat eben solche Skripte zur Verfügung stellt, um sich auch ohne Insights wirksam selbst helfen zu können, schätze ich an Red Hat sehr. Es gibt da draußen noch einige Unternehmen, die diesem Beispiel ruhig folgen dürfen.

Persönlich halte ich aktives Schwachstellen-Management für sinnvoll. Nur durch kontinuierliche Kontrolle können Schwachstellen gefunden, bewertet und entsprechend behandelt werden. Gleichzeitig dient es der Überprüfung, ob bzw. wie bereits getroffene Maßnahmen zur strukturellen Verbesserung des Sicherheits-Niveaus (z.B. ein Patchmanagement) wirken.

Bild 6: Alle erkannten Schwachstellen wurden geschlossen

Bild 6 zeigt, dass gegenwärtig keine offenen Schwachstellen mehr existieren. Dies sollte stets das Ziel sein.

Mir selbst hat der Test des Schwachstellen-Managements Freude bereitet und die gefundenen Schwachstellen konnten innerhalb kurzer Zeit geschlossen werden.

Der nächste Artikel dieser Reihe wird sich dem Compliance-Service widmen.