Login
Newsletter
Werbung

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

41 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von klopskind am Di, 14. Januar 2020 um 15:02 #

Die Aktualisierung auf Thunderbird 68.4.1 ist dringend angeraten, falls dies nicht automatisch geschieht. Die meisten Distributionen bieten das aktuelle Paket bereits an.
Was heißt hier "die meisten"?

Aus meiner Sicht bieten bisher folgende Distributionen Thunderbird in Version 68.4.1 an:
Arch
Chocolatey (f. Windows)
CRUX 3.5
FreeBSD Ports
Gentoo (inkl. thunderbird-bin)
KaOS
Mageia 7
Manjaro
nixpkgs (f. NixOS, Linux, Darwin)
PCLinuxOS
Rosa
Scoop (f. Windows)
Slackware(64) (14.2 & current)
Solus
T2 SDE
Ubuntu 20.04
Void

In konkreter Vorbereitung scheinen sich zu finden:
Alpine Linux Edge (testing)
Debian (unstable, security(?))
MX Linux 19 (testing)
Fedora (32, 31 & 30 testing)

Ergo: Da fehlen so einige namhafte Vertreter.

  • 0
    Von klopskind am Di, 14. Januar 2020 um 15:06 #

    Nachtrag: Meine Quellen waren repology.org, LWN und in einigen Fällen auch distributionsspezifische Paketsuchmaschinen.

    0
    Von devil am Di, 14. Januar 2020 um 20:18 #

    Debian Unstable hab ich heute Mittag kontrolliert, da gabs die neue Version schon, MX sollte es also auch haben. Fedora ist meines Wissens dran.

    • 1
      Von klopskind am Di, 14. Januar 2020 um 23:14 #

      Debian Unstable hab ich heute Mittag kontrolliert, da gabs die neue Version schon, [...]
      Ja, so schrieb ich es ja auch. In Stable - also dort, wo es entscheidend ist, fehlt es weiterhin. Letzter Änderungseintrag:
      thunderbird (1:68.3.0-2~deb10u1) stable-security; urgency=medium
      [...]
      -- Carsten Schoenert Sat, 14 Dec 2019 10:31:09 +0100

      MX sollte es also auch haben.
      Wieso? MX 19 basiert auf Debian Buster. Laut der offiziellen Repodaten von MX enthält bisher nur MX 19 testing die neue Version.
      Package: thunderbird
      Version: 2:68.4.1-1~mx19+1
      Architecture: amd64
      Maintainer: Mike Purtell
      Installed-Size: 144781
      [...]
      Filename: pool/test/t/thunderbird/thunderbird_68.4.1-1~mx19+1_amd64.deb
      Size: 36303008
      SHA256: efdd2614952a53f440fcac45883cb8724085525b302e0de2cb8d65afddad3b08
      SHA1: 4113f7901c04658f7e970b0992149765904e9158
      MD5sum: 5e4ef0f4d412cae667e18b177b006971

      MX 19 (nicht testing) hat nur

      Package: thunderbird
      Version: 2:60.9.0-1~mx19+1
      Architecture: amd64
      Maintainer: Mike Purtell
      Installed-Size: 154323
      [...]
      Filename: pool/main/t/thunderbird/thunderbird_60.9.0-1~mx19+1_amd64.deb
      Size: 37901776
      SHA256: dd907c4f903bf3cf1cbaf56f0089f05a25f3eb202eb71bef771fdbf51c25bbfa
      SHA1: 555963035d9936afd805d3c16fc8e6c609980b71
      MD5sum: a589d6b55aa8ac8f49c404ec0c5a83db
      Fedora ist meines Wissens dran.
      Ja genau, bei Fedora war/ist es noch nicht bis Version 31 bzw. 30 durchgerutscht.


      Ich wollte darauf hinaus, dass es bspw. in den oben genannten, in openSUSE, SUSE, allen unterstützten Zweigen von Ubuntu außer 20.04, Mint, RHEL und CentOS bisher fehlt.

      • 0
        Von Mint-User am Mi, 15. Januar 2020 um 08:04 #

        Außer Mint? Das ist noch nicht bis zur mir durchgerutscht, habe noch 68.2.2

        • 0
          Von klopskind am Mi, 15. Januar 2020 um 08:48 #

          Hm, vielleicht habe ich mich in meinem letzten Kommentar unverständlich ausgedrückt. Tut mir leid. Das "außer" galt nur für etwaige Versionen von Ubuntu - nicht für die in der Aufzählung folgenden Distributionen. Ich hätte diesen Teil wohl besser in Klammern setzen sollen.

          Ich wollte keinen Widerspruch zu meinem ersten Kommentar erzeugen. Dort ist Mint nicht aufgeführt, was implizieren würde, dass Mint es nicht hat(te).

          Also verhält es sich mit Mint genau so, wie Sie es sagen. Und ich wollte dazu an keiner Stelle einen Widerspruch erzeugen.

        0
        Von Ach je ... am Do, 16. Januar 2020 um 10:31 #

        Ich wollte darauf hinaus, dass es bspw. in den oben genannten, in openSUSE, SUSE, allen unterstützten Zweigen von Ubuntu außer 20.04, Mint, RHEL und CentOS bisher fehlt.

        Nun ja, zu solchen Irrtümern kommt man vermutlich dann besonders leicht, wenn man openSUSE sowieso hasst.
        Der Update auf Version 68.4.1 kam hier bei mir die Tage über die Tagesroutine im KDE-Updater rein wie alle anderen Updates auch.

        Also, wenn man keine Ahnung hat ...

        • 0
          Von Ach je ... am Do, 16. Januar 2020 um 11:21 #

          Laut /var/log/zypp/history passierte der Update auf Version 68.4.1-lp151.1.1 am 10.01. gegen 20:05 ...

          • 0
            Von klopskind am Do, 16. Januar 2020 um 21:47 #

            Das ist die Version aus dem rein optionalen Mozilla-Repo von openSUSE. Dieses müsste man eigenhändig hinzufügen und aktivieren. Die Pakete darin wurden nicht von den regulären QA-Prozessen geprüft.

            In den regulären Standardpaketarchiven für Leap ist es bisher noch nicht erschienen. Dafür ist es inzwischen von Factory in Tumbleweed durchgerutscht.

            Sogar für SUSE Linux Enterprise befindet sich die Version in der QA-Phase.

            Zudem würde die reguläre Verfügbarkeit noch nicht dem Stand der Mailinglisten und des Bugtrackings entsprechen.

            Ihre Darstellungen sind irreführend, Ihre Kritik samt Unterstellungen ungerechfertigt.

            Quellen:
            Bugzilla - Thunderbird Vulnerabilities (Janunar 2020)
            Bugzilla - einschlägiger Trackingbug
            openSUSE Mailingliste: opensuse-security-announce (Janunar 2020)
            openSUSE Paketsuche Thunderbird
            SUSE CVE Register: CVE-2019-17015 (einer der CVEs, der Teil des MFSA 2020-01 & MFSA 2020-02 ist)
            openSUSE Leap 15.1 Repo
            optionales Mozilla Repo f. openSUSE Leap 15.1

            • 0
              Von Ach je ... am Fr, 17. Januar 2020 um 11:32 #

              Das ist die Version aus dem rein optionalen Mozilla-Repo von openSUSE. Dieses müsste man eigenhändig hinzufügen und aktivieren.

              Selten ist mir ein dümmlicheres Argument untergekommen. Außer den dreieinhalb Standard-Repos muss jedes andere manuell installiert, egal ob für Wine, Multimedia, Libre Office, Kernel, NVidia-Treiber.

              Ihre Darstellungen sind irreführend, Ihre Kritik samt Unterstellungen ungerechfertigt.
              Was klopskind schreibt, ist wie üblich einfach dummes Zeug.

              • 0
                Von klopskind am Fr, 17. Januar 2020 um 14:08 #

                Selten ist mir ein dümmlicheres Argument untergekommen.
                Es ist auch nicht das einzige...

                Zitate:

                The packages in the below repositories are not supported by openSUSE, meaning they may not be tested.
                For new Linux and openSUSE users, it is recommended to use the four default repositories: OSS, Non-OSS, Update and Update-Non-OSS. Later on when you familiarize yourself with package management you can add more repositories, such as Packman.
                Please make sure that you actually need a specific repository instead of blindly adding it. More repositories equates to more complexity in terms of software management, which means you will need some experience to avoid problems with your openSUSE operating system. In extreme cases system failure can occur.
                Warning: Adding additional repositories can sometimes carry risks.
                Quelle

                Ihnen gingen wohl die Gegenargumente aus, oder warum sehen Sie sich gezwungen, sich hier mit einem ad hominem zu behelfen?

                Was klopskind schreibt, ist wie üblich einfach dummes Zeug.
                Das ist lediglich Ihre persönliche Meinung samt eines weiteren ad hominem.

                Fazit: Im Selbstdisqualifizieren sind Sie Meisterin. Bravo!

                • 0
                  Von Ach je ... am Fr, 17. Januar 2020 um 14:40 #

                  Süß. Anfänger und Trolle wie klopskind sollten also fortschrittliche weiterführende Konfigurationen vermeiden. Danke für diese eindrucksvolle Bestätigung.

                  • 0
                    Von klopskind am Fr, 17. Januar 2020 um 15:16 #

                    Das ist lediglich Ihre irrationale Meinung samt erneutem ad hominem und widerlegt den Wahrheitsgehalt meiner Aussagen nicht im Geringsten - keine Argumente, keine Diskussion.

                    • 0
                      Von Ach je ... am Sa, 18. Januar 2020 um 14:15 #

                      Mit Trollen, die keine Ahnung haben und Systeme bashen, die sie nicht benutzen (vielleicht in der Jungsteinzeit mal gesehen haben) diskutiere ich nicht. Die lache ich aus. Und nenne sie Trolle.

0
Von polix am Di, 14. Januar 2020 um 16:07 #

Da ubuntu 18.04 im Moment nur die ältere 68.2.2 Version anbietet, bin ich froh darüber, dass ich Thunderbird nur der Hersteller-Seite verwende. Einfach 64-Bit tz-Ordner für Linux herunterladen, entpacken, und eine Desktop-Verknüpfung mit dem Starter anlegen. Alle updates werden dann direkt verteilt und könnnen manuell oder wenn ich mich nicht irre, automatisch erfolgen.

  • 0
    Von Ghul am Di, 14. Januar 2020 um 16:18 #

    Securityfixes werden üblicherweise zu den alten Paketversionen der noch gepflegten Distributionsversionen zurückportiert.
    Der Haken ist somit nur die Zeitfrage, wie lange das dauert.

    Und speziell im Fall von Ubuntu bekommt man bei Paketen aus universe und multiverse in der Regel keine Updates mehr nach dem Release der Distribution, da die Community dafür nicht aktiv genug ist und Canonical diese Pakete selber nicht pflegt. Das schließt leider oft dann auch Sicherheitsfixes mit ein, die beim Ubuntunutzer dann nie ankommen und das installierte System dann zum anfälligen Sicherheitsloch werden lässt, wenn diese Software regelmäßig benutzt wird.

    Und dann noch eine allgemeine Ergänzung zum ersten Abschnitt.
    Da die Sicherheitslücken für gewöhnlich erst im kleinen Kreis bekannt gemacht werden und eine Nachrichtensperre verhängt wird, haben die Softwareentwickler und Distributoren Zeit rechtzeitig darauf zu reagieren, so dass der Fix oftmals schon in den aktualisierten Paketen drin ist, bevor es irgendwo auf Newsseiten überhaupt bekannt gemacht wird.
    Die Schwachstelle ist hier nur, dass Kriminelle öffentliche Mailinglisten der Entwickler aktiv mitlesen könnten und es dann trotzdem vorher wissen, bevor es die Allgemeinheit über Nachrichtenseiten erfährt.

    • 0
      Von #! am Di, 14. Januar 2020 um 16:51 #

      Dazu muss man sagen, dass sich längst nicht alle Upstreamfixes in veraltete Versionen zurückportieten lassen. Es gibt eben Fälle, für die man mehr ändern muss, als was z.B. gemäß Debian Stale als reines Sicherheitsupdate gelten könnte.

      0
      Von Andre am Mi, 15. Januar 2020 um 08:59 #

      >> Securityfixes werden üblicherweise zu den alten Paketversionen der noch gepflegten Distributionsversionen zurückportiert.
      Der Haken ist somit nur die Zeitfrage, wie lange das dauert.

      Grundsätzlich kann man sich leider nicht auf ein gutes Patchmanagement verlassen. Ich hatte vor etwa 10Jahren etwa bei Debian einen "bekannten" lighttpd bug in verbindungen mit mysql, so das sql-verbindungen irgendwann nach 1Tag verloren gingen. Das Problem war damals bereits bekannt, und es gab eine "korrektur" für den lighttpd source.

      Also habe ich ein kleines PatchFile gebaut, es bei mir getestet und es den Paketmaintainern unter verweis zur Quelle zukommen lassen. Die haben sich dann Wochen später gemeldet - das sies testen werden, und hab dann niemehr etwas davon gehört. Statt dessen wurden andere Probleme gefixed und mein kompiliertes Package immer wieder erneut überdschrieben, so das ich mein Patchfile mehrfach wieder zurückportieren musste. Das war ein mehr als ernüchterndes Erlebnis.

      Auch bei Ubuntu LTS hatte ich schon vor einigen Jahren selbst erlebt das kritische Sicherheitslücken bei FTP Servern welche über monate hinweg nicht gefixed wurden - obwohls z.B. bei Debian schon längt gefixed war. Auch hier brachte die Kommunikation mit den Maintainern wenig erfolg.

      ===================

      Auch wär ich mir nicht sicher ob in "alten" LTS-Distributionen welche eventuell ältere Major-Releases einer Applikation/Desktops einsetzen SecurityFixes vom der aktuellen Major-Release gebackportet werden - und wenn ja, in welchem Umfang und in welcher Qualität. Das ist erstens nicht ganz trivial via Copy/Paste machbar, zweitens muss das jede Distro selbst machen, und meine o.g. Beispiele zeigen das die Praxis sicher nicht bei 100% liegt.

    0
    Von nurso am Di, 14. Januar 2020 um 17:52 #

    Es gibt einige Distros, unter denen laufen die neuen Firefox- und Thunderbird-Versionen von mozilla.org bereits nicht mehr, weil wenigstens Glibc 2.17 benötigt wird. CentOS6 z.B. oder auch Debian Wheezy oder Slackware 14.0.

    0
    Von Anonymous am Di, 14. Januar 2020 um 18:14 #

    Alle updates werden dann direkt verteilt und könnnen manuell oder wenn ich mich nicht irre, automatisch erfolgen.

    Man kann nach Updates suchen und diese automatisch installieren lassen. Letzteres geht aber nur, wenn TB in einem Verzeichnis installiert ist, das keine root-Rechte benötigt. In diesem Fall muss man das Update manuell vornehmen, ist aber auch keine große Sache.

    0
    Von Caramba am Mi, 15. Januar 2020 um 07:28 #

    Thunderbird 68.4.1 für Ubuntu 18.04 (LTS):
    sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa
    sudo apt update

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?

0
Von Christoph Schmees am Mi, 15. Januar 2020 um 12:33 #

"... weist Mozilla darauf hin, dass die Lücken generell nicht per E-Mail ausgenutzt werden können, da die Scripting-Funktion während des Lesens von E-Mails ausgeschaltet ist."

Viel Lärm um (fast) nichts, wie schon bei FF.

Wie der konkrete angebliche Angriff auf TB (in default-Einstellung) aussieht, würde mich brennend interessieren.

Oder ist es hier so wie bei FF, wo "Chinesen einen Angriff beobachtet" haben wollen? Belastbare Fakten, Angriffsvektor: Fehlanzeige.

Wenn ich einen Link klicke, dann wird der an den Browser übergeben. Ab dann ist der Browser verantwortlich (auch für JS), nicht mehr TB. Und FF kann man ja mit NoScript oder uMatrix gut gegen hergelaufene JS schützen.

Ist denn schon Sommerloch, dass um diese "Sicherheitslücken" so viel heiße Luft produziert werden muss?

0
Von Janko Weber am So, 19. Januar 2020 um 14:22 #

Ich denke vor Thunderbird muß man Angst bekommen. Binden die jetzt Desktop-Suche und Internet-Suche in ein e-Mail Programm ein? Eine Funktion die das Öffnen eines Link und damit das Starten des Browsers unterbindet habe ich nicht gefunden. Damit wäre das Problem doch gelöst. *?

Was spricht eigentlich gegen claws-mail und/oder Sylpheed?


MfG Janko Weber

Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung