Wenn man einen Anwendungs-Dienst betreibt, welcher nur für ein bestimmtes Release von Red Hat Enterprise Linux wie bspw. RHEL 8.4 freigegeben ist, gilt es effektiv zu verhindern, dass bei Updates Pakete installiert werden, die zu einem folgenden Release wie z.B. RHEL 8.5 gehören. Andernfalls verliert man bestenfalls die Unterstützung vonseiten des Herstellers der Anwendung. Im schlimmsten Fall ist die Anwendung nicht mehr lauffähig und man muss das Upade zurückrollen.
Hinweisvon Steffen Frömer (Senior Technical Account Manager bei Red Hat): Um Updates für ein spezifisches Minorrelease zu bekommen, auch wenn wie im Beispiel RHEL 8.5 bereits verfügbar ist, müssen Repositories mit verlängertem Support (z.B. Extended Update Support, EUS) verwendet werden. Andernfalls bekommt man keine Paketupdates.
Weiterführende Informationen zum Thema Extended Update Support bietet der Link unter [3].
Der folgende Code-Block zeigt, wie man Updates für ein RHEL-8-System auf das Release 8.4 beschränkt:
Das Kommando in der letzten Zeile, geht auf den Wissensartikel [1] zurück, welcher darauf hinweist, dass nur so der Paket-Cache sicher geleert wird. Dies ist notwendig, da der Paketmanager andernfalls fälschlicherweise Paketversionen eines höheren Release aus dem lokalen Cache installieren könnte, was zu Abhängigkeitsproblemen führt.
Mit folgendem Befehl lässt sich die Beschränkung wieder entfernen:
# subscription-manager release --unset
Release preference has been unset
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:
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.
