CleanPress

Kategorie: Security

  • GnuPG 2.3.0 mit neuem Standard-Algorithmus veröffentlicht

    GnuPG-Logo | Lizenz: GPL

    Die neue Version 2.3.0 von GNU Privacy Guard (GnuPG), einem Standard für E-Mail-Verschlüsselung und das Signieren von Paketen hat ein paar Verbesserungen gegenüber früheren Versionen erhalten. Darunter ist ein neuer noch experimenteller Schlüsseldatenbank-Daemon für schnellere Schlüsselsuche. Um den Daemon zu aktivieren, muss derzeit die Phrase use-keyboxd in die Dateien gpg.conf und gpgsm.conf eingetragen werden. Die Schlüssel werden dann in einer SQLite-Datenbank abgelegt, die die Suche nach Schlüsseln deutlich beschleunigen soll.

    EdDSA als neuer Standard

    Die Standardalgorithmen für die Erstellung neuer öffentlicher Schlüssel wurden auf ed25519/cv25519 geändert. Am hinteren Ende der Empfehlungen steht nun AES und löst damit 3DES als Schlusslicht ab. Neu hinzugekommen ist die Unterstützung für die Verschlüsselung per Authenticated Encryption with Associated Data (AEAD) unter Verwendung von OCB oder EAX. Neu unterstützt werden zudem Curve448 und der Export von SSH-Schlüsseln im nach dem Algorithmus Ed448.

    Mehr Smartcards unterstützt

    Für unterstützte Smartcards wurde das neue Frontend gpg-card integriert. Mit tpm2d steht ein neuer Daemon für die Bindung von Schlüsseln an die lokale Machine bereit. Zudem wurde die Unterstützung von Smartcards und deren Lesegeräte generell weiter ausgebaut. So werden nun auch Telesec Signature Cards v2.0, Rohde&Schwarz Cybersecurity Cards und PIV Cards unterstützt. Unter Windows steht auf der Kommandozeile volle Unterstützung für Unicode bereit.

    GnuPG 2.3 steht auf diversen Spiegelservern zum Download bereit. Der Quellcode kann über den FTP-Server des Projekts bezogen werden. Alle Änderungen der neuen Version sind in der Ankündigung nachzulesen. Die Entwickler empfehlen die neue Version auch für den produktiven Einsatz, wenn die neuen Funktionen benötigt werden und dabei kleinere Regressionen akzeptabel sind. GnuPG 2.2 wird weiterhin unterstützt.

  • Debian 11: Repositories aus 3. Hand ohne apt-key einbinden

    Debian 11: Repositories aus 3. Hand ohne apt-key einbinden

    Wer in letzter Zeit versucht hat, bei Debian, Ubuntu oder deren Repositories aus 3. Hand in die Quellenliste einzutragen und dabei den herkömmlichen Weg zu gehen, wurde mit einer Warnung konfrontiert. Das liegt daran, dass viele Anleitungen im Netz noch immer die Verwendung von apt-key für das Einbinden der Schlüssel verwenden, obwohl apt-key schon lange als überholt gilt. Bereits 2010 wurde es als veraltet und unsicher markiert und wird mit Debian 11 und Ubuntu 22.04 letztmalig ausgeliefert.

    Unsichere Methoden

    Es gibt verschiedene Möglichkeiten, ein APT-Repository aus dritter Hand einzubinden. Die entsprechenden Schlüssel wurden früher unter /etc/apt/trusted.gpg und in letzter Zeit manuell in Unterverzeichnissen von /etc/apt/trusted.gpg.d abgelegt. Obwohl letzteres oft empfohlen wird, sieht das Debian-Wiki beide Möglichkeiten als unsicher an.

    Der Grund dafür ist, dass beim Hinzufügen eines OpenPGP-Schlüssels zum Signieren eines APT-Repositorys zu einem der beiden Verzeichnisse dem Schlüssel von APT bedingungslos auch bei allen anderen auf dem System konfigurierten Repositorys vertraut wird, die über keine signed-by-Option verfügen. Infolgedessen kann jedes inoffizielle APT-Repository, dessen Signierschlüssel zu /etc/apt/trusted.gpg oder /etc/apt/trusted.gpg.d hinzugefügt wurde, jedes Paket auf dem System ungefragt aktualisieren oder ersetzen.

    Bisheriges Vorgehen

    Eine typische Zeile zum Einbinden des Schlüssels bei Debian-basierten Distributionen sieht oft etwa so aus wie hier am Beispiel des Signal-Messengers:

    wget -O- https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -

    Das ergibt eine Warnung:

    Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

    Debian 12 verlangt ein anderes Vorgehen

    Apt-key kann derzeit noch benutzt werden, aber mit dem in wenigen Monaten erwarteten Debian 11 fällt diese Möglichkeit weg. Deswegen ergibt es Sinn, sich bereits jetzt mit der von Debian-Wiki erwähnten Methode signed-by vertraut zu machen. Laut dem Debian-Wiki sollte der Schlüssel über HTTPS an einen Ort heruntergeladen werden, der nur von Root beschreibbar ist, wie etwa /usr/share/keyrings. Der Schlüssel sollte einen kurzen Namen erhalten, der das Repository beschreibt, gefolgt von archive-keyring als Erweiterung. Wenn das Repository z. B. mein_repository heißt, sollte die Schlüsseldatei mein_repository-archive-keyring.gpg heißen.

    Die OpenPGP-Keys von Repositories aus dritter Hand sind in der Regel mit der Methode ASCII-Armor versehen. Diese Verpackung gilt es, bereits während des Downloads zu entfernen.

    Im Fall des oben als Beispiel verwendeten Schlüssels für das Repository des Signal-Messengers sieht das dann so aus:

    Schlüssel unter Root-Kontrolle

    wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor | sudo tee /usr/share/keyrings/signal-archive-keyring.gpg

    Nachdem der Schlüssel am richtigen Ort liegt, gilt es, den Eintrag für die Quellenliste zu formulieren. Um im Beispiel bei Signal zu bleiben, legen wir zunächst einen Listeneintrag in /etc/apt/sources.list/d an:

    sudo nano /etc/apt/sources.list.d/signal.list

    Der Inhalt der Datei lautet:

    deb [signed-by=/usr/share/keyrings/signal-archive-keyring.gpg] https://updates.signal.org/debian/ stable main

    Dabei sind natürlich die Distribution und der Zweig anzupassen. Für Ubuntu würde es so aussehen:

    deb [signed-by=/usr/share/keyrings/signal-archive-keyring.gpg] https://updates.signal.org/desktop/apt groovy main

    Damit wird das Einbinden von Repositories aus dritter Hand mit Debian 11, Ubuntu 22.04 und deren Derivaten nicht unbedingt einfacher, aber sicherer. Wenn man sich die Zeile, die den Schlüssel per wget holt und die Definition für die Quellenliste wegspeichert, muss man im Bedarfsfall nur noch die Befehle anpassen.

  • PHP-Repository kompromittiert

    PHP
    Logo: Colin Viebrock | Quelle: PHP | Lizenz: CC BY-SA 4.0

    Vor zwei Tagen meldeten PHP-Entwickler die Entdeckung von zwei böswilligen Commits im zentralen PHP-Repository, wo der Quellcode der Skriptsprache zur Erstellung dynamischer Webseiten liegt. Die Commits wurden im Namen des PHP-Erfinders Rasmus Lerdorf und des Entwicklers Nikita Popov getätigt.

    Kein eigener Server mehr

    Als Konsequenz aus dem Einbruch geben die Entwickler den Server git.php.net auf und nutzen künftig die bisher lediglich als Spiegel dienenden Repositories auf GitHub als Hauptinstanz. Der Schreibzugriff auf PHP-Repositories erfordert künftig eine Mitgliedschaft in der PHP-Organisation sowie die Aktivierung der Zwei-Faktor-Authentifizierung für GitHub.

    Hintertür zweimal entfernt

    Der erste Commit, der als »Fix Typo« überschrieben war und im Namen von Lerdorf erfolgte, etablierte eine Hintertür. Nachdem Popov den Commit rückgängig gemacht hatte, tauchte der gleiche Commit sieben Stunden später in seinem eigenen Namen erneut auf, um nach einer Stunde entdeckt und wieder entfernt zu werden.

    Kryptographische Signierung gefordert

    Das PHP-Team zieht nun die Konsequenz aus der Tatsache, dass das Team, dass sich um die Infrastruktur kümmert, meist nur aus zwei Leuten besteht, die der Aufgabe nicht die nötige Sorgfalt zukommen lassen können. Der Angriff hat auch erneut den Aufruf aus der Community zur Folge, die kryptographische Signierung von Code Commits, die den Quellcode von PHP betreffen, verbindlich zu machen.

    Gefahr der Verbreitung gering

    PHP wird von rund 80 Prozent aller Websites verwendet, deren serverseitige Programmiersprache bekannt ist, wie aus einer Statistik von W3techs hervorgeht. Während die Entwickler den kompromittierten Server nach weiteren böswilligen Commits untersuchen, ist die Gefahr, dass sich der Schadcode aus diesem Angriff weiter verbreitet, gering, da PHP hauptsächlich über die Distributionen installiert und aktualisiert wird.

  • Schwerwiegender Fehler in OpenSSL behoben

    OpenSSL

    OpenSSL ist ein wichtiger Dreh- und Angelpunkt, wenn es um die Implementierung von Transport Layer Security für Website- und E-Mail-Verschlüsselung geht. So war dann auch die IT-Welt 2014 geschockt darüber, wie es sein konnte, dass bei einer so wichtigen Softwarekomponente eine Lücke wie Heartbleed auftreten konnte.

    Heartbleed führte zur Core Infrastructure Initiative

    Ein paar Zeilen böswilligen Codes konnten einen hohen wirtschaftlichen Schaden erzeugen, unter anderem weil die Nutzer und Nutznießer von OpenSSL es an der Unterstützung für dieses wichtige Projekt hatten fehlen lassen. Zudem wurde OpenSSL über die Jahre immer wieder von kleineren Lücken heimgesucht, allerdings wurden auch vermehrt Audits zu ihrer Entdeckung eingesetzt, zuletzt Anfang 2019.

    Kritische Lücke geschlossen

    Jetzt haben die Entwickler eine weitere, am 17. März entdeckte, hochgradig gefährliche Sicherheitslücke gepatcht, die es Hackern leicht machte, eine große Anzahl von Servern komplett lahmzulegen. Die als CVE-2021-3449 katalogisierte Lücke konnte Server zum Absturz bringen, indem der Hacker einem Server während des anfänglichen Handshakes, der eine sichere Verbindung zwischen einem Endbenutzer und einem Server herstellt, eine bösartig formulierte Neuverhandlungsanforderung übersandte.

    Nur in Nischenkonfigurationen

    Die Entwickler haben zeitgleich eine weitere Schwachstelle behoben, die in Grenzfällen verhindert hat, dass Anwendungen TLS-Zertifikate erkennen und ablehnen, die nicht von einer vom Browser als vertrauenswürdig erkannten Zertifizierungsstelle signiert waren. Diese zweite Schwachstelle ist als CVE-2021-3450 katalogisiert und konnte in nicht standardgemäßen Nischenkonfigurationen eine vollständige Umgehung der Zertifikatsüberprüfung bewirken. Diese Lücke betrifft zudem lediglich den X509_V_FLAG_X509_STRICT Modus.

    Bitte zeitnah aktualisieren

    Alle Versionen ab OpenSSL 1.1.1h sind durch die Lücken verletzlich und sollten umgehend auf OpenSSL 1.1.1k aktualisiert werden. OpenSSL 1.0.2 ist nicht betroffen. Bisher bieten Alpine Linux, Debian und Devuan Unstable, Gentoo, Funtoo, Exherbo, GNU Guix, Solus und Void Linux die gepatchte Version an. Weitere Distributionen werden zeitnah folgen.

  • Fingerprinting im Browser auch ohne JavaScript

    Fingerprinting im Browser auch ohne JavaScript

    Eine neue Seitenkanalattacke soll es Angreifern erlauben, Tracking per Fingerprinting im Browser auch dann zu erfolgreich zu betreiben, wenn die Verwendung von JavaScript untersagt ist. Das berichten Forscher der Cornell University, die dieses Angriffsszenario entwickelt haben. Der komplette Report ist als PDF verfügbar.

    Viele Prozessoren anfällig

    Anfällig für diese neue Tracking-Attacke sind die Hardware-Architekturen Intel Core, AMD Ryzen, Apple M1 sowie Samsung Exynos, die einen Großteil der heute verwendeten CPUs abdecken. Überraschenderweise kamen die Forscher zu dem Schluss, dass ihre Angriffe aufgrund der einfacheren Cache-Austauschrichtlinien auf den M1- und Exynos-Chips effektiver waren als auf den anderen Plattformen. Die Attacke ist ausschließlich auf HTML und CSS aufgebaut und ist somit nicht auf JavaScript angewiesen. Dabei sollen sogar Sicherheitsfunktionen wie VPN und das Tor-Netzwerk keinen absoluten Schutz bieten.

    Kein JavaScript nötig

    Die Forscher hatten zunächst versucht, die JavaScript-Funktionen zu identifizieren, die für die Durchführung eines solchen Cache-basierten Angriffs wesentlich sind. Dann entwickelten sie eine Reihe von Angriffen mit progressiv abnehmender Abhängigkeit von JavaScript-Funktionen, bis sie schließlich bei reinem HTML/CSS anlangten. Damit werden auch Maßnahmen der Browser-Hersteller wie die Verhinderung der exakten Zeitmessung, die bei JavaScript-basierten Seitenkanalattacken unerlässlich ist, obsolet.

    Hauptsächlich mit Chrome getestet

    Als Einschränkung erwähnen die Forscher, dass sie ihre Angriffe auf allen Plattformen hauptsächlich mit Googles Chrome Browser durchgeführt haben und die Verwendung anderer Browser vermutlich abweichende Ergebnisse zeigen würde. Die Prozessorhersteller sind von den Forschern über den neuen Angriffsvektor informiert worden. Die reale Gefahr dieser Entdeckung ist relativ gering, da solche Cache-Timing-Attacken in etwa den gleichen Schwierigkeitsgrad aufweisen wie die ebenfalls timing-sensitiven Spectre-Attacken auf Intel-CPUs. Für den Bereich des Home-Computings sind hier keine Angriffe zu erwarten.

  • Zwei Sicherheitslücken in Sudo entdeckt

    Sudo wird von fast allen Linux-Distributionen verwendet, um Prozesse mit den Rechten eines anderen Benutzers, meist dem Superuser root, auszuführen. Bereits häufiger war Sudo von Sicherheitslücken betroffen. Jetzt wurden zwei Schwachstellen entdeckt, von denen eine bereits 2011 eingeschleppt wurde. Die beiden Lücken wurden als CVE-2021-3156 und CVE-2021-23239 katalogisiert. Die Erste der beiden Lücken hat einen CVSS-Score von 7.0 was der allgemeinen Einordnung als high entspricht, die Zweite hat einen Score von 2,5, was als low einzuordnen ist

    Pufferüberlauf

    Bei der von Sicherheitsforschern von Qualsys entdeckten Schwachstelle CVE-2021-3156 handelt es sich um einen Heap-Based Buffer Overflow, also einen Überlauf in der dynamischen Speicherverwaltung. Es wurde entdeckt, dass Sudo beim Parsen von Befehlszeilen den Speicher nicht korrekt behandelt. Ein lokaler Angreifer, egal ob mit Sudo-Rechten ausgestattet oder nicht, könnte dieses Problem ohne Authentifizierung ausnutzen, um unbeabsichtigten Zugriff auf das Administratorkonto erhalten. Betroffen sind die älteren Versionen von 1.82 – 1.8.31p2 und aktuelle Versionen von 1.9.0 – 1.9.5p1. Somit sind alle aktuellen Ausgaben von Distributionen betroffen, die Sudo einsetzen. Darunter sind Ubuntu 20.04 LTS und 20.10, Fedora 33 und Debian 10 sowie RHEL und SUSE Enterprise.

    Sudoedit

    Bei der zweiten Schwachstelle CVE-2021-23239 kann ein lokaler Angreifer in der Komponente sudoedit
    eine Race Condition auslösen, die bei der Überprüfung von Verzeichnisberechtigungen dazu führt, dass Dateirechte umgangen werden. Ein lokaler Angreifer könnte dieses Problem ausnutzen, Dateirechte zu umgehen, um festzustellen, ob ein Verzeichnis existiert oder nicht.

    Zeitnah aktualisieren!

    Zum jetzigen Zeitpunkt haben Arch, Ubuntu, Debian, FreeBSD, Fedora und Red Hat und andere die Lücken bereits geschlossen. Nutzer sind dringend aufgefordert, ihre Systeme sobald als möglich zu aktualisieren und eine angebotene Sudo-Version höher als 1.9.5p1 einzuspielen. Eine Alternative zu Sudo kann doas sein.

  • Tails will 2021 auf Wayland umstellen

    Tails 2021
    Logo: Wikimedia Lizenz: CC by 4.0

    Die anonymisierende Distribution Tails hat ihre Roadmap für 2021 vorgelegt. Tails steht für »The Amnesic Incognito Live System« und bedient sich zur Anonymisierung des Tor-Netzwerks, durch dessen Knotenrechner der Netzwerkverkehr geleitet wird. Es ist als Live-System für die Verwendung auf USB-Sticks oder DVDs ausgelegt und spezialisiert sich auf Anonymität und die Wahrung der Privatsphäre seiner Anwender. Als Basis für Tails dient derzeit Debian 10.7 »Buster«.

    Migration zu Wayland

    Als wichtigste geplante Neuerung ist die Migration vom X.org-Server hin zu Wayland zu sehen. Die Entwickler sehen darin eine Verbesserung der Sicherheit aller Applikationen in Tails. So soll beispielsweise der derzeit deaktivierte Unsafe Browser in Tails unter Wayland nicht mehr dazu genutzt werden können, die Anonymität eines Anwenders aufzudecken.

    An anderer Stelle sollen kommende Tails-Versionen es den Nutzern leichter machen, die Zensur durch Staat und Provider in ihren Ländern zu umgehen, indem der Start von Tor und die Konfiguration von Tor-Bridges komplett überarbeitet und zusätzlich persistente Tor-Bridges eingeführt werden.

    Persistenz überarbeiten

    Aufgrund der Ergebnisse einer Umfrage unter den Anwendern vor einem halben Jahr soll die Oberfläche der Einstellungen für die persistente Speicherung verbessert werden. Zudem soll das Script, dass der Persistenz-Funktion zugrunde liegt, von Perl auf Python GTK+ umgestellt werden. Damit soll die künftige Wartbar- und Erweiterbarkeit der Funktion gewährleistet werden.

    Tails 5.0 setzt auf Debian GNU/Linux 11

    Als weiterer Programmpunkt steht gegen Ende des Jahres Tails 5.0 auf dem Zettel der Entwickler. Dieser neue Strang wird auf dem im Jahresverlauf erwarteten Debian GNU/Linux 11 »Bullseye« aufsetzen, dessen Freeze am 12. Januar einsetzt.

    Im gleichen Atemzug rufen die Entwickler dazu auf, das Projekt mit Spenden zu unterstützen, auf die die Weiterentwicklung dringend angewiesen ist. Die Veröffentlichung der nächsten Version Tails 4.15 ist für den 26. Januar vorgesehen.

  • ProtonVPN Linux-App als offizielle Beta erschienen

    Über VPN-Anbieter kann man geteilter Meinung sein. aber wenn die Entscheidung dahin geht, dann sollte man sich ausgiebig umschauen, denn nicht immer werden die Versprechen bezüglich der Anonymität erfüllt, beispielsweise wenn es um Logs geht, die Rückschlüsse auf die wahre IP des Anwenders erlauben.

    Offizieller Linux-Client

    Ein Kandidat, der hier in die nähere Auswahl kommen könnte ist ProtonVPN von den Machern des in der Schweiz angesiedelten Dienstleisters ProtonMail. Das Projekt hat gerade die offizielle Beta-Version einer Linux-App freigegeben. Diese löst die vor zwei Jahren von der Community erstellte und seither gepflegte Version ab. Die vom ProtonVPN-Team erstellte CLI-App soll vor allem die Sicherheit des Dienstes erhöhen.

    Die neue App braucht keine Root-Rechte und erhielt einen Kill-Switch, der den Netzzugang kappt, wenn der Dienst die Verbindung verliert. Die App verhindert zudem DNS-Leaks und IPv6-Leaks und stellt die VPN-Verbindung automatisch wieder her, wenn das Netzwerk gewechselt wurde.

    Derzeit nur für Debian und Derivate

    Die App steht derzeit nur für Debian und dessen Derivate bereit, andere Distributionen sollen in den nächsten Wochen folgen. Das Repository kann zur Aktualisierung der Software in die Quellen integriert werden. Die App ist vollständig in den NetworkManager und damit in die GNOME- und KDE-Plasma-Desktop-Umgebungen integriert und verwendet standardmäßig OpenVPN mit UDP, kann aber auf TCP umgestellt werden.

    Derzeit unterstützt die Beta-Version kein Split-Tunneling und funktioniert nicht mit Headless-Systemen. Für Anwender, die diese Merkmale benötigen, bleibt die Community-Version verfügbar, bis die offizielle App diese Funktionen unterstützt.

    Preismodelle beginnen bei 0 Euro

    Installation und Anwendung sind in der Ankündigung beschrieben. Anwender, die mit einer einzigen Verbindung mit reduzierter Bandbreite und Servern in lediglich drei Ländern zufrieden sind, können ProtonVPN kostenfrei nutzen. Darüber hinaus gibt es kostenpflichtige Angebote für 2, 5 und 10 gleichzeitige Verbindungen in 50 Ländern mit Geschwindigkeiten bis zu 10Gbit/s und Preisen von 48 bis hin zu 288 Euro jährlich.

    Alle Angebote versprechen eine strikte No-Log-Richtlinie und auch das kostenfreie Angebot verzichtet auf Werbung. Die Nutzung eines VPN-Anbieters setzt Vertrauen voraus. Deshalb klärt Proton auf auf, was ProtonVPN kann und was nicht.

  • Ubuntu patcht Lücken zu Rechteausweitung

    Bild: Security | GotCredit on Flickr | Lizenz: CC BY 2.0

    Der bei GitHub angestellte Sicherheitsforscher Kevin Backhouse hat zwei Lücken in Ubuntu 20.04 LTS entdeckt, deren Kombination es einem lokalen Angreifer mit einfachen Mitteln erlaubte, einen Root-Account zu erlangen. Die Lücken sind mittlerweile gepatched.

    Ohne eine Zeile Code

    Backhouse schrieb, es sei ungewöhnlich, dass eine Schwachstelle in einem modernen Betriebssystem so leicht ausgenutzt werden kann wie hier. Zur Ausnutzung der von ihm gefundenen Lücken muss keine einzige Zeile Code geschrieben werden. Die Lücke zur Ausweitung der Rechte ist zweigeteilt. Der erste Teil des Angriffs nutzt einen Fehler im Accountsservice aus, einem Daemon zur Verwaltung von Userkonten. Dieser Daemon stammt eigentlich aus dem freedesktop-Projekt, wurde aber von den Ubuntu-Entwicklern modifiziert, um eine Datei im Home-Verzeichnis des Benutzers zu lesen.

    Backhouse hat zunächst die Datei namens .pam_environment über einen symbolischen Link an die virtuelle Gerätedatei /dev/zero geschickt. Der anschließende Versuch, die Sprache des Desktops zu ändern lässt die entsprechende Dialogbox einfrieren. Im Terminal stellt er fest, dass Accountsservice nun einen CPU-Kern zu 100% auslastet. Nun löscht Backhouse den Symlink, um sich nicht selbst auszusperren.

    Der Daemon wird gecrashed

    Als Nächstes sendet er das Signal SIGSTOP zum Unterbrechen von Programmprozessen an den Accountsservice. Jetzt folgt der einzig kritische Punkt des Exploits: Bevor sich Backhaus von seinem Konto abmeldet, setzt er zunächst per nohup einen Timer, der ihm das Ausloggen ermöglicht bevor er den Konten-Dämons crasht. Ohne diesen Schritt würde er einfach ausgesperrt und der Exploit wäre fehlgeschlagen.

    GDM3 erlaubt Root-Account

    Nun stellt beim Login per GDM3 dieser fest, dass kein User-Konto besteht und schaltet das Setup ein, als wäre die eine Neuinstallation. Nun kann ein Root-Account angelegt werden und das System gehört dem Angreifer. Beide Lücken, die Ubuntu-Ausgaben von 16.04 LTS bis zu 20.10 betrafen, sind mittlerweile geschlossen.

    Video zum Exploit

  • GnuPG 2.2.23 schließt kritische Lücke

    Logo von GnuPG | Quelle: GnuPG | Lizenz: Public Domain

    Werner Koch, Entwickler von GNU Privacy Guard (GnuPG), gibt die sofortige Verfügbarkeit von GnuPG 2.2.23 bekannt. Die neue Version schließt eine kritische Sicherheitslücke in den Vorgängerversionen 2.2.21 und 2.2.22. Darüber hinaus ist auch Gpg4win 3.1.12 betroffen.

    Lücke beim Import

    Das Importieren eines OpenPGP-Schlüssels mit einer Präferenzliste für AEAD-Algorithmen kann zu einem Array-Überlauf und damit oft zu einem Absturz oder anderem undefiniertes Verhalten führen. AEAD steht für Authenticated Encryption with Associated Data und stellt laut Wikipedia neben dem Schutz einer vertraulichen Nachricht die Authentizität und Integrität weiterer Daten sicher, die nicht verschlüsselt werden.

    Nicht trivial auszunutzen

    Das Importieren eines willkürlichen Schlüssels kann laut Koch oft leicht von einem Angreifer ausgelöst werden und damit diesen Fehler auslösen. Das Ausnutzen des Fehlers abgesehen von Abstürzen ist nicht trivial, aber wahrscheinlich für einen engagierten Angreifer möglich.

    Software-Verteilung nicht betroffen

    Die Hürde für einen Angreifer ist, dass nur jedes zweite Byte kontrolliert und manipuliert werden kann, jedes erste Byte hat dagegen einen festen Wert von 0x04. Eine Überprüfung bei der Software-Verteilung sollte von diesem Fehler nicht betroffen sein, weil ein solches System eine kuratierte Liste von Schlüsseln verwendet.

    Zeitnah aktualisieren

    Anwender, die Version 2.2.21 or 2.2.22 von GnuPG verwenden, sollten zeitnah auf GnuPG 2.2.23 aktualisieren. Für Anwender älterer Versionen oder einer Beta-Version von GnuPG 2.3 besteht kein dringender Handlungsbedarf. Bei Verwendung von Gpg4win 3.1.12 oder GnuPG VS-Desktop 3.1.12 sollte entweder auf einen zeitnah erscheinenden Fix gewartet werden oder GnuPG Version 2.2.23 darüber installiert werden. Anwender, die keine neue Version installieren können, sind mit der Anwendung eines Patches ebenfalls auf der sicheren Seite.

    Neben dieser Sicherheitslücke wurde in GnuPG 2.2.23 unter anderem eine mögliche Schutzverletzung (segfault) und ein Fehler beim Parsing beseitigt. Zudem wurden Übersetzungen für Ungarisch, Polnisch, Tschechisch und Ukrainisch überarbeitet.