Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
- Thunderbird-Version: 68.x
- Betriebssystem + Version: Windows 10 (1903)
- Kontenart (POP / IMAP): n/a
- Postfach-Anbieter (z.B. GMX): n/a
- Eingesetzte Antiviren-Software: Windows Defender
- Firewall (Betriebssystem-intern/Externe Software): Windows Defender
- Router-Modellbezeichnung (bei Sende-Problemen): n/a
Ein Hinweis auf ein reproduzierbares Problem beim Update auf die Version 68.x in Kombination mit CardDav/Cardbook.
Kurzform:
Beim Update auf die Version 68.x kann es zu Datenverlust in CardDav-Adressbüchern kommen! Das Problem tritt unmittelbar nach dem Update auf. Nach anschließender Wiederherstellung treten keine weiteren Probleme auf.
Details:
Ich habe (inzwischen mehrfach, auf verschiedenen Clients) folgendes Phänomen beobachtet: Nach (Live-) Update auf die angebotene Version 68 wurden die nicht kompatiblen Erweiterungen erwartungsgemäß deaktiviert und sogleich upgedatet. Im Fall von Cardbook auf die Version 42.3/42.4, die mit Thunderbird 68.x kompatibel ist. Der Kalender Lightning wurde auf zugehörige Version 68.x gehoben.
Unmittelbar danach meldeten Cardbook und Lightning Synchronisationsfehler. Eines meiner Adressbücher war nun leer. Das Log von Cardbook enthielt zahlreiche Einträge, die besagten, dass die Kontakte eines Adressbuchs vom Server gelöscht wurden. Zum Glück traf das nicht zu. Ein Blick auf den Server zeigte, dass das Adressbuch unversehrt vorhanden war. Der Server (Radicale) hatte aber massive Störungen. Adressbücher und Kalender waren nicht mehr verfügbar bzw. konnten nicht synchronisiert werden.
Nach Neustart des Servers konnte ich das betroffene Adressbuch in Cardbook neu anlegen. Sämtliche Kontakte waren wieder da. Auch die Kalender waren alle wieder in sync.
Einen Tag später meldete das Backup vom Server Fehler. Ein genauer Blick zeigte, dass eine Adressbuchdatei korrupt war. Sie ließ sich nicht mehr lesen und somit auch nicht kopieren. Das ist vermutlich auf den hängenden Server zurückzuführen. Ich habe die Datei aus dem Backup des Vortages wieder hergestellt.
Zwei Tage später: Der Thunderbird wurde auf zwei weiteren Rechnern upgedatet. Das Resultat war ähnlich. Es waren anderen Adressbücher betroffen. Der Server hatte sich erneut aufgehängt.
Rund eine Woche später, gestern Abend, das Update auf Thunderbird 68.1.1 sowie Cardbook 42.4. Wieder bringt das Update den Server zum hängen.
Dieses Mal ist auch ein Adressbuch beim Provider betroffen. Das ist ein Indiz dafür, dass das Problem grundsätzlich nicht auf unsere eigene Infrastruktur zurückzuführen ist. Auch andere Server können betroffen sein.
Das Problem trat bisher auf jedem Client auf, der diese Updates bekommen hat und trat unmittelbar mit dem Neustart auf. Beschädigt wurden jeweils nur Adressbücher. Die Kalender gingen wegen des Serverausfalls offline, blieben aber intakt.
Neben den upgedateten Windowsrechnern gibt es in unserem Netzwerk noch weitere Windowsrechner und Linux Clients mit Stand Thunderbird 60.x sowie diverse Smartphones mit unterschiedlichen Betriebssystemen, auch Exoten, insgesamt rund 30 Clients. Die Umgebung ist seit Jahren stabil. Ein Problem dieser Art war bisher nicht auftreten.
Neben Adressbüchern auf der eigenen Infrastruktur war auch ein Adressbuch bei einem Provider betroffen. Die Konfiguration der Thunderbird Clients ist weitgehend gleich. Neben CardBook und Lightning werden lediglich 2 Erweiterungen benutzt, Enigmail und AllowHTMLTemp. Beide sind zur 68 kompatibel. Die Clients sind selbstverständlich nicht gepimpt, zusätzlichen Scripte werden schon gar nicht benutzt.
Mein Fazit:
Das Problem steht im direktem Zusammenhang mit dem Update. Ob durch Thunderbird oder an Cardbook verursacht, vermag ich nicht zu sagen. Deshalb rate ich zur Vorsicht beim Update auf die 68.x. Insbesondere, wenn über Cardbook eingebundene CardDAV-Adressbücher existieren. Vor dem Update sollte unbedingt ein Backup erstellt werden. Möglicherweise hilft es, die Verbindung zum CardDAV-Server vor dem Update zu trennen und erst nach dem Neustart wieder zu etablieren.
Ich habe mich vorerst zu einem kompletten Rollback entschieden, wobei CVE-2019-11755 noch einige Fragen aufwirft.
Ich könnte versuchen, das Problem anhand von Logs und eines Netzwerk-Traces genauer zu untersuchen. Jedoch hat mich dieses Update inzwischen einige Stunden meiner Freizeit gekostet. Weitere Zeit und Energie werde ich nicht investieren.
Dieser Beitrag ist daher lediglich als Hinweis für andere gedacht.