CVE | My-IT-Brain

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.

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.

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.

Regelmäßig berichtet die IT-Fachpresse über neue Common Vulnerabilities and Exposures (CVE). Dieser Artikel möchte euch eine kleine Hilfestellung geben, um herauszufinden, ob euer RHEL-System von einem CVE betroffen ist.

In unserem Rechenzentrum betreibe ich ein Patchmanagement mit Ansible für unsere RHEL-Systeme. Dieses stellt sicher, dass einmal im Monat verfügbare Red Hat Security Advisories (RHSA) auf allen RHEL-Systemen installiert werden. Damit gewährleisten wir ein Mindestmaß an Sicherheit. Selbstverständlich können darüber hinaus alle System-Betreiber*innen zu jeder Zeit verfügbare Updates auf den von ihnen betreuten Servern installieren.

Wie eingangs erwähnt berichtet in der Regel die IT-Fachpresse über neue Sicherheitslücken und Schwachstellen. Diese Meldungen enthalten häufig auch die sogenannten CVE-Nummern, welche eine Schwachstelle/Sicherheitslücke eindeutig identifizieren. Mit Hilfe dieser Nummer könnt ihr feststellen, ob euer RHEL-System verwundbar ist und ob ggf. schon ein Patch existiert, welcher das Problem behebt.

Für diesen Text habe ich exemplarisch zwei Schwachstellen ausgewählt:

Nutzung der Red Hat CVE-Datenbank

Red Hat betreibt eine CVE-Datenbank unter der URL: https://access.redhat.com/security/security-updates/#/cve

Hier kann man nach einer CVE-Nummer suchen und zu weiterführenden Informationen zu einer Schwachstelle gelangen (siehe Abb. 1). Hinter dem Link in der Tabelle verbirgt sich eine Detail-Seite für den jeweiligen CVE.

Abb. 1: Screenshot der Red Hat CVE-Datenbank für CVE-2020-0543

Liefert eine Suche keine Treffer zurück, kann dies verschiedene Ursachen haben (siehe Abb. 2).

Abb. 2: Red Hat CVE-Datenbank liefert nicht zu jeder CVE-Nummer einen Treffer

Nutzung des Paket-Managers auf der Kommandozeile

Mit Hilfe des Paket-Managers YUM kann für jedes System individuell geprüft werden, ob für einen CVE ein entsprechender Fix existiert. Der folgende Codeblock veranschaulicht dies:

$ sudo yum updateinfo list --cve CVE-2020-0543                                
[...]
RHSA-2020:2432 Moderate/Sec. microcode_ctl-2:2.1-61.6.el7_8.x86_64
updateinfo list done
$
$ sudo yum updateinfo list --cve CVE-2020-13777
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
updateinfo list done
$

Die erste Abfrage nach CVE-2020-0543 zeigt, dass es ein Security-Advisory für ein installiertes Paket gibt, welches von der Schwachstelle betroffen ist. Gegen CVE-2020-13777 ist das System hingegen nicht verwundbar. Dies ist in diesem Fall der Tatsache geschuldet, dass GnuTLS auf dem genutzten System nicht installiert ist.

Mit Hilfe des folgenden Befehls lassen sich auch auf der Kommandozeile weitere Informationen zu einem CVE abrufen:

$ sudo yum updateinfo info --cve CVE-2020-0543 
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

===============================================================================
  Moderate: microcode_ctl security, bug fix and enhancement update
===============================================================================
  Update ID : RHSA-2020:2432
    Release : 0
       Type : security
     Status : final
     Issued : 2020-06-09 18:20:28 UTC
       Bugs : 1788786 - CVE-2020-0548 hw: Vector Register Data Sampling
	    : 1788788 - CVE-2020-0549 hw: L1D Cache Eviction Sampling
	    : 1827165 - CVE-2020-0543 hw: Special Register Buffer Data Sampling (SRBDS)
       CVEs : CVE-2020-0543
	    : CVE-2020-0548
	    : CVE-2020-0549
Description : Security Fix(es):
            : 
            : * hw: Special Register Buffer Data Sampling
            :   (SRBDS) (CVE-2020-0543)
            : 
            : * hw: L1D Cache Eviction Sampling (CVE-2020-0549)
            : 
            : * hw: Vector Register Data Sampling
            :   (CVE-2020-0548)
            : 
            : For more details about the security issue(s),
            : including the impact, a CVSS score,
            : acknowledgments, and other related information,
            : refer to the CVE page(s) listed in the References
            : section.
            : 
            : Bug Fix(es):
            : 
            : * Update Intel CPU microcode to microcode-20200602
            :   release, addresses:
            :   - Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0)
            :     microcode from revision 0x61f up to 0x621;
[...]

CVE durch Update schließen

Ich persönlich empfehle in der Regel, das gesamte System mittels sudo yum -y upgrade zu aktualisieren und so alle installierten Pakete auf den aktuellsten Stand zu bringen. Es ist jedoch auch möglich, nur die Updates zu installieren, die notwendig sind, um eine spezielle Schwachstelle zu schließen. Auch hierfür wird wieder die CVE-Nummer genutzt:

$ sudo yum upgrade --cve CVE-2020-0543
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
 --> mock-2.2-1.el7.noarch from @epel removed (updateinfo)
 --> unbound-libs-1.6.6-3.el7.x86_64 from @rhel-7-server-rpms removed (updateinfo)
 --> mock-2.3-1.el7.noarch from epel removed (updateinfo)
 --> unbound-libs-1.6.6-4.el7_8.x86_64 from rhel-7-server-rpms removed (updateinfo)
1 package(s) needed (+0 related) for security, out of 3 available
Resolving Dependencies
--> Running transaction check
---> Package microcode_ctl.x86_64 2:2.1-61.el7 will be updated
---> Package microcode_ctl.x86_64 2:2.1-61.6.el7_8 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================================================
 Package                              Arch                          Version                                   Repository                                 Size
==============================================================================================================================================================
Updating:
 microcode_ctl                        x86_64                        2:2.1-61.6.el7_8                          rhel-7-server-rpms                        2.6 M

Transaction Summary
==============================================================================================================================================================
Upgrade  1 Package

Total size: 2.6 M
Is this ok [y/d/N]:

Obigem Code-Block ist zu entnehmen, dass Updates für insgesamt drei Pakete zur Verfügung stehen. Um CVE-2020-0543 zu schließen, wird jedoch nur das Paket microcode_ctl aktualisiert. Die beiden anderen Pakete werden nicht verändert.

My-IT-Brain

A Blog with Tricks, Tools, Facts and Stuff around IT

Schlagwort-Archive: CVE

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