1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › PGP/SMIME: Angreifer können…

An Official Statement by the GnuPG and Gpg4Win teams

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. An Official Statement by the GnuPG and Gpg4Win teams

    Autor: X3N 14.05.18 - 17:24

    https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html

    1. This paper is misnamed.

    2. This attack targets buggy email clients.

    3. The authors made a list of buggy email clients.

    @Golem: Den Artikel besser noch einmal überarbeiten.



    1 mal bearbeitet, zuletzt am 14.05.18 17:26 durch X3N.

  2. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: hab (Golem.de) 14.05.18 - 19:33

    Hallo,

    Ich sehe nicht was wir überarbeiten müssten. Das mit MDC ist doch im Artikel so erläutert.

    Meine Einschätzung ist eine andere als die der GPG-Entwickler, ich denke es ist ein fundamentaler Fehler in der GPG-API, dass unauthentifizierter Plaintext ausgegeben wird. Aber ich denke von den dargestellten Fakten widerspricht die Stellungnahme der Darstellung in unserem Artikel nicht.

  3. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: scroogie 14.05.18 - 20:37

    Ich finde den Artikel auch in Ordnung, er erläutert die Situation gut. Aber trotzdem:
    Wenn ich eine sicherheitsrelevante API verwende, deren Fehlermeldungen komplett ignoriere und zurückgegebene Daten dennoch auf eine bekannt riskante Weise am Client rendere, würde ich das schon als Fehler in der Verwendung sehen. Es könnte ja im Falle einer Fehlermeldung auch einfach Bogus im Rückgabewert stehen.

  4. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: Mingfu 14.05.18 - 21:13

    scroogie schrieb:
    --------------------------------------------------------------------------------
    > Wenn ich eine sicherheitsrelevante API verwende, deren Fehlermeldungen
    > komplett ignoriere

    Das ist eine ziemliche bequeme Art der Verantwortungsabschiebung seitens GnuPG. Sicherheitsrelevante Entscheidungen sollte schon das für die Sicherheit verantwortliche Programm treffen und das nicht auf Dritte auslagern, die für eine informierte Entscheidung noch weniger Informationen zur Verfügung haben.

    Die Meldungen "WARNING: message was not integrity protected" + "DECRYPTION_FAILED" anzuzeigen, aber dann trotzdem die entschlüsselte Nachricht auszugeben, passen doch wohl nicht ins Jahr 2018, wenn man angeblich schon seit dem Jahr 2000 (rudimentäre) Gegenmaßnahmen implementiert hat, die man aber beim Empfang einer Nachricht nach wie vor nicht obligatorisch erwartet, weil bildlich gesprochen noch eine ganze alte OpenPGP-Version auf einer Zuse Z3 laufen könnte, die Nachrichten weiterhin ganz ohne Authentication verschickt. Wenn man die Sicherheit dermaßen der Rückwärtskompatibilität opfert, macht man etwas falsch - zumal Orakelangriffe auf Kryptosysteme, die mangelnden Integritätsschutz von Nachrichten ausnutzen, überhaupt nicht neu und beim von OpenPGP verwendeten Verschlüsselungsmodus auch noch extrem einfach umzusetzen sind.

    Das ganze OpenPGP-Protokoll ist völlig in der Vergangenheit verhaftet und ignoriert konsequent jeden Fortschritt im Kryptographiebereich. Und statt dass die Verantwortlichen die Gelegenheit jetzt nutzen und endlich einmal aufwachen, zieht man sich auf den Standpunkt zurück, dass wenn niemand beim Umgang mit OpenPGP einen Fehler macht und um sämtliche Schwachpunkte im Protokoll und deren Vermeidungsmaßnahmen weiß, es gar kein Problem geben würde. Motto: OpenPGP ist sicher, solange niemand auf die Idee kommt, es einzusetzen...



    1 mal bearbeitet, zuletzt am 14.05.18 21:15 durch Mingfu.

  5. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: Anonymer Nutzer 14.05.18 - 21:49

    Mingfu schrieb:
    > Das ganze OpenPGP-Protokoll ist völlig in der Vergangenheit verhaftet und
    > ignoriert konsequent jeden Fortschritt im Kryptographiebereich. Und statt
    > dass die Verantwortlichen die Gelegenheit jetzt nutzen und endlich einmal
    > aufwachen, zieht man sich auf den Standpunkt zurück, dass wenn niemand beim
    > Umgang mit OpenPGP einen Fehler macht und um sämtliche Schwachpunkte im
    > Protokoll und deren Vermeidungsmaßnahmen weiß, es gar kein Problem geben
    > würde. Motto: OpenPGP ist sicher, solange niemand auf die Idee kommt, es
    > einzusetzen...

    Vorweg: ich bin nicht der Krypto-Guru.

    Man kann doch den verschlüsselten Text immer noch per Copy & Paste auf der Kommandozeile entschlüsseln - und ist "safe"? Daraus folgt: es ist ein Client- bzw. Plugin - Problem. GnuPG/PGP bzw. die Kryptografie dahinter ist doch ungebrochen, darum geht es doch bei diesem Client-Angriff gar nicht?



    1 mal bearbeitet, zuletzt am 14.05.18 21:54 durch FalschesEnde.

  6. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: Mingfu 14.05.18 - 22:07

    Witzigerweise wäre man bei Nutzung der Kommandozeile tatsächlich sicher, weil in diesem Fall die Nachricht gar nicht ausgegeben würde:

    > When giving a filename on the command line an output file is even not
    > created.

    GnuPG verhält sich also auch noch völlig widersprüchlich. Was für die Kommandozeile als zu gefährlich gilt, wird bei automatischer Nutzung per Pipe durch Drittprogramme bedenkenlos gemacht...

  7. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: chithanh 14.05.18 - 23:27

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > GnuPG verhält sich also auch noch völlig widersprüchlich. Was für die
    > Kommandozeile als zu gefährlich gilt, wird bei automatischer Nutzung per
    > Pipe durch Drittprogramme bedenkenlos gemacht...

    Das Verhalten ändert sich nicht abhängig von Kommandozeile oder nicht, das ist völliger Quatsch.

    Das Verhalten ändert sich abhängig von Datei- oder Pipe-Ausgabe (beides ist sowohl auf der Kommandozeile als auch bei Nutzung durch Drittprogramme möglich), und es gibt handfeste technische Gründe wieso. Bei Dateiausgabe wird in eine temporäre Datei geschrieben die im Falle eines Fehlers dann einfach wieder gelöscht wird. Bei Pipe-Ausgabe kann man einmal ausgegebene (Giga-)Bytes nicht mehr zurückholen.

  8. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: X3N 15.05.18 - 00:55

    hannob (golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Hallo,
    >
    > Ich sehe nicht was wir überarbeiten müssten. Das mit MDC ist doch im
    > Artikel so erläutert.
    >
    > Meine Einschätzung ist eine andere als die der GPG-Entwickler, ich denke es
    > ist ein fundamentaler Fehler in der GPG-API, dass unauthentifizierter
    > Plaintext ausgegeben wird. Aber ich denke von den dargestellten Fakten
    > widerspricht die Stellungnahme der Darstellung in unserem Artikel nicht.

    Golemtext:
    Doch es gibt ein weiteres Problem: Wenn die MDC-Authentifizierung fehlschlägt, werden die Daten trotzdem von GnuPG entschlüsselt und ausgegeben, erst hinterher erfolgt eine Benachrichtigung, dass die entsprechenden Daten ungültig sind.

    Statement:
    GnuPG also throws large warning messages if an MDC indicates a message
    has been modified. In both cases, if your email client respects this
    warning and does the right thing -- namely, not showing you the email --
    then you are completely protected from the Efail attack, as it's just a
    modern spin on something we started defending against almost twenty
    years ago. [...] You might be vulnerable if you're running an ancient version of GnuPG
    (the 1.0 series; the current is 2.2), or if your email plugin doesn't
    handle GnuPG's warning correctly.

    Der feine Unterschied besteht darin, dass der Mailclient bzw. das Plugin für dieses Problem verantwortlich ist und nicht GnuPG. Dies suggeriert, dass etwas mit der Verschlüsselung nicht stimmt - was aber nicht der Fall ist.

  9. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: freebyte 15.05.18 - 01:57

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > Das ganze OpenPGP-Protokoll ist völlig in der Vergangenheit verhaftet und
    > ignoriert konsequent jeden Fortschritt im Kryptographiebereich.

    Ich bin einer der über Fortschritte im Kryptographiebereich nachdenkt und mit antreibt, aber ich verstehe nicht so ganz was Du von PGP erwartest ausser "encrypted rein, decrypted raus"?

    Wenn ich bei jedem Cryptoalgo über den potentiellen Bockmist nachdenken soll, den ein nachgeordnetes Programm mit dem decrypted Output anstellt dann werde ich lieber Ananaszüchter in Alaska weil man die Voraussetzungen noch die Konsequenzen einer allumfassenden Sicherheitsarchitektur vielleicht Dir - aber kaum noch den selbsternannten "Admins" und schon gar nicht meinem Schwager "aber ich will Dir doch nur ein Katzenvideo schicken" beibringen wird.

    Ich habe aus dem Vorfall lediglich zur Kenntnis genommen, dass wir es richtig machen :)

    fb

  10. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: Mingfu 15.05.18 - 06:27

    freebyte schrieb:
    --------------------------------------------------------------------------------
    > Ich bin einer der über Fortschritte im Kryptographiebereich nachdenkt und
    > mit antreibt, aber ich verstehe nicht so ganz was Du von PGP erwartest
    > ausser "encrypted rein, decrypted raus"?

    Ich erwarte beispielsweise, dass man die Verschlüsselung in einem Betriebsmodus verwendet, der eine erfolgreiche Manipulation der Eingangsnachricht unterbindet. Authenticated Encryption sollte also Standard sein und zwar in der Form, dass sie vom Programm auch verbindlich durchgesetzt wird, dass also kompromittierte Klartexte nicht ausgegeben werden.

    Und das Ganze sollte im Jahr 2018 nicht mittels einer optionalen SHA1-Frickellösung geschehen, sondern auf einem der wohluntersuchten Modi mit verifizierbaren Sicherheitseigenschaften basieren, wie GCM.

    > Wenn ich bei jedem Cryptoalgo über den potentiellen Bockmist nachdenken
    > soll, den ein nachgeordnetes Programm mit dem decrypted Output anstellt

    Das gehört im Sicherheitsbereich inzwischen eigentlich dazu, dass man sich überlegt, was (naheliegende) Fehlermöglichkeiten sind und wie robust das System darauf reagiert. Eine falsche Verwendung sollte in diesen Fällen dann gar nicht möglich sein, weil das System dies unterbindet.

    Denn dass man mit Fehlern rechnen muss, das sind einfach die Lehren, die man in der Vergangenheit immer wieder machen musste. Zumal die Verwender eines Systems sich normalerweise viel weniger über die Konsequenzen einer falschen Verwendung im Klaren sind, als deren Erschaffer. Wenn man dort nicht vorbaut, dann kann auf solche Dinge warten, wie sie hier passiert sind.

  11. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: RicoBrassers 15.05.18 - 08:49

    X3N schrieb:
    --------------------------------------------------------------------------------
    > Der feine Unterschied besteht darin, dass der Mailclient bzw. das Plugin
    > für dieses Problem verantwortlich ist und nicht GnuPG. Dies suggeriert,
    > dass etwas mit der Verschlüsselung nicht stimmt - was aber nicht der Fall
    > ist.

    Nur, dass GnuPG das Ganze auch selbst per default aktivieren könnte, sich aber dagegen entschieden hat, weil einige GPG-Implementationen mit einer seit über 15 Jahren existierenden Funktion zurückhängen.

    Nur, um das nochmal klarzustellen: GPG unterstützt MDC seit (spätestens) 2001. Die Aktivierung/Nutzung eines solchen Sicherheitsfeatures auf die Clients abzuwälzen, weil einige Implementationen eine Ewigkeit zurückliegen, ist einfach grob fahrlässig.

    Könnten die Mailclients das Problem beheben? Ja.
    Macht sich GPG aber zumindest mitschuldig und könnte das Ganze für die Zukunft "dauerhaft" für alle User beheben, in dem MDC endlich standardmäßig genutzt wird? JA, definitives JA!

    Hier die Schuld aufgrund von eigenen Versäumnissen auf die Mailclients abwälzen zu wollen, ist einfach nur peinlich. Sicherheitssoftware muss bereits standardmäßig so konfiguriert sein, dass sie ohne Anassung dieser Konfiguration eine ausreichende Sicherheit bietet und gegen bekannte Sicherheitslücken immun ist.

  12. Re: An Official Statement by the GnuPG and Gpg4Win teams

    Autor: freebyte 15.05.18 - 13:14

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > Ich erwarte beispielsweise, dass man die Verschlüsselung in einem
    > Betriebsmodus verwendet, der eine erfolgreiche Manipulation der
    > Eingangsnachricht unterbindet. Authenticated Encryption sollte also
    > Standard sein und zwar in der Form, dass sie vom Programm auch verbindlich
    > durchgesetzt wird, dass also kompromittierte Klartexte nicht ausgegeben
    > werden.

    "Authenticated Encryption" bedeutet letztendlich nur, dass dem schützbaren Teil der Nachricht eine Prüfsumme (MAC) mitgegeben wird. Das ist einfach, wenn die MAC sich nur auf den chiffrierten Text bezieht, es wird zu einem Problem wenn zB. bei multipart/alternative E-Mails noch Plaintext mit in die MAC soll (ohne dass das Cryptotool irgendwas über multipart/alternative wissen muss).

    > Zumal die Verwender eines Systems sich normalerweise viel weniger
    > über die Konsequenzen einer falschen Verwendung im Klaren sind, als
    > deren Erschaffer. Wenn man dort nicht vorbaut, dann kann auf solche
    > Dinge warten, wie sie hier passiert sind.

    Als Entwickler des Crypto-Tools hast Du schlechte Karten weil Du nur das verarbeiten kannst, was dir vom MUA an der API-Pforte angeliefert wird.

    Ich gehe mal davon aus, dass es MUAs gibt, die eine "signcrypted" Message sauber aus einem nachträglich zugefügten Wrapper herauslösen und an die Cryptoengine verfüttern.

    fb

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. SAP Projektleiter (m/w/x) - Schwerpunkt Produktion & Logistik
    über duerenhoff GmbH, Raum München
  2. Professional CRM SAP CX Berater / Entwickler (m/w/d)
    Radeberger Gruppe KG, Frankfurt am Main
  3. Fachinformatiker (w/m/d)
    Bundeskartellamt, Bonn
  4. Automation Expert (d/m/w)
    OSRAM Opto Semiconductors Gesellschaft mit beschränkter Haftung, Regensburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. No Man's Sky für 22,99€, Assassin's Creed Valhalla - Ragnarök Edition für 45,99€)
  2. 163,99€ statt 299€
  3. 1.279€ statt 1.599€
  4. 44,99€ statt 79,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Altris: Kathodenmaterial für Natrium-Ionen-Akkus kommt aus Schweden
Altris
Kathodenmaterial für Natrium-Ionen-Akkus kommt aus Schweden

Eine europäische Firma will vom Lithium wegkommen. Bis 2023 soll eine Pilotfabrik für Akku-Kathoden mit einer Kapazität von bis zu 1 GWh pro Jahr entstehen.
Von Frank Wunderlich-Pfeiffer

  1. Akkutechnik Neue Natrium-Ionen-Akkus von Lifun aus China ab 2023
  2. Rohstoffe Lithiumkarbonat für über 50 Euro/kg gefährdet Akkupreise
  3. Faradion Indischer Konzern kauft Hersteller von Natrium-Ionen-Akkus

Deklaratives Linux: Keine Angst vor Nix
Deklaratives Linux
Keine Angst vor Nix

NixOS ist genial zum Deployen von Software, doch der Einstieg ist hart. Über eine rasant wachsende Linux-Distribution und ihre Community, die viel erreicht.
Ein Erfahrungsbericht von Lennart Mühlenmeier

  1. Proton Epics Anti-Cheat-Tool läuft auf Linux
  2. Datenleck Sicherheitslücke im Shop von Tuxedo entdeckt und geschlossen
  3. Linux Treiberentwicklung fast ohne Hardware

WLAN erklärt: So erreichen Funknetzwerke Gigabit-Datenraten
WLAN erklärt
So erreichen Funknetzwerke Gigabit-Datenraten

Mehr Antennen, mehr Frequenzbänder, mehr Bandbreite: Hohe Datenraten per Funk brauchen viele Ressourcen - und eine effektive Fehlerbehandlung.
Von Johannes Hiltscher

  1. 802.11be Qualcomm steigt in die Welt von Wi-Fi 7 ein
  2. Im Maschinenraum Die Funktechnik hinter WLAN
  3. 802.11be Broadcom stellt komplettes Wi-Fi 7 Chip-Portfolio vor