Thunderbird 102 Release trotz leichten und schweren Fehlern

„Security geht vor“, aber es gibt Grenzen. Diese wurden beim Thunderbird 102 Update gestern wohl leicht überschritten.

Thunderbird 102 Release trotz leichten und schweren Fehlern

Auf der Fedora Developer Mailingliste ist ein interessanter Beitrag gelandet, in dem sich über das Thunderbirdupdate 102 ausgelassen wird. Die näheren Umstände spielen für den Beitrag keine Rolle, in Kürze: viel zu schnell, keine ausreichenden Test, Änderungen angemahnt.

Wichtig ist eine der Antworten eines Benutzers, der dank des Updates einige Konten und Filter verloren hat. Für ihn kam nur ein Downgrade + Backup in Frage. Ich hatte vor dem Lesen dieses Postings bereits eiN Ticket auf gemacht, weil bei mir andere Probleme aufgetreten sind:

Der erste Start erfolgte in English, obwohl alle Sprachpakete vorhanden waren, was ein anderes Problem für sich darstellt, denn diese hatte ich schon das letzte mal gelöscht, als die ungefragt alle wieder installiert wurden.

Dummerweise lassen sich diese Pakete nicht löschen. Thunderbird empfiehlt dazu den „Safe-Mode“ zu benutzen, also ohne Addons usw. . Das bringt und zum nächsten Problem:

Der Safe-Mode geht nicht

Ja, Leute Ihr hab richtig gelesen: Der eben noch empfohlene Muß-Immer-Starten-Modus geht nicht.

Die Anwendung startet zwar, aber nach dem Laden des Caches und der Konten passiert rein gar nichts mehr. Es kommt keine GUI, ergo kann man nichts machen. Neue Thunderbird starten dann natürlich auch nicht, weil schon eine Instanz läuft 😉 Da auch Strace nichts brauchbares geliefert hat, ist das jetzt Sache der Thunderbird Devs.

Ironischerweise oder „Zum Glück“ startet Thunderbird im Normalmodus noch, so daß es kein Totalausfall ist.

Bugreports bei Fedora und Mozilla sind raus und ich wette bei den anderen Distros sieht es nicht besser aus.

Die ganzen Quickpushes wurden übrigens nötig, weil Thunderbird < 102.0.2 eine schwere Sicherheitslücke hat, die dringend geschlossen werden mußte. Aber was nutzt es dem User, wenn er sicher ist, aber die Anwendung nicht mehr läuft? Zum Glück lief das Update es bei den Meisten mit kleinen oder gar keinen Fehlern durch, aber das in unter 24h schon 2 auf der Dev-ML über Fehler berichten, ist schon erstaunlich, weil das sonst nicht passiert.

PVA: kleines Sicherheitsloch im IMAP Modul

Wie das so mit komplexer Software ist, CVE Meldungen sind quasi vorprogrammiert, aber einfache Programmierfehler tun es meistens auch 🙁

PVA: kleines Sicherheitsloch im IMAP Modul

Jetzt ist der Einschlagkrater durch die im PVA gefundene Sicherheitslücke nicht besonders groß, man müßte Ihn vermutlich mit der Lupe suchen, weil kaum wer von dem neuen Feature wußte und es ausprobiert hat, aber, zur Vermeidung gleichartiger zukünftiger Unfälle, soll die Lücke seziert und dokumentiert werden.

Was ist passiert?

In der MailConnection-Komponente, die macht die IMAP Verbindung auf, war ein Programmierfehler drin, der die verschlüsselte Verbindung zum IMAP Server unterband. Wer also die neue Funktion schon ausprobiert hat , muß mindestens auf diesen Commit updaten: 685ee5ecaa486006a0cee04cac763ee479160e6e

Hier der fehlerhafte Code:

Properties props = System.getProperties();
if ( m.secure == true ) {
       props.setProperty("mail.store.protocol", "imaps");
} else props.setProperty("mail.store.protocol", "imap");

Session session = Session.getInstance(props, null);
Store store = session.getStore("imap");
store.connect(m.servername, m.username, m.password);

Statt die laut Konfiguration (m.secure) gewünschte Verbindungsart „imaps“ zu wählen, zog es der Code vor, dann doch unabhängig davon „imap“ zu verwenden. Korrekt wäre diese Zeile gewesen:

Store store = session.getStore();

Was war die Ursache?

Als Ursache konnte „mangelndes Verständnis“ der Methode getStore(…) ausgemacht werden, um genau zu sein, wurde erwartet, daß es sich um den Unterschied zwischen „POP3“ oder „IMAP“ handelt, weil der Sicherheitslevel wurde ja vorher schon festgelegt, aber leider überschrieb der Aufruf diese Voreinstellung wieder.

Was müßt Ihr tun?

Im Repo ist das Update bereits enthalten, so daß alle die, die Automatische Updates einspielen, schon sicher sind.
Wer seinen PVA selbst baut, der muß einmal updaten und compilieren.

Wie wurde es gefunden?

Vor 11 Jahren, ja, einfach weiterlesen, entschied ich, daß meine POP3/IMAP Serverlogs von einer Software auf genau diese unverschlüsselten Verbindungen prüft und den Benutzer darüber informiert, daß er irgendwo eine unsichere Konfig hat. 11 Jahre lang habe ich keine Email erhalten, und jetzt rettet dieses kleine Script dem PVA den Arsch 😉

PS: Falls wer dachte, daß man im Github einfach mal so ein Security Advisory schreiben könnte, der hat das noch nie versucht und mir ist jetzt klar, warum so viele Projekte mit Lücken, keine Securityeinträge haben 🙁