CleanPress

Kategorie: Security

  • Erneut Sicherheitsprobleme bei X.Org

    X.org-Server 21.1.0

    Dieser Tage veröffentlichte Jan-Niklas Sohn von der Trend Micro Zero Day Initiative einige neu entdeckte Sicherheitsprobleme bei X.Org. Bereits seit einigen Jahren gilt X.Org als Sicherheitsrisiko und es tauchen immer wieder Sicherheitsprobleme auf. Der derzeitige X.Org-Betreuer Povilas Kanapickas, der erst kürzlich X.Org Server 21.1.0 freigegeben hatte, veröffentlichte Details dazu auf der X.Org-Mailingliste.

    Jan-Niklas Sohn entdeckte, dass der X.Org-Server bestimmte Eingaben nicht korrekt behandelt. Ein Angreifer könnte dieses Problem nutzen, um den Server zum Absturz zu bringen, was zu einem Denial-of-Service führt, oder möglicherweise lokal die Privilegien eskalieren und beliebigen Code ausführen.

    Alle vier Lücken betreffen die Eingabevalidierung in X-Server-Erweiterungen und sind folgendermaßen katalogisiert:

    Betroffen sind sowohl der Xorg-Server als auch XWayland. Patches für alle vier Lücken stehen auf Gitlab bereit. Bei Canonical sind etwa alle Versionen seit Ubuntu 18.04 LTS betroffen, bei Debian alle Ausgaben seit Debian 9. »Stretch«. Während Canonical bereits gepatchte Pakete für alle Versionen bereithält, ist bei Debian derzeit nur Unstable gepatched. Bei Arch Linux ist xorg-server noch verwundbar, während, xorg-wayland gepatched ist. Auch openSUSE hat Patches für die betroffenen Produkte.

    EDIT: Mittlerweile liegt eine neue Version des X.Org-Servers vor, die bei den Distributionen getestet wird. xorg-server 21.1.2 wurde gestern Nachmittag offiziell vorgestellt. Diese Version behebt die vier gemeldeten Sicherheitslücken und mehrere Regressionen. Insbesondere werden die tatsächlichen physischen Abmessungen durch den X-Server nicht mehr gemeldet, da dies fehlerhaft war. Ab nun werden generell 96 DPI gemeldet, so wie es auch XWayland tut. Eine bessere Lösung für die Zukunft wäre laut Betreuer Povilas Kanapickas wäre, die Standard-DPI so zu belassen, wie sie ist, und das richtige Verhalten mit einer Kommandozeilenoption zu aktivieren (vielleicht -dpi auto oder ähnlich).

  • OpenSSH 8.8 deaktiviert Support für RSA-SHA

    Photo by FLY:D on Unsplash

    OpenSSH ist eine auf dem SSH-Protokoll basierende Sammlung von abgesicherten Werkzeugen zum Netzwerken. Das gerade veröffentlichte OpenSSH 8.8 deaktiviert die Unterstützung für RSA-Signaturen mit dem SHA-1-Hash-Algorithmus. Für die meisten Benutzer sollte diese Änderung unmerkbar sein und es besteht keine Notwendigkeit, ssh-rsa-Schlüssel zu ersetzen, da die Funktion UpdateHostKeys die Clients auf einen verlässlicheren Algorithmus aktualisiert. Inkompatibilitäten können lediglich bei Verwendung älterer SSH- Implementierungen auftreten.

    Sicherheitsproblem bei sshd behoben

    Darüber hinaus kündigen die Entwickler an, in einer der nächsten Ausgaben von OpenSSH scp, das Protokoll zur verschlüsselten Übertragung von Daten von der Verwendung des scp/rcp-Protokolls auf die Verwendung von SFTP umzustellen. Die neue Version behebt zudem ein Sicherheitsproblem, das dadurch verursacht wurde, dass sshd seit OpenSSH 6.2 Benutzergruppen fälschlicherweise initialisierte, wenn Befehle aus den Sektionen Authorized Keys Command und Authorized Principals Command ausgeführt wurden, bei denen eine AuthorizedKeysCommandUser– oder AuthorizedPrincipalsCommandUser-Direktive gesetzt wurde, um den Befehl unter einem anderen Benutzer auszuführen. Dadurch konnten je nach Systemkonfiguration unbeabsichtigte Nutzerprivilegien vergeben werden.

  • Red Hat gibt Firewalld 1.0.0 frei

    Red Hat gibt Firewalld 1.0.0 frei

    Firewalld ist ein grafisches Frontend für die Befehlszeilenprogramme iptables und nftables des Netfilter-Frameworks im Kernel. Mit Firewalld lassen sich dauerhafte Regeln für den Netzwerkverkehr setzen, ohne dass man sich in die Gefilde von chains, jumps, accepts und denies begeben muss. Vielmehr regelt Firewalld den Netzverkehr mit einem Zonenmodell mit vordefinierten anpassbaren Regelsätzen. Zonen für bestimmte Szenarien lassen die dafür erlaubten Dienste herein und blockieren alles andere.

    10 Jahre bis zur 1.0.0

    Jetzt hat Red Hat nach 10 Jahren und vielen Minor-Versionen eine stabile Version 1.0.0 veröffentlicht, die auch einige nicht kompatible Neuerungen im Gepäck hat, aber auch Ballast abwirft. So wurde die Kompatibilität zu Python 2 über Bord geworfen und der tftp-client-Dienst entfernt. Das iptables-Backend geht in Rente. Bereits seit Firewalld 0.6 wird das modernere nftables unterstützt. Obwohl als veraltet markiert, wird iptables noch lange in Firewalld verfügbar bleiben.

    Intra Zone-Weiterleitung wird zum Standard

    Das mit Firewalld 0.8 eingeführte Intra Zone Forwarding wird mit 1.0.0 zum Standard. Das ermöglicht die freie Weiterleitung von Paketen zwischen Schnittstellen oder Quellen innerhalb einer Zone, wie es auch bei anderen auf Zonen basierten Firewalls der Fall ist. Für das nftables-Backend wurden die NAT-Regeln zur iNet-Familie zusammengefasst und damit die bisherige Regelduplizierung für ip- und ip6-sets überflüssig.

    Firewalld wird im Herbst mit Fedora 35 als Standard-Firewall ausgeliefert. Außerdem ist Firewalld bei openSUSE, SUSE, Red Hat und CentOS sowie dessen Nachfolgern AlmaLinux und Rocket Linux im Einsatz. Firewalld ist darüber hinaus in den meisten Distributionen aus den Archiven installierbar. Alle Änderungen können im Detail im Blog des Projekts nachgelesen werden. Das Konzept von Firewalld wird in einem Artikel im Sysadmin-Blog näher erläutert.

  • Sicherheitslücken im Kernel und bei Systemd geschlossen

    Systemd Lücke
    Quelle: Negative Space | Lizenz: CC0

    Die Forscher des Sicherheitsunternehmens Qualys haben eine Sicherheitslücke im System- und Sitzungs-Manager Systemd entdeckt. Bei erfolgreicher Ausnutzung der Lücke kann ein unprivilegierter Angreifer Systemd zum Absturz bringen und eine Kernel-Panik auslösen.

    Lücke seit Systemd v220 vorhanden

    Die Sicherheitslücke wurde bereits in Systemd v220 im April 2015 durch den Commit 7410616c eingeführt. Anfang Juni informierte Qualys dann das Red Hat Security Team über die als CVE-2021-33910 katalogisierte Lücke. Einen Monat später wurden Patches von Red Hat an die Mailing-Liste linux-distros@openwall geschickt. Am gestrigen 20. Juli wurde die Lücke dann öffentlich bekannt gemacht.

    Angesichts der Breite der Angriffsfläche für diese Schwachstelle empfiehlt Qualys den Anwendern, die Patches für diese Schwachstelle sofort anzuwenden.

    Bharat Jogi, Qualys Senior Manager für Sicherheitsrisiken

    Die Lücke ermöglicht es Angreifern, die Funktion alloca() mit einer unkontrollierten Größe in der Funktion unit_name_path_escape ein Dateisystem auf einem sehr langen Pfad einzuhängen, sodass es zu einem Speicherfehler kommt, der Systemd und in der Folge das gesamte Betriebssystem zum Absturz bringt, da zu viel Speicherplatz im Systemd-Stack verwendet wird.

    Patches werden verteilt

    Die Patches werden bereits in den betroffenen Distributionen verteilt. Bei Debian Unstable etwa kam der Patch gestern in Form von systemd 247.3-6. Es ist dies nicht die erste Sicherheitslücke in Systemd und es wird vermutlich nicht die letzte sein. Kritiker werfen Systemd immer wieder vor, durch seine Komplexität solchen Lücken Vorschub zu leisten. Egal wie man dazu steht, wer Systemd verwendet, sollte das Update mit dem Patch möglichst zeitnah einspielen.

    Kernel-Lücke

    Zeitgleich hat Qualys eine weitere Lücke im Linux-Kernel entdeckt, die als CVE-2021-33909 katalogisiert wurde. Es handelt sich um einen Out-of-Bounds-Write-Fehler in der Funktion seq_file in der Dateisystemschicht des Kernels. Durch diesen Fehler kann ein lokaler Angreifer mit Nutzerprivilegien Zugriff auf Speicher erhalten, was zu einem Systemabsturz oder einem Leck in internen Kernel-Informationen führen kann. Das Problem resultiert daraus, dass die size_t-zu-int-Konvertierung vor der Ausführung von Operationen nicht validiert wird.

  • Report: Open-Source-Bibliotheken in Unternehmen kaum aktualisiert

    Bibliotheken selten aktualisiert
    Photo by Florian Olivo on Unsplash

    Ein 36-seitiger Report über die Sicherheit von Software von Sicherheitsanbieter Veracode mit dem Titel State of Software Security (SoSS) v11: Open Source Edition, der im Juni veröffentlicht wurde, stellt einem Großteil der Bibliotheken von Drittanbietern in Repositories ein schlechtes Zeugnis aus. Demnach werden fast 80 % dieser Bibliotheken von den Entwicklern, die sie in ihrer Software verwenden, nie aktualisiert. Als Resultat daraus enthielten fast alle diese Repositories Bibliotheken mit mindestens einer Sicherheitslücke, die sich in 92 % der Fälle mit einem einzigen Update beheben ließen.

    Solide Basis

    Der Report von Veracode (Download erst nach Anmeldung) scheint eine solide Basis zu haben, wie Günter Born in seinem Blog berichtet. Demnach wurden für den Report 13 Millionen Scans von mehr als 86.000 Repositories mit mehr als 301.000 Bibliotheken analysiert. Zudem wurden rund 2.000 Entwickler über ihre Verwendung von Software aus dritter Hand befragt.

    Angst vor Regressionen

    Dabei wird klar, dass es zwei Hauptgründe gibt, warum Entwickler keine Updates einspielen. Einerseits wird dies bei der Vielzahl der verwendeten Bibliotheken auch in proprietärer Software einfach vergessen, andererseits werden nach der Devise »never touch a running system« durch Updates eingeführte Regressionen befürchtet. Der Report stellt allerdings klar, dass 65 % solcher Updates nur minimale Änderungen mitbringen, die selbst bei komplexen Anwendungen kaum dazu in der Lage sind, Schaden anzurichten.

    Richtlinien notwendig

    Die beliebtesten Bibliotheken entstammen Tools und Frameworks wie .NET, Go, JavaScript, Ruby, PHP, Python Java und Swift, wobei die Beliebtheit von Jahr zu Jahr stark schwanken kann. Der Report geht auch darauf ein, ob Unternehmen Richtlinien haben, wenn es um die Auswahl von Bibliotheken geht und wie diese aussehen.

    Als Fazit kann man mitnehmen, dass die Sicherheit der Lieferkette bei Software einen steigenden Wert darstellt und die Einstellung vieler Entwickler von »Einbinden und Vergessen« nicht länger tragbar ist. Da sich Bibliotheken schnell ändern können, sei eine Bestandsaufnahme der verwendeten Bibliotheken im Unternehmen unabdingbar.

  • BIOS/UEFI bei 129 Dell-Rechnern angreifbar

    Dell BIOS
    Photo by Markus Winkler on Unsplash

    Wie das Sicherheitsunternehmen Eclypsium berichtet, sind 129 Modelle von PCs und Notebooks der Firma Dell von mehreren Sicherheitslücken betroffen, die Angriffe über die BIOS-Funktion BIOSConnect erlauben. Die Lücken erlauben die Ausführung beliebigen Codes auf der Ebene von BIOS/UEFI. Die vier Schwachstellen haben einen CVSS-Score von 8.3, der der Stufe high entspricht.

    Angriff auf BIOS/UEFI-Ebene

    Die Lücken ermöglichen es einem privilegierten Netzwerkangreifer, sich als Dell.com auszugeben und beliebige Codeausführung auf der BIOS/UEFI-Ebene des betroffenen Geräts zu ermöglichen. Ein solcher Angriff würde es Angreifern erlauben, den Boot-Prozess des Geräts zu kontrollieren und das Betriebssystem und die Sicherheitskontrollen auf höherer Ebene zu unterlaufen. Das Problem betrifft 129 Dell-Modelle von Laptops, Desktops und Tablets, einschließlich Geräten, die durch Secure Boot und Dell Secured-Core-PCs geschützt sind.

    Lücken in BIOSConnect

    BIOSConnect ist eine Funktion von SupportAssist, mit der Benutzer eine Betriebssystemwiederherstellung aus der Ferne durchführen oder die Firmware auf dem Gerät aktualisieren können. In beiden Fällen ermöglicht BIOSConnect dem BIOS des Systems, sich über das Internet mit den Backend-Services von Dell in Verbindung zu setzen und dann den Aktualisierungs- oder Wiederherstellungsprozess zu koordinieren.

    Die Sicherheitsforscher bei Eclypsium haben vier Lücken entdeckt, die als CVE-2021-21571, CVE-2021-21572, CVE-2021-21573 und CVE-2021-21574 katalogisiert wurden. Die letzten beiden Lücken konnten bereits Ende Mai serverseitig geschlossen werden, ohne dass Handlungsbedarf für die Anwender besteht. Bei CVE-2021-21571 handelt es sich um eine Sicherheitslücke bei der Zertifikatsvalidierung des Dell UEFI BIOS HTTPS-Stacks, der von der Dell BIOSConnect-Funktion und der Dell HTTPS-Boot-Funktion genutzt wird. CVE-2021-21572 beschreibt einen Pufferüberlauf bei BIOSConnect. Ein authentifizierter Angreifer mit lokalem Zugriff auf das System kann diese Schwachstellen ausnutzen, um beliebigen Code auszuführen und UEFI-Beschränkungen zu umgehen.

    Update zwingend notwendig

    Die beiden noch offenen Lücken können nur über BIOS/UEFI-Updates geschlossen werden, die Dell am 24. Juni bereitgestellt hat. Dabei soll auf keinen Fall die BIOSConnect-Funktion genutzt werden. Stattdessen ist es ratsam, die ausführbare BIOS-Datei des jeweiligen Betriebssystems zu benutzen, nachdem die Hashes manuell mit den von Dell veröffentlichten Hashes verglichen wurden. Linux-Anwender, deren Dell-Geräte von dem Firmware-Aktualisierungsdienst fwupd unterstützt werden, sollten diese für das Update nutzen, indem sie zeitnah den Befehl sudo fwupdmgr update ausführen.

  • Sicherheitslücken in App-Stores bei KDE und GNOME

    Forscher beim Berliner IT-Sicherheitsunternehmen Positive Security haben eine kritische Schwachstelle im Pling-Store entdeckt, der von App-Stores für freie und quelloffene Software genutzt wird. Die Lücke kann potenziell missbraucht werden, um Supply-Chain-Attacks über eine XSS-Lücke zu inszenieren und Remote Code Execution (RCE) auszuführen.

    Kein Kontakt

    Da die Entdecker der Lücke seit Februar nicht in der Lage waren, einen Verantwortlichen bei der Firma Hive01, die den Pling-Store betreibt, zu erreichen, gehen sie jetzt mit der bisher ungepatchten Lücke an die Öffentlichkeit. Betroffen sind unter anderem:

    • appimagehub.com
    • store.kde.org (Discover)
    • gnome-look.org
    • xfce-look.org
    • pling.com

    Installation mit einem Mausklick

    Pling-Store ermöglicht es Anbietern, Dinge wie Erweiterungen, Themes, Icons oder Mauszeiger mit einem Klick zu installieren, die in den Distributionen selbst vielleicht nicht verfügbar sind. Derzeit werden die Desktops KDE Plasma, Gnome, XFCE, Mate, Cinnamon, Budgie, LXQt, Elementary und Enlightenment unterstützt. Die entdeckte Schwachstelle liegt in der Methode, wie Entwickler im Pling-Store eine App anlegen und Metadaten etwa zur Beschreibung der App im Listenfeld HTML or Embed Media Code anlegen. Dieses Listenfeld lässt sich leicht missbrauchen, um eine XSS-Nutzlast unterzubringen.

    Zugriff auf aktive Angebote

    Die gespeicherte Nutzlast ließe sich verwenden, um bereits aktive Angebote zu ändern oder neue Angebote im Pling-Speicher im Kontext anderer Benutzer zu veröffentlichen, was zu einem wurmfähigen XSS führt. Neben den typischen XSS-Implikationen würde dies einen Supply-Chain-Attacke-XSS-Wurm mit einer JavaScript-Nutzlast ermöglichen, um trojanisierte Versionen von Software hochzuladen und die Metadaten der Auflistung eines Opfers so zu verändern, dass sie den Angriffscode enthalten und verbreiten.

    Über eine Electron-App, die Pling-Store allen Nutzern empfiehlt, gelang es den Forschern, über die XSS-Lücke eine App zu installieren und damit Code auszuführen. Wenn ein Anwender eine bösartige Website besucht, während der Pling-Store im Hintergrund aktiv ist, wird der XSS-Code innerhalb der Pling-App ausgelöst. Der JavaScript-Code in der Website kann nun nicht nur eine Verbindung zum lokalen WebSocket-Server herstellen, der verwendet wird, um Nachrichten von der App abzuhören, sondern er nutzt ihn auch, um Nachrichten zu senden, um beliebigen nativen Code auszuführen, indem er ein AppImage herunterlädt und ausführt.

    Auch wenn bei der zu Blue Systems gehörenden Firma Hive01 niemand auf den Versuch, die Lücke zu melden, reagiert hat, so haben die Entwickler von GNOME und KDE die unter CVE-2021-28117 katalogisierte Lücke mittlerweile geschlossen.

  • OpenSSL 3.0 mit neuer Lizenz

    OpenSSL 3.0

    OpenSSL, die freie Software-Bibliothek für Anwendungen, die die Kommunikation über Computernetzwerke unter anderem mittels SSL/TLS für die Mehrheit der HTTPS-Webseiten sichern, stellt die erste Beta-Version des neuen, ursprünglich für das 4. Quartal 2020 zur Veröffentlichung anstehenden Hauptzweigs 3.0 online. Das gab das OpenSSL Management Committee jetzt im Projektblog bekannt.

    Neu: Lizenz und Versionierung

    Drei Jahre haben die Entwickler an der neuen Hauptversion OpenSSL 3 gearbeitet und dabei mehr als 7.000 Commits von über 300 Entwicklern integriert. Mit der neuen Version wechselt das Projekt von der bisherigen Doppel-Lizenzierung aus SSLeay und seiner eigenen Lizenz hin zur Apache 2 Lizenz, um die Verwendung in anderen Open-Source-Projekten zu vereinfachen. Die Versionierung wird vereinfacht.

    Provider-basierte Architektur als Standard

    An die Stelle der bisherigen »Engine« API tritt eine Provider-basierte Architektur. Diese soll mehr Flexibilität bringen und es Drittautoren ermöglichen, neue Kryptoalgorithmen in OpenSSL hinzuzufügen. Dabei ist das Provider-Konzept eine der wichtigsten Änderungen, die bereits mit OpenSSL 1.1.1 eingeführt wurden. Provider sammeln Algorithmus-Implementierungen und stellen sie zur Verfügung. Mit OpenSSL 3.0 ist es nun möglich, entweder programmatisch oder über eine Konfigurationsdatei festzulegen, welche Provider der Anwender für eine bestimmte Anwendung verwenden möchte. OpenSSL 3.0 wird standardmäßig mit 5 verschiedenen Providern ausgeliefert. Im Laufe der Zeit werden möglicherweise weitere Provider von Drittanbietern zur Verfügung gestellt, die in OpenSSL eingebunden werden können.

    FIPS-Modul in Arbeit

    Einer der verfügbaren Standardanbieter ist FIPS. Dieser stellt FIPS-validierte kryptografische Algorithmen zur Verfügung. OpenSSL wurde 2006 erstmals die FIPS 140-2-Zertifizierung erteilt. Ein entsprechendes Modul ist für OpenSSL 3 in Arbeit, wird wegen des langen Review-Prozesses von mindestens sechs Monaten aber erst im nächsten Jahr erwartet. Zur Verwaltung von digitalen Zertifikaten in einer Public-Key-Infrastruktur (PKI) wurde das Certificate Management Protocol (CMP) vollständig implementiert.

    OpenSSL 3.0 ist ein Major-Release, was bedeutet, dass die ABI der Bibliothek geändert wurde, was eine Neukompilierung aller abhängigen Anwendungen erfordert. Ein Migrations-Leitfaden soll Entwicklern helfen, falls nötig ihre Anwendungen anzupassen. Der Quellcode steht auf der Projektseite bereit, das Projekt wird auf GitHub gepflegt.

  • Kritische Lücke in Polkit nach 7 Jahren geschlossen

    Photo by iMattSmart on Unsplash

    Polkit, das früher PoilcyKit hieß ist der mit Systemd verbandelte Berechtigungsdienst, der es unprivilegierten Prozessen ermöglicht mit ihren privilegierten Kollegen sprechen können. Wenn also eine Anwendung für eine Aufgabe Root-Rechte benötigt, fragt Polkit nach dem entsprechenden Passwort.

    CVE-2021-3560

    Wie auf GitHub aktuell zu lesen ist, wurde kürzlich eine Sicherheitslücke entdeckt, die seit sieben Jahren in Polkit vorhanden war und als CVE-2021-3560 (Common Vulnerabilities & Exposures) katalogisiert ist. Sie war mit 7.8 von 10 Punkten als kritisch eingestuft.

    Ausweitung der Rechte

    Bei der Lücke handelte es sich um eine mögliche Privilegien-Eskalation, die sehr einfach durchzuführen war. Sie war mit Commit bfa5036 in Version 0.113 eingeschleppt worden. Wie Kevin Backhouse, der Entdecker der Lücke schreibt, waren zur Ausnutzung lediglich einige Kommandozeilen-Werkzeuge und Befehle wie bash, kill und dbus-send notwendig. Die Schwachstelle wird durch das Starten eines dbus-send-Befehls ausgelöst, der jedoch sofort per kill beendet wird, während Polkit noch mitten in der Verarbeitung der Anfrage steckt.

    Polkit ging mit der Antwort auf die bereits beendete Anfrage falsch um. Anstatt den Vorgang abzubrechen, ging Polkit davon aus, dass die Anfrage von einem Prozess mit der UID 0 gekommen sei, also von einem Root-Prozess und genehmigte die Anfrage. Das gelang zwar nicht immer, aber oft genug, um den Aufwand gering zu halten.

    Bitte zeitnah aktualisieren

    Der Fehler betrifft Distributionen, die Polkit in Version 0.113 oder später verwenden. Welche Distributionen das sind, lässt sich mit Repology nachvollziehen. Debian hat mittlerweile mit Version 0.105-31 einen Patch für Unstable und Testing bereitgestellt, den Ubuntu für 21.04 übernommen hat. Unter anderem auch Arch Linux, Red Hat und SUSE haben ihre Pakete gepatched.

  • Schwere Lücke in VMware vCenter Server

    VMware Logo | Quelle: Wikipedia

    Zwei schwere Sicherheitslücken im VMwares Servermanagement-Software vCenter gefährden Anwender mit einer Schwere von bis zu 9,8 von 10 möglichen Punkten. Die als CVE-2021-21985 und CVE-2021-21986 katalogisierten Lücken erlauben die Ausführung von Code aus der Ferne und werden bereits aktiv ausgenutzt. Bereits am 25. Mai hat VMware die Lücken gepatcht.

    9,8 von 10 Punkten

    Die schwerere der beiden Lücken mit der Katalognummer CVE-2021-21985 findet sich in der Komponente vSphere-Client, wo aufgrund einer fehlenden Eingabevalidierung im Virtual SAN Health Check-Plug-in ein böswilliger Akteur mit Netzwerkzugriff auf Port 443 Befehle mit uneingeschränkten Rechten auf dem zugrunde liegenden Betriebssystem, wo vCenter gehostet ist, ausführen kann. Betroffen sind alle vCenter Server-Versionen ab 6.5.0 bis inklusive 7.x.

    Bei der Lücke, die als CVE-2021-21986 katalogisiert ist, gibt VMware einen Schweregrad von 6.5 an. Sie findet sich ebenfalls im vSphere-Client im Authentifizierungsmechanismus für die Plug-ins Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager und VMware Cloud Director Availability. Mit Netzwerkzugriff auf Port 443 können von den betroffenen Plug-ins erlaubte Aktionen ohne Authentifizierung durchgeführt werden.

    Beide Lücken und deren Behebung sind im Blog von VMware ausführlich beschrieben. Anwender, die den vCenter-Server nutzen, sollten dringend ihre Installation aktualisieren.