Ungewollter Klartextversand von PGP-Mails

  • Vorsicht bei der Weiterleitung von PGP-mails per TB-Filter!


    Wir haben das auf 3 Systemen ausprobiert und sind der Meinung:

    das ist ein ziemlicher Hammer.

    Eigentlich ein Fall für die Bugzilla-Liste aber es fand sich niemand,

    der das machen wollte. Ich hab keinen Account dort und beim Neuanlegen wird rumgezickt:


    You have requested an account token too recently to request another. Please wait a while and try again.

    So viel Zeit hab ich nicht.

    Zusammenfassung:

    Eine per Filter eingetragene Mail-Weiterleitung auf PGP-Mails erfolgt

    ungefragt unverschlüsselt - egal, ob für die Zieladresse ein PGP-Key vorliegt

    oder nicht.

    Thunderbird/91.8.1 und 91.11.0 (64-Bit) - Linux

    Verschlüsselung standardmässig aktiviert, _kein_ Master-Passwort

    definiert.

    Letzteres führt dann zumindest dazu, dass beim Empfang einer

    weiterzuleitenden Mail ein Passwort abgefragt wird.

    Hat man ein Master-Passwort definiert passiert das ganze wohl

    völlig ohne Zutun des Anwendert. (nicht getestet)


    Wer es nicht glaubt:

    Einen neuen Local-Folder anlegen

    Eine beliebige PGP-Mail hinein kopieren

    Einen Filter mit einer Weiterleitung für diesen Folder einrichten

    Den Filter ausführen

    Auf der Empfängeradresse nachsehen und staunen


    Das Subject kommt dabei als:

    "Fwd: ..." an

    Der Inhalt ist aber unverschlüsselter Klartext.


    Aufgefallen ist das, weil ein Kollege eine Nachrichtauf einen nicht-PGP-Account

    haben wollte, wenn eine Mail auf den PGP-Account eintrifft.

    Dafür hat er sich dann einen Einganfsfilter gebaut - und war _sehr_

    verwundert, das die Mail dort im Klartext ankam.

    Ich wollte das nicht glauben - dann habe ich es nochmals selbst

    und von 2 Leuten unabhängig testen lassen.


    ps: ich hab nun doch die Bugzilla-Account Mail bekommen.

    Zwei themenähnliche Bugs habe ich gefunden (beide knapp 20 Jahre alt )

    aber keiner beschreibt das Problem.

    Also habe ich das dort als neu eingetragen. (bug 1790736)


    Wenn es ein Feedback gibt werde ichs hier posten.

    Ich fände es ja auch toll, wenn das alles nur heisse Luft wäre.

    Aber m. E. ist das ein extremes Sicheheitsrisiko.


    Feedback wäre schön - vielelicht machen wir ja irgendwas grundsätzlich

    falsch. Aber wenn dem so wäre: auch einem doofen Anwender darf

    es nicht möglich sein, ungewollt entschlüsslte PGPs zu versenden.








  • Ich kann das hier mit Thunderbird 91.13.0 (64-Bit) unter Linux genau so nachvollziehen. Wobei die OpenPGP Schlüsselverwaltung von TB bei mir nur die öffentlichen Schlüssel enthält, die privaten Schlüssel lasse ich nach wie vor von 'gpg-agent' verwalten. Dort ist die Timeoutzeit auf 60s eingestellt, was dazu führt, daß bei eingehenden verschlüsselten Mails in der Regel immer nach der Passphrase gefragt wird – unabhängig von einem Masterpasswort in TB.


    Die Weiterleitung im Klartext erfolgt übrigens unabhängig davon, ob man für die Weiterleitung 'Eingebunden' oder 'Als Anhang' konfiguriert hat.


    Interessant wäre zu wissen, ob dieser Bug schon mit TB 68.* + Enigmal bestand, oder erst ab Version 78.* aufgetreten ist. Das wäre dann der zweite 'Hammer' nach 'Thunderbird stored OpenPGP secret keys without master password protection' (versehen mit der niedrigsten Sicherheitsstufe 'low'!):

  • .... Dort ist die Timeoutzeit auf 60s eingestellt, was dazu führt, daß bei eingehenden verschlüsselten Mails in der Regel immer nach der Passphrase gefragt wird – unabhängig von einem Masterpasswort in TB.

    ...

    Die Weiterleitung im Klartext erfolgt übrigens unabhängig davon, ob man für die Weiterleitung 'Eingebunden' oder 'Als Anhang' konfiguriert hat.


    Ta, das ist schon ein ziemlicher Klopfer - und ich hätte erwartet, dass bei den Supportern

    sofort der Alarm an geht. Aber der Status ist noch immer "UNCONFIRMED".

    Aber auch hier im Forum scheint das kaum jemand irgendwie zu berühren...


    Und wenn jemand keinen Agent verwendet und ein Masterpasswort eingegeben hat,

    dann macht der TB das ganz von alleine - und man bekommt nichts davon mit.

    Es sei denn, man hat das Filter-Log eingeschaltet und schaut da ab und zu mal rein.

    Ich finde das echt gruselig.

  • Aber auch hier im Forum scheint das kaum jemand irgendwie zu berühren...

    Die meisten sind doch mit der 'Bug-Inflation' der 102.* Version beschäftigt …


    Außerdem taucht im Thema 'Linux + PGP' auf – das schränkt den Kreis der interessierten Leser schon mal stark ein.

  • Außerdem taucht im Thema 'Linux + PGP' auf – das schränkt den Kreis der interessierten Leser schon mal stark ein.

    Unter Win haben wir das noch getestet - aber ich gehe davon aus, dass es dort genauso sein

    wird.


    • 23 hours ago - UNCONFIRMED


    "Die meisten sind doch mit der 'Bug-Inflation' der 102.* Version beschäftigt …"


    Vielleicht sollte ich mal nachsehen, ob es eine aktuelle Version von "Pine" gibt....

  • Ich kann den Fehler ebenfalls bestätigen, auch, dass das schon ein "dicker Klopfer" ist.


    Ganz so überdramatisch sehe ich das aber nicht. Denn, "wer Verschlüsselung ernst nimmt" oder sich durch seine E-Mails sogar in Gefahr begibt, der benutzt mindestens a) ein Masterpassword und wird b) niemals nicht E-Mails unbesehen per Filter an andere weiterleiten.

    Was ich deshalb auch nicht getestet habe, werden die E-Mails verschlüsselt weitergeleitet, wenn denn ein Schlüssel vorhanden ist?

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Also habe ich das dort als neu eingetragen. (bug 1790736)

    Ich kann Bug 1790735 und 1790737 aufrufen, aber nicht Bug 1790736:

    Access Denied
    You are not authorized to access bug 1790736. To see this bug, you must first log in to an account with the appropriate permissions.
    bugzilla.mozilla.org


    You are not authorized to access bug 1790736. To see this bug, you must first log in to an account with the appropriate permissions.

  • Hallo schlingo ,


    habe es eben eingeloggt probiert.

    Kann das von Veteran und Boersenfeger beschriebene "Zugriff verweigert" wegen nicht ausreichender Rechte bestätigen.


    Gruß

    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

  • Dass sicherheitsrelevante Bugs nicht für jeden einsehbar sind, ist ganz normale Praxis.

    So ist es.

    Ich hatte allerdings damit gerechnet, dass das innerhalb von 5 Tagen zumindest mal confirmed wird.

    Ist ja kein sonderlich kompelxer Versuchsaufbau dafür nötig.

    In der Bugmeldung steht das gleiche drin wie hier am Anfang dieses Threads.



    oh, ich seh grad:

    status ist immer noch UNCONFIRMED. aber es ist ein reply da:


    doch an der Stelle hab ich erst mal aufgehört zu lesen.

    und eine Schachtel Valium eingeworfen:


    "I agree it's not ideal. But I'm not sure it's a security issue,"


    das ist was für morgen.....



    Thanks for your report.

    I agree it's not ideal. But I'm not sure it's a security issue, because it's the user's own's decision and action that triggers the forwarding.

    I'd agree this problem as an incomplete implementation that doesn't warn the user about all possible, potentially problematic consequences of configuring automatic filter actions.

    Fixing the scenario you describe will have larger consequences, I think.

    Sending the message with encryption might not be possible. This means that a filter action could fail for some messages. How would we handle that? A filter could run on many messages, so it isn't as simple as showing a popup for each failure. We'd have to ensure the user can learn about all failed filter actions.

    I think this is a difference from today, because today all filter actions are expected to always succeed, right?

    --------

  • Sending the message with encryption might not be possible. This means that a filter action could fail for some messages. How would we handle that?

    Ich habe den Eindruck, sie haben das Problem noch nicht ganz verstanden. Im vorliegenden Fall ist ein gültiger Schlüssel für den Empfänger vorhanden, die Verschlüsselung also problemlos möglich. Da stellt sich die Frage nach dem Fehlerfall erst gar nicht.


    Bei meinem Test wurde ich beim Entschlüsseln nach der Passphrase gefragt, während der Weiterleitung aber nicht noch einmal zum Unterschreiben. Da war mir schon klar, daß sie nicht in der Form erfolgt war, wie bei manueller Weiterleitung.


    Wenn ein Anwender 'Verschlüsseln + Signieren' vorgegeben hat und das ohne Probleme möglich ist, hat TB das auch so umzusetzen – ohne Wenn und Aber!

  • Sending the message with encryption might not be possible. This means that a filter action could fail for some messages. How would we handle that?

    Ich habe den Eindruck, sie haben das Problem noch nicht ganz verstanden.

    .....

    Wenn ein Anwender 'Verschlüsseln + Signieren' vorgegeben hat und das ohne Probleme möglich ist, hat TB das auch so umzusetzen – ohne Wenn und Aber!

    Ja, so sehe ich das auch - und so sollte das jeder sehen.

    Ich habs nochmal in Bugzilla erläutert.

    Denn ich brauche ja nur 1 Minute zugang zu dem TB-Mailer des Users

    um einen Filter einzurichten und bekomme dann _alle_ seine PGP-Mails

    unverschlüsselt als Klartext - und der User merkt _nichts_ davon.


    Sowas darf nicht sein.

  • Das ist zweifelsfrei ein Fehler, der dringend behoben gehört. Keine Frage! Als Optimistin gehe ich auch davon aus, dass das geschehen wird. Bis dahin ist es gut, dass der Fehler nun bekannt ist. Ginge es nach mir, sollte das auch ganz offiziell publiziert werden.


    Und doch, seien wir mal ehrlich, wohl niemand hier im Forum geriete in ernsthafte Bedrängnis, wenn seine E-Mails unverschlüsselt wären. Schließlich sind 99,x Prozent aller E-Mails eh unverschlüsselt. Die meisten der ohnehin verschwindend wenigen "Verschlüsseler" machen das, weil sie sich vor mitlesenden Providern schützen wollen, vor Diebstahl oder meinetwegen auch nur, weil sie es können.

    Diejenigen, für die Gefahr für Leib und Leben bestünde oder die zu Firmengeheimnissen kommunizieren etc. , die leiten nicht unbesehen per Filter weiter. Die stellen auch sicher, dass niemand unbefugt Zugriff auf den Rechner bekommt. Die nehmen Verschlüsselung nämlich wirklich ernst und tun nicht nur so. Solche Dokumente verbleiben auch nicht im Thunderbird, sondern landen in einem gesicherten Bereich oder werden gleich sicher gelöscht.


    Also, ich finde es wirklich großartig, dass wicki_w bzw. sein Kollege diesen Fehler gefunden hat. Der schlummert möglicherweise schon immer und gehört auch meiner Meinung unbedingt gefixt. Man sollte ihn aber nicht größer machen als er ist. Das hat sonst immer etwas von dem Splitter im Auge das anderen, hier Mozilla.


    Nebenbei: Wenn man eine verschlüsselte E-Mail zum Lesen entschlüsselt hat, dann verbleibt deren Inhalt zunächst noch im RAM, schlimmstenfalls sogar in einem Cache auf der Festplatte, auch wenn sie längst nicht mehr angezeigt wird. Das habe ich vor Jahren mal unter Windows getestet, indem ich den RAM nach Passagen einer solchen E-Mail durchsucht habe.

    Wenn also jemand Zugriff zu dem Rechner bekommt, dann ist es nicht schwierig, diese E-Mails abzugreifen. Ganz zu schweigen von all den anderen Dokumenten. Dazu braucht es keinen Filter. Will man sich schützen, ist die wichtigste Maßnahme daher immer die, den Zugriff auf den Rechner zu verhindern und dafür zu sorgen, dass er selbst bei Diebstahl nach heutigen Maßstäben sicher ist.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Also, ich finde es wirklich großartig, dass wicki_w bzw. sein Kollege diesen Fehler gefunden hat. Der schlummert möglicherweise schon immer und gehört auch meiner Meinung unbedingt gefixt.

    Vielleicht findet sich ja noch jemand, der das mit TB 68 + Enigmail testen kann …

    Man sollte ihn aber nicht größer machen als er ist. Das hat sonst immer etwas von dem Splitter im Auge das anderen, hier Mozilla.

    Der Vergleich hinkt – der Anwender kann hier als 'Workarround' nur auf die Weiterleitung per Filter verzichten. Die Verantwortung liegt einzig und allein bei Mozilla!

  • Da hinkt gar nichts. Ja, die Verantwortung für den Fix liegt selbstverständlich bei den Entwicklern.


    Die Verantwortung für den Umgang mit E-Mails, insbesondere vertraulichen, liegt aber bei den Benutzern. Jemand, der eine vertrauliche E-Mail schickt, entscheidet über den Kreis der Empfänger. Eine solche E-Mail einfach ungefragt weiterzuleiten - und dann auch noch unbesehen per Filter - das ist, um es mal deutlich zu sagen, eine Sauerei. Das widerspricht dem Geist der Verschlüsselung komplett.


    Insofern sollte es für jemanden wie dich, der du hier doch stets darauf hinweist, wie erst du im Gegensatz zu Mozilla die Verschlüsselung nimmst, doch überhaupt keine Option sein, auch nur an ein solches Filter zu denken.

    Wer nicht einmal den eigenen Rechner bei Verlassen konsequent sperrt, der sollte nicht dauernd auf Mozilla zeigen.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Eine solche E-Mail einfach ungefragt weiterzuleiten - und dann auch noch unbesehen per Filter - das ist, um es mal deutlich zu sagen, eine Sauerei. Das widerspricht dem Geist der Verschlüsselung komplett.

    Wer lesen kann, ist klar im Vorteil:

    Aufgefallen ist das, weil ein Kollege eine Nachricht auf einen nicht-PGP-Account haben wollte, wenn eine Mail auf den PGP-Account eintrifft.

    Also nichts von wegen 'ungefragt' …

    Insofern sollte es für jemanden wie dich, der du hier doch stets darauf hinweist, wie erst du im Gegensatz zu Mozilla die Verschlüsselung nimmst, doch überhaupt keine Option sein, auch nur an ein solches Filter zu denken.

    Habe ich das Thema aufgebracht? Ich habe es auf meinem System getestet und kann den Bug bestätigen.


    'Weiterleiten an:' ist eine Standard-Aktion in den Filtern von Thunderbird und sollten auch mit verschlüsselten Nachrichten funktionieren – vor allem, wenn ein gültiger Schlüssel für den Empfänger vorliegt.

    Wer nicht einmal den eigenen Rechner bei Verlassen konsequent sperrt, der sollte nicht dauernd auf Mozilla zeigen.

    Deine Unterstellungen entbehren jeder Grundlage und sind auf Dauer einfach nur langweilig.

  • Wer nicht einmal den eigenen Rechner bei Verlassen konsequent sperrt...

    Also das mit dem "Rechner sperren", das sehe ich auch nicht als so

    sehr wichtig an. Es geht nicht um die Codes von Putins oder Bidens Sprengköpfen.... ;)


    Ich möchte nur nicht, dass jeder, der mal an den TB ran kommt, dann auch gleich

    alle PGP-Mails lesen und versenden kann.

    Das geht ja auch (nach bisherigem Kenntnisstand) nicht.

    (Wenn man Timeout für die Passphrase kurz genug setzt)


    Aber die Einrichtung eines Filters zur Weiterleitung, die ist möglich auch ohne

    PGP-Key/Passphrase.

    Und wenn die Weiterleitung einmal drin ist, dann merkt der Anwender das nicht.

    So lange er nicht aktiv danach sucht. Und alle Mails werden dann unverschlüsselt

    weiterlgeleitet.