Im Zeitraum dieser Woche wurden einige Lösungen für verschiedene Probleme mit dem Linux-Kernel veröffentlichtEs wurden jedoch auch einige andere entdeckt, von denen Wanpeng Li kürzlich zwei Denial-of-Service (DOS) im Linux-Kernel entdeckte.
Womit das Ermöglicht lokalen Angreifern, einen Nullzeiger zu verwenden, um auf einen Fehler zum Auslösen eines DOS-Status zu verweisen.
Die erste Sicherheitslückemit der Nummer CVE-2018-19406 zu häufigen Sicherheitslücken und Gefährdungen, Es existiert in der Linux-Kernel-Funktion kvm_pv_send_ipi, die in der Datei arch / x86 / kvm / lapic.c definiert ist.
Die Sicherheitsanfälligkeit CVE-2018-19406 ist in Linux Kernel 4.19.2 vorhanden. Ermöglichen, dass der Angreifer aufwändige Systemaufrufe auf nicht reparierten Geräten verwendet, um den DOS-Status zu erreichen. Dieses Problem wird dadurch verursacht, dass der Advanced Programmable Interrupt Controller (APIC) nicht korrekt initialisiert wurde.
Wanpeng Li schrieb:
„Der Grund dafür ist, dass die apic-Map noch nicht initialisiert wurde. Der Testfall aktiviert die Schnittstelle pv_send_ipi durch vmcall, was dazu führt, dass auf kvm-> arch.apic_map nicht verwiesen wird. "Dieser Patch behebt das Problem, indem überprüft wird, ob die Apic-Karte NULL ist oder nicht, und wenn ja, sofort."
Die zweite von Wanpeng Li entdeckte Sicherheitsanfälligkeit ist auf Situationen beschränkt, in denen ein Angreifer physisch auf das Gerät zugreifen kann.
Dieses Problem ist in der nationalen Schwachstellendatenbank mit CVE-2018-19407 nummeriert und wird in der Funktion vcpu_scan_ioapic in arch / x86 / kvm / x86.c im Linux-Kernel 4.19.2 angezeigt, sodass lokale Benutzer einen Denial-of-Service verursachen können (NULL-Zeiger). Abweichung und BUG) durch entworfene Systemaufrufe, die eine Situation erreichen, in der ioapic nicht initialisiert ist.
Eine weitere Sicherheitsanfälligkeit, die den Linux-Kernel CVE-2018-18955 betrifft
Außerdem Auch im Laufe dieser Woche wurde eine Sicherheitslücke entdeckt (CVE-2018-18955) im UID / GID-Übersetzungscode aus dem Benutzernamensraum.
Zum Hauptbezeichnersatz, der Ermöglicht einem nicht privilegierten Benutzer mit Administratorrechten in einem isolierten Container (CAP_SYS_ADMIN), Sicherheitsbeschränkungen zu umgehen und auf Ressourcen außerhalb des Namespace des aktuellen Bezeichners zuzugreifen.
Wenn Sie beispielsweise ein freigegebenes Dateisystem in einem Container und einer Hostumgebung verwenden, können Sie den Inhalt der Datei / etc / shadow in der Hauptumgebung lesen, indem Sie sich direkt an i-node wenden.
Die Sicherheitsanfälligkeit besteht in Distributionen, die Kernel 4.15 und neuere Versionen verwenden, z. B. in Ubuntu 18.04 und Ubuntu 18.10, Arch Linux und Fedora (Kernel 4.19.2 mit Fix ist bereits in Arch und Fedora verfügbar).
RHEL und SUSE sind nicht betroffen. In Debian und Red Hat Enterprise Linux ist die Unterstützung des Benutzerbereichs nicht standardmäßig aktiviert, sondern in Ubuntu und Fedora enthalten.
Die Sicherheitsanfälligkeit wird durch einen Fehler im Linux-Kernel-Code 4.15 verursacht, der im Oktober letzten Jahres eingeführt wurde.
Das Problem wurde in den Versionen 4.18.19, 4.19.2 und 4.20-rc2 behoben.
Verletzlichkeit Es ist in der Funktion map_write () vorhanden, die in der Kerneldatei /user_namespace.c definiert ist. Dies wird durch eine fehlerhafte Verarbeitung verschachtelter Benutzer-ID-Bereiche verursacht, die mehr als 5 UID- oder GID-Bereiche verwenden.
Unter diesen Bedingungen funktioniert die Übersetzung der UID / GID-Bezeichner vom Namespace in den Kernel (Forward Map) korrekt, jedoch nicht während der Rückwärtskonvertierung (Reverse Map, vom Kernel zum Bezeichnerraum).
Es tritt eine Situation auf, in der die Benutzer-ID 0 (root) während der Vorwärtskonvertierung korrekt dem Bezeichner 0 im Kernel zugeordnet wird, jedoch nicht die tatsächliche Situation während der Rücktransformation widerspiegelt, die bei den Prüfungen inode_owner_or_capable () und privileged_wrt_inode_uidgid () verwendet wird.
Daher betrachtet der Kernel beim Zugriff auf einen Inode den Benutzer als ordnungsgemäß autorisiert, obwohl der Bezeichner 0 nicht aus dem Hauptsatz der Benutzer-IDs, sondern aus einem separaten Namespace verwendet wird.