Gpg.fail

 (gpg.fail)
4 Punkte von GN⁺ 2025-12-28 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Website, die mehrere Sicherheitslücken im Zusammenhang mit GnuPG offenlegt und auf Detailseiten zu jeder einzelnen Schwachstelle verlinkt
  • Auf der Website sind verschiedene Problemfälle bei PGP-Signaturen, Verschlüsselung und Vertrauensprüfung aufgeführt
  • Zu den wichtigsten Punkten gehören Plaintext-Angriffe, Path Traversal, Fehler bei der Hash-Berechnung, Memory Corruption und gefälschte Signaturen
  • Der Betreiber erwähnt, dass die Website derzeit hastig neu geschrieben wird und Folien, PoCs und Patches bald veröffentlicht werden sollen
  • Ein Fall, der die Notwendigkeit einer ernsthaften Überprüfung der Signaturintegrität und Vertrauensmodelle von Open-Source-Sicherheitswerkzeugen aufzeigt

Überblick über die Website

  • gpg.fail ist eine Website, die Schwachstellen in GnuPG (einer OpenPGP-Implementierung) sammelt und veröffentlicht
    • Jeder Eintrag verweist über einen separaten Link auf eine Seite mit detaillierter technischer Analyse
    • Der Betreiber schreibt, er habe „den Quellcode der Website zu Hause gelassen und schreibe sie gerade neu; morgen könne man eine bessere Version erwarten“
  • Oben auf der Website kündigt der Hinweis “Slides, pocs and patches soon!” die baldige Veröffentlichung weiterer Materialien an

Liste der offengelegten wichtigsten Schwachstellen

  • Multiple Plaintext Attack on Detached PGP Signatures
    • Weist darauf hin, dass bei abgetrennten PGP-Signaturen ein mehrfacher Plaintext-Angriff möglich ist
  • GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
    • GnuPG akzeptiert Pfadtrenner und Path Traversal im Dateinamenfeld von Literal Data
  • Cleartext Signature Plaintext Truncated for Hash Calculation
    • Es tritt ein Problem auf, bei dem der Plaintext bei der Hash-Berechnung abgeschnitten wird
  • Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
    • Prüfungen auf Veränderbarkeit von Chiffraten werden fehlerhaft durchgesetzt, wodurch Plaintext-Recovery-Angriffe möglich werden
  • Memory Corruption in ASCII-Armor Parsing
    • Memory Corruption beim Parsen von ASCII-Armor möglich
  • Trusted comment injection (minisign)
    • Möglichkeit zur Injection von Trusted Comments in minisign
  • Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
    • Möglichkeit zur Fälschung von Cleartext-Signaturen in der Implementierung des NotDashEscaped-Headers
  • OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
    • Anfällig für Format Confusion im OpenPGP-Cleartext-Signature-Framework
  • GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
    • Ein Ausgabeproblem, bei dem nicht zwischen erfolgreicher Signaturprüfung und Nachrichteninhalt unterschieden wird
  • Cleartext Signature Forgery in GnuPG
    • Möglichkeit zur Fälschung von Cleartext-Signaturen durch fehlerhafte Verarbeitung von NULL-Bytes
  • Radix64 Line-Truncation Enabling Polyglot Attacks
    • Zeilenabschneidung in Radix64 ermöglicht Polyglot-Angriffe
  • GnuPG may downgrade digest algorithm to SHA1 during key signature checking
    • Beim Prüfen von Schlüsselsignaturen kann der Digest-Algorithmus auf SHA1 herabgestuft werden
  • GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
    • Beim Parsen von Trust Packets ist das Hinzufügen beliebiger Subkeys möglich
  • Trusted comment Injection (minisign)
    • Die Schwachstelle zur Injection von Trusted Comments in minisign wird erneut erwähnt

Weitere Pläne

  • Der Betreiber arbeitet derzeit an Patches und will Folien sowie PoCs (Proofs of Concept) bald veröffentlichen
  • Die Website wurde vorläufig neu geschrieben; eine verbesserte Version am nächsten Tag ist angekündigt

Bedeutung

  • Zeigt, dass es zahlreiche Schwachstellen im gesamten System von Signatur-, Verschlüsselungs- und Vertrauensprüfung in GnuPG gibt
  • Ein Beispiel, das die Notwendigkeit stärkerer Grundvertrauensprüfungen und intensiverer Code-Audits für Open-Source-Sicherheitswerkzeuge unterstreicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-28
Hacker-News-Kommentare
  • Nach der jüngsten Veröffentlichung von Schwachstellen in GnuPG ist das Vertrauen erschüttert. Im CCC-Vortrag wurden Zero-Days offengelegt, und einige davon sind als „wontfix“ markiert, was Enttäuschung ausgelöst hat
    • Es hieß auch, das „Vertrauen in Werner Koch ist verloren gegangen“, woraufhin andere nach den Gründen fragten
    • Jemand bezeichnete GPG als bereits seit Jahrzehnten verlorene Sache (lost cause) und meinte, ernsthafte Sicherheitsnutzer seien längst zu besseren Alternativen gewechselt
  • Der Blogbeitrag von GnuPG wurde veröffentlicht, aber es gab Reaktionen, dass es schwer nachvollziehbar sei, eine Funktion weiterzuführen, die 30 Jahre lang als „schädlich“ galt
    • Ein Nutzer bedauerte, dass Werner Koch sich lange Zeit GPG gewidmet habe, nun aber strukturelle Mängel, die sich grundlegend nicht beheben lassen, sichtbar geworden seien
  • Zu einigen GPG-Schwachstellen wurde angemerkt, es gehe um „nicht vertrauenswürdigen Text mit ANSI-Escape-Codes“, was sich wie eine Terminal-Version von XSS anfühle
  • Es gab auch die Analyse, dass die Paketstruktur von GPG selbst übermäßig komplex sei
    • Nachrichten bestehen aus Paketen in vielen unterschiedlichen Formen, wodurch Angreifer die Zustandsmaschine aus dem Takt bringen können
    • Insbesondere ein Malleability-Bug kann durch Fehler bei Zustandsübergängen dazu führen, dass Authentifizierungsprüfungen ausgelassen werden
    • Diese strukturelle Komplexität erzeuge eine „Weird Machine“; gefordert wurde ein Redesign mit einem einfachen und klaren Binärformat
    • Darauf gab es auch Reaktionen, dass diese Erklärung hervorragend sei
  • Auch die Frage, ob GPG den Standards entspricht, wurde weiter diskutiert
    • Manche meinten, „das ist nur ein Problem von GnuPG und vom OpenPGP-Standard getrennt“, andere hielten dagegen, dass auch in wichtigen PGP-Implementierungen wie Sequoia, minisign und age Parser-Schwachstellen gefunden wurden
    • Ein anderer Nutzer erklärte, das OpenPGP-Lager sei in LiberePGP (GnuPG) und RFC-9580 (Sequoia) gespalten, die jeweils einen minimalistischen bzw. maximalistischen Ansatz verfolgten. Wichtig sei, Standardkriege zu vermeiden und die Interoperabilität zu erhalten
    • Einige behaupteten, das Clearsig-Problem sei ein Fehler des OpenPGP-Standards selbst
    • Andere meinten, die Bugs in GPG gingen letztlich auf strukturelle Probleme des PGP-Protokolls zurück und seien damit faktisch Bugs auf Protokollebene
  • Im Zusammenhang mit GPG-Signaturen kam die Frage auf: „Ist es weiterhin sicher, GPG für git-commit-/tag-Signaturen zu verwenden?“
    • Ein Nutzer nannte als Beispiel die „Bitflip-Schwachstelle“ von GPG und erklärte, das sei ein schwerwiegendes Problem, bei dem Angreifer Klartext manipulieren könnten
    • Jemand anderes wies darauf hin, dass bereits die gemeinsame Nutzung eines einzelnen Schlüssels über mehrere Anwendungen hinweg riskant sei, und argumentierte, für jede App sollte ein separater Schlüssel verwendet werden
    • Eine weitere Stimme riet, diese Schwachstellen erreichten nicht das Niveau von Remote-Angriffen; nötig sei sorgfältige Nutzung statt Panik
    • Ein Nutzer berichtete aus eigener Erfahrung, dass er GPG und YubiKey auf mehreren Geräten verwendet habe und dann auf den 1Password SSH Agent umgestiegen sei, was alles deutlich vereinfacht habe
    • Ein anderer betonte, dass für einen vollständigen Ersatz von GPG das Problem der Schlüsselverteilung gelöst werden müsse. Schwieriger als die Signatur selbst sei die verlässliche Verteilung öffentlicher Schlüssel
  • Es wurden auch Bedenken über die Tendenz im Rust-Ökosystem geäußert, gedankenlos die MIT-Lizenz zu verwenden
    • Ein Nutzer sagte, viele nähmen sie, „weil MIT der Standard ist“, und warnte, dass mit dem Wegfall des Copyleft-Schutzes von GPL3 die Kontrolle der Nutzer geschwächt werden könne
    • Jemand, der dem zustimmte, sagte, er habe früher MIT verwendet, stelle aber inzwischen alle Projekte auf volles Copyleft um
    • Eine andere Person analysierte, dieses Phänomen trete nicht nur bei Rust, sondern in den meisten modernen Sprachökosystemen auf
      • Angesichts der Realität, dass Großunternehmen auf dem Code von Freiwilligen Imperien errichten, sehe man den Wert von Copyleft wieder neu
      • In Umgebungen, in denen GPL aus rechtlichen Gründen nicht eingesetzt werden kann, müsse man sich aber aus praktischen Gründen für permissive Lizenzen entscheiden
      • Ein schwaches Copyleft wie die Mozilla Public License hätte ein Mittelweg sein können, doch die FSF habe dafür nicht genug geworben, was bedauert wurde
    • Jemand meinte, „im Zeitalter, in dem Nichtmenschen (LLMs) Code lernen, braucht es neue, menschenzentrierte Lizenzen“
    • Eine andere Person sagte, „ob GPL oder MIT, am Ende ist Nutzungskontrolle auch nur ein Feature“, und betrachtete die Kontrolllogik Freier Software aus funktionaler Perspektive
    • Ein Nutzer hinterließ die pragmatische Einschätzung: „Damit Software langfristig überlebt, muss man zuerst Bugs beheben“
  • Es gab auch Leute, die GPG weiterhin nützlich finden
    • Mit OpenPGP-Smartcards oder zusammen mit einem YubiKey sei es recht stabil und leichter einzurichten als andere Hardware-Lösungen
    • Sie planen, es weiterhin eher für verschlüsselte Backups, Passwortmanager und SSH-Schlüsselverwaltung als für E-Mail zu verwenden