Login
Newsletter
Werbung

Thema: Thunderbird 68.4.1 schließt bereits ausgenutzte Sicherheitslücke

5 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von Drubadix am Mi, 15. Januar 2020 um 00:43 #

Für was müssen e-Mails überhaupt code fähig sein?
Auch der Sinn von html-mails erschließt sich mir nicht.

Bei verschlüsselten mails kennt man den Absender und bei unverschlüsselten könnten die server die Weiterleitung blockieren wenn code enthalten ist. Auf diese Weise würde man eine der größten Einfallstore für Schadcode schließen.

  • 0
    Von Anonymous am Mi, 15. Januar 2020 um 10:46 #

    Aber dann könnten die Dummuser sich nicht mehr gegenseitig mit lustigen bunten Mails bespassen. Das geht ja wohl gar nicht!

    0
    Von klopskind am Mi, 15. Januar 2020 um 10:47 #

    Warum code in e-mails? Für was müssen e-Mails überhaupt code fähig sein?
    Erstens bedeuten bereits ASCII, UTF-8 oder sonstige Zeichensätze, dass eine Kodierung/Dekodierung stattfindet. Du liest ja nicht die übertragene Mail Byte für Byte. In dieser Hinsicht enthält eine Mail immer "code".

    Zweitens heißt die Anwesenheit bzw. Übertragung von "code" nicht, dass er auch gelesen, interpretiert und ausgeführt wird. Wieso also kein "code" in Mails?

    Auch der Sinn von html-mails erschließt sich mir nicht.
    Mir erschließt er sich schon. Man möchte Texte im Allgemeinen gerne möglichst frei und praktikabel formatieren - so auch Mails. Dazu möchte man eventuell Bilder einbetten. Man kann jetzt lang über die konkrete Spezifikation der Auszeichnungssprachen, die hierfür infrage kämen, diskutieren. HTML in Mails wurde per zusätzlichem RFC als Auszeichnungssprache neben unformatierten Texten und Zeichensätzen standardisiert. Das lag vermutlich an der damalig bereits bestehende Verbreitung von HTML. Und da mit Browsern die nötige Software bereits existierte, um HTML zu interpretieren und darzustellen, lag der Schritt nahe, das für Mail anzupassen.

    Natürlich sollte man aus Sicherheitsgründen in Mails nur eine kleine, sichere Untermenge von HTML unterstützen, d.h. u.A. also kein JavaScript ausführen oder externe Seitenelemente nachladen. Für eine erste Übersicht schauen und testen Sie doch mal welche HTML-Tags/Attribute in diesen Kommentaren zugelassen sind. In dieser Hinsicht sollten Mail-Klienten also nicht fähig sein, "code" ausführen zu können.

    Bei verschlüsselten mails kennt man den Absender und [...]
    Wer kennt den Absender verschlüsselter Mails? Wer ist "man"?

    Die Felder des Mail-Header können lauter Kokolores enthalten. Wenn man Glück hat, ist die gesamte Kette der Adressen der MTAs unverfälscht. Sobald ein MTA über seinen Vorgänger lügt, wird es kompliziert. Die Felder From und Reply-To können vom tatsächlichen Absender frei erfunden sein.

    Und auch eine Verschlüsselung hilft hier nicht weiter. Verschlüsselung ist keine Authentifizierung. Welche Art der Verschlüsselung meinen Sie? Cäsar-Verschlüsselung? Asymmetrische Verschlüsselung? Auch bei GPG kann eine angehängte Signatur schon vom tatsächlichen Absender absichtlich irreführend sein, oder gar auf dem Weg zum Empfänger verfälscht worden sein. Sie setzen hier voraus, dass die Vertrauenskette bereits hergestellt wurde.
    Schlagen Sie also implizit vor, dass man Mails nur noch von denjenigen erhalten kann, mit welchen man über andere Kanäle bereits eine Vertrauenskette herstellen konnte? Ich denke nicht, dass sich Mail so durchgesetzt hätte.

    [...] bei unverschlüsselten könnten die server die Weiterleitung blockieren wenn code enthalten ist.
    Dafür müssten die Server den Inhalt der Mails interpretieren. Das verschiebt also nur das Problem von der Klient-Software (MUA/MRA) auf die Server-Software (MSA, MTA oder MDA). Zudem zentralisiert sich so der Aufwand. Damit wird es aufwändiger einen Server zu betreiben. Die Kosten würden steigen. Außerdem liegt dann eine sicherheitskritische Stelle mehr in der Server-Software.

    Die Frage, was "code" in diesem Zusammenhang denn überhaupt bedeutet, hatte ich ja bereits angeschnitten, siehe oben.

    Auf diese Weise würde man eine der größten Einfallstore für Schadcode schließen.
    Nein, so einfach geht das nicht. Bestenfalls verlagert es das Problem an eine ungünstigere Stelle, und so nebenbei definieren wir Mail grundlegend neu - durch massive Einschränkung der Features und RFCs (siehe oben). Da werden Sie sicherlich großen Beifall ernten.

    • 0
      Von blubbermal am Mi, 15. Januar 2020 um 12:16 #

      Dann ist wohl ein Font-Code wohl ein Code im Sinn einer ausführbaren Datei?

      Der Inhalt einer Mail wird von der Content-Firewall kontrolliert. Wenn er sich diese leisten kann ;-)

      • 0
        Von klopskind am Mi, 15. Januar 2020 um 16:13 #

        Dann ist wohl ein Font-Code wohl ein Code im Sinn einer ausführbaren Datei?
        Was genau meinen Sie mit Font-Code? CSS Web Fonts? Das wäre ein nachgeladenes Element.

        Aus welchem Teil meines Kommentars schließen Sie, dass dies zutreffen würde? Und worauf wollen Sie damit hinaus?

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung