KernelCare+ Patches für CVE-2020-1971 sind da
Große Neuigkeiten vom OpenSSL-Team - sie haben den Fix für eine neue CVE-2020-1971 der über x509v3-Zertifikatsfelder Störungen der Server verursacht. Die gute Nachricht ist, dass es nicht zu Datendiebstahl führen kann, aber es hat die Fähigkeit, Ihre Server herunterzufahren und die Betriebsabläufe des Unternehmens zu lähmen. Die Versionen OpenSSL 1.1.1 und 1.0.2 sind von diesem Problem betroffen. Andere OpenSSL-Versionen sind ohne Unterstützungsind nicht überprüft worden und werden mit hoher Wahrscheinlichkeit vom Verkäufer nicht beachtet.
Im Moment arbeitet das KernelCare-Team daran, die Patches des Herstellers 1.1.1 auf v.1.1.0 zu portieren und sie mit der Live-Patching-Technologie zu ergänzen. Die rebootless Patches für unterstützte und nicht unterstützte Versionen von OpenSSL werden in 24 Stunden für CentOS6 und 7 bereitgestellt, die Patches für die übrigen unterstützten Distributionen werden im Laufe dieser Woche veröffentlicht.
UPDATE vom 9. Dezember:
Patches für CentOS 6 und CentOS 7 wurden veröffentlicht. Die KernelCare-Kunden werden die Updates in den nächsten 4 Stunden erhalten.
Um zusätzliche Risiken zu minimieren, werden wir morgen eine neue Version des KernelCare-Agenten veröffentlichen.
Inhalte:
- Was ist passiert?
- Wie kann man CVE-2020-1971 ohne einen Systemneustart oder -neustart entschärfen?
- Über CVE-2020-1971
Was ist passiert?
Für Benutzer von CentOS6 und anderen EOL-Distributionen, die OpenSSL-Versionen älter als 1.1.1 und 1.0.2 einsetzen, ist das Schlimmste eingetreten: Basierend auf den offenen Quellen werden frühere OpenSSL-Versionen nicht mehr unterstützt, und es ist davon auszugehen, dass der Hersteller die Korrekturen für CVE-2020-1971 für die älteren Bibliotheksversionen nicht veröffentlichen wird, so dass Unternehmensserver anfällig dafür sind, von böswilligen Akteuren abgeschaltet zu werden. Zum jetzigen Zeitpunkt ist KernelCare+ einer der wenigen Dienste, die die Patches für CVE-2020-1971 innerhalb von 24 Stunden veröffentlichen und alte und neue OpenSSL-Versionen ohne Dienstneustart oder Serverneustart aktualisieren können.
Diejenigen, die bei den auslaufenden Betriebssystemen oder gemeinsam genutzten Bibliotheken bleiben, hatten mehrere konstruktive Gründe dafür. Machen wir uns nichts vor: Die Migration auf eine neue Shared Library oder ein neues Betriebssystem ist eine mühsame und kostspielige Angelegenheit. Und selbst wenn Systemadministratoren mit der Aktualisierung von Tausenden von Servern einverstanden sind, schätzt die Unternehmensleitung den Umfang der erforderlichen finanziellen und zeitlichen Ressourcen angemessen ein und bleibt daher zögerlich.
Welche Möglichkeiten haben Sie nun? Die offensichtlichste - wenn Sie v1.1.x von OpenSSL verwenden - krempeln Sie die Ärmel hoch und patchen Sie CVE-2020-1971 manuell. Wenn Sie v1.0 verwenden, aktualisieren Sie auf die neuere Version von OpenSSL, um den Fix zu erhalten. Wie auch immer Sie sich entscheiden - beide erfordern einen Neustart der Dienste oder einen Neustart des gesamten Systems, damit die Aktualisierung der gemeinsam genutzten Bibliothek wirksam wird. Egal, wofür Sie sich entscheiden - die Folgen sind die gleichen: Ausfallzeiten und zusätzliche Arbeitsbelastung.
Wie kann man CVE-2020-1971 ohne einen Systemneustart oder -neubeginn entschärfen?
Es gibt noch eine dritte Möglichkeit, OpenSSL zu aktualisieren, ohne auf die neuere Version zu migrieren oder manuell zu patchen. Diejenige, die Ihre Arbeitsbelastung durch die Notfall-Updates nicht extrem erhöht. Lassen Sie KernelCare+ OpenSSL automatisch für Sie patchen.
Das KernelCare+-Team ist jetzt dabei, die 1.1.1-Patches des Herstellers auf v.1.1.0 zu portieren und mit der Live-Patching-Technologie zu erweitern. KernelCare+ ist ein Live-Patching für Shared Libraries, das Sicherheitsupdates anwendet, ohne den Betriebszustand Ihrer Anwendungen zu beeinträchtigen - keine Neustarts, keine Reboots. Neben dem Live-Patching von Glibc und OpenSSL schützt KernelCare+ auch Linux-Kernel.
Die KernelCare-Patches werden am 9. Dezember 2020 veröffentlicht. Zuerst - für die am meisten betroffenen Distributionen - CentOS 6 und CentOS 7. Die Patches für die übrigen Distributionen werden in den kommenden Tagen verfügbar sein.
Erhalten Sie eine KOSTENLOSE 7-Tage-Testversion von KernelCare
Ihre vierte Option ist der Kauf eines Extended Livecycle Supports von CloudLinux, oder Sie entscheiden sich für ein leistungsstarkes Duo: CloudLinux's CentOS 6 ELS und KernelCare+-Paket. Der Installationsprozess ist einfach: Führen Sie einen Befehl aus, um eine neue Repository-Datei hinzuzufügen. Danach versorgt Sie CloudLinux mit Updates für OpenSSL, Glibc, cPanel, Apache, PHP, MySQL, OpenSSH, Zlib usw. Die Aufgabe von KernelCare+ besteht darin, Ihnen diese Aktualisierungen ohne Neustart und Unterbrechung Ihrer Prozesse und Abläufe zur Verfügung zu stellen.
Über CVE-2020-1971
OpenSSL hat kürzlich (8. Dezember 2020) einen Patch für eine hochriskante Null-Pointer-Dereferenz-Schwachstelle in der GENERAL_NAME_cmp()-Funktion der Verschlüsselungsbibliothek veröffentlicht. Wenn diese Schwachstelle nicht gepatcht wird, kann ein Angreifer böswillig gestaltete Parameter an die Funktion GENERAL_NAME_cmp() senden und das System zum Absturz bringen, was zu einem Denial-of-Service (DoS) führt. Die Sicherheitslücke wurde CVE-2020-1971 zugeordnet.
Der Zweck der Funktion GENERAL_NAME_cmp() ist ein doppelter:
- Es vergleicht die Namen der Verteilungspunkte der Sperrlisten (CRL) zwischen der verfügbaren CRL, die mit der Option "-crl_download" heruntergeladen wurde, und dem im X.509-Zertifikat enthaltenen CRL-Verteilungspunkt.
- Er überprüft, ob der Unterzeichner des Zeitstempel-Antwort-Tokens mit dem Namen der Zeitstempel-Autorität übereinstimmt.
Wenn ein Angreifer die Kontrolle über beide zu vergleichenden Parameter hat, kann er das System mit böswillig erstellten CRLs oder bösartigen X.509-Zertifikaten zum Absturz bringen.
OpenSSL verwendet einen generischen Typ namens GeneralName, der für die Vergleiche verwendet wird. Einer der Typen heißt EDIPartyName. Wenn beide Parameter den Typ EDIPartyName enthalten, behandelt der OpenSSL-Code sie als "andere" und es kommt zu einem Segmentierungsfehler.
Alle Server, die OpenSSL-Versionen 1.1.1-1.1.1h und 1.0.2-1.0.2w verwenden, sollten auf die neueste Version 1.1.1i oder 1.0.2x aktualisiert werden. Entwickler, die OpenSSL als Abhängigkeit verwenden, sollten auch die Verschlüsselungsbibliothek patchen, insbesondere wenn sie s_server, s_client und verify-Tools für Zertifikate implementieren. Diese Tools verwenden GENERAL_NAME_cmp() in ihrer Funktionalität, und der Google-Sicherheitsforscher David Benjamin, der die Schwachstelle gefunden hat, hat nachgewiesen und demonstriert, dass OpenSSL abstürzt, wenn fehlerhafte Eingaben an sie gesendet werden.