Thunderbird – Ausführen beliebigen Programmcodes

Thunderbird About infos 52.5.0
Alle Thunderbird Versionen vor 52.5.0 sind von einer Remote-Code-Execution (RCE) Schwachstelle und anderen Sicherheitslücken betroffen, die als schwerwiegend eingestuft wurden.

Alarmstatus

Fedorabenutzern stehen derzeit (Stand: 28.11. 14:19 Uhr) KEINE Updates zur Verfügung.

Wie uns Jan Horak von RedHat mitteilt, befindet sich Thunderbird 52.5.0 derzeit im Bau. Testversionen werden daher vermutlich heute noch für Fedora bereitstehen.

Update

Seit 14:55 Uhr stehen die Updates für Fedora zum Download in Koji bereit.

Die frischen RPMs könnt Ihr dann für Eure jeweilige Fedoraversion hier finden :

Fedora 25 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005614
Fedora 26 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005616
Fedora 27 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005615
Fedora 28 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005618

CERT Warnung zu Thunderbird

Die Warnung des Bund-CERT finden Sie hier : https://www.cert-bund.de/advisoryshort/CB-K17-2035

Thunderbirds Mitteilung

Mozilla stuft die Sache schon etwas genauer ein und dafür, das es bereits am 23. November 2017 gemeldet wurde, haben unsere Distributionen echt langsam gearbeitet, alle, auch Suse .

Wer sich ein Bild machen will, hier die nötigen Infos:

Impact: critical
Products: Thunderbird
Fixed in Thunderbird 52.5

„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-2017-7828: Use-after-free of PressShell while restyling layout

„A use-after-free vulnerability can occur when flushing and resizing layout because the PressShell object has been freed while still in use. This results in a potentially exploitable crash during these operations.“

CVE-2017-7830: Cross-origin URL information leak through Resource Timing API

„The Resource Timing API incorrectly revealed navigations in cross-origin iframes. This is a same-origin policy violation and could allow for data theft of URLs loaded by users.“

CVE-2017-7826: Memory safety bugs fixed in Firefox 57, Firefox ESR 52.5, and Thunderbird 52.5

„Mozilla developers and community members reported memory safety bugs present in Firefox 56, Firefox ESR 52.4, and Thunderbird 52.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort that some of these could be exploited to run arbitrary code.“

Glückwünsche

Wie unsere Quellen berichten, stellt OpenSUSE bereits eine gepatchte Version für SUSE Linux Enterprise 12 sowie OpenSUSE Leap 42.2 und 42.3 bereit.

Glückwünsche an SUSE, Ihr wart die ersten 🙂

 

Redhat-Webseite des Session-Replaying bezichtigt

Da haben es Forscher der Princeton Universität mal genauer genommen und eine Menge bekannter Webseiten auf sogenanntes Session-Replaying untersucht. Dummerweise sind davon nicht nur hierzulande eher unbekannte Webseiten zu finden, sondern auch Teamviewer, wordpress.com, wp.com, conrad.de, comodo.com, Skype & Microsoft und Redhat .

Was ist Session-Replaying ?

Session-Replaying bezeichnet Trackingtechniken in Javascript, die alle Tastatureingaben, alle Mausbewegungen usw. aufzeichnen und zur Auswertung an einen Drittanbieter übermittelt. Natürlich ohne vorher zu fragen, ob die das dürfen. Mit den Daten kann man als Webseitenbetreiber auswerten lassen, wo die eigenen Seiten besonders gut oder besonders schlecht sind. Soweit, so „naja“. Jetzt zeichnen die Scripte aber auch Fehleingaben auf, also z.B. alles was in der Zwischenablage ist und per Copy&Paste unabsichtlich kopiert wird, bspw. auch Passwörter.

Was damit für Schindluder getrieben werden kann, kann sich jeder selbst ausmalen, dem das Copy&Paste schon einmal seine Dienste versagt hat. Das geht nämlich leider schneller, als einem Lieb ist.

Für Redhat kommt der Dienst von clicktale.net ins Spiel. Dieser wurde von Princeton mit dem Vermerk : „evidence of session recording“ versehen.

Gegenmaßnahmen

Wenn es nach dem jüngsten FireFox Update auf 57 gegangen wäre: Keine.

Glücklicherweise hat Giorgio Maone sein Plugin NoScript auf die neue Firefox Api angepaßt. Damit kann man die Tracking-Domains sperren, bzw. erst gar nicht aktivieren. Also, alle die an Giorgio gezweifelt haben, sollten vor Ihm auf die Knie fallen und um Entschuldigung bitten. Der Mann und sein Plugin können Euch jeden Tag den Arsch retten! Das Teil ist für den Datenschutz der Goldstandard. Wundert mich eigentlich, daß die Bundesdatenschutzbeauftragte das nicht für jeden Behörden PC vorschreibt. Das wäre ja mal was 🙂

Die Liste

Wer sich die Liste ansehen will, die ist hier erhältlich:

https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

Ihr werdet noch mehr prominente Namen finden z.B. addidas.com , dominos.com ( Ex-Joeys ) , symantec.com, mongodb.com, cpanel.net, magento.com, bitdefender.com, acrobat.com, worldoftanks.com und wenig verwundernd kaspersky.ru .

Linux – DNS-DeTracking mit nscd

Das Problem

Wenn man alle seine DNS Anfragen über einen einzigen Anbieter abwickelt, kann der leicht herausbekommen, wofür man sich interessiert, da er ja jede Domain kennt, mit der man „reden“ will.

Wenn man von einem DNS Anbieter, sei es die Deutsche Telekom oder Google, nicht vollumfänglich getrackt werden will, kann man nur seinen eigenen DNS-Cache betreiben, oder laufend den DNS Anbieter wechseln ? Oder gibt es da vielleicht noch eine dritte Möglichkeit ?

Methode 1:

Jeder kann sich einen DNS Cache auf dem eigenen PC installieren. Der Nachteil ist, es ist nicht besonders effizient und bei einigen DSL-Anbietern kann man auch nicht selbst die DNS Auflösung machen. In letzterem Fall solltet Ihr Euch auf jeden Fall einen Tunnel in die freie Welt aufbauen, z.b. per VPN. Einen eigenen Server der dafür ausreicht kann man sich schon für 6,50 € im Monat mieten. Ihr braucht  dann noch sowas : UDP Traffic per SSH tunneln, Die Vorratsdatenspeicherung umgehen oder VDS: Schnell ein VPN aufsetzen . Es geht zwar nicht um die Vermeidung der VDS, aber das Prinzip ist das gleiche. Aber wenn Ihr sowieso schon einen eigenen Server habt, laßt den das DNS Cache übernehmen.

Wieso ist das nicht effektiv ?

Ein DNS Cache macht nur dann Sinn, wenn viele Klienten in einem Netzwerk das Cache benutzen, denn der eigentliche Sinn ist, daß nicht jeder Rechner die Root-DNS kontaktiert, sondern das man möglichst viele Anfragen lokal selbst beantworten kann, weil man bereits einmal danach gefragt hat. Das geht zum einen schneller, zum anderen spart es Traffic ein. Das man seinen Fußabdruck dabei kleiner hält, fällt praktischerweise nebenbei ab. Je mehr einen DNS Cache benutzen, desto mehr gehen auch die eigenen Anfragen in der Masse unter.

Methode 2:

Ein Script, daß laufend die /etc/resolv.conf  neu und die DNS Servernamen in der Reihenfolge zufällig hinein schreibt, ist mit ein bisschen Bash-Foo machbar. Dauer ca. 15 Minuten.

Methode 3:

Schauen wir uns mal die /etc/resolv.conf an, finden wir dort:

; generated by /usr/sbin/dhclient-script
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Wenn man nichts weiter auf seinem Rechner installiert hat, wird in genau dieser Reihenfolge ein DNS nach dem Anderen abgefragt, wenn der vorherige DNS nicht rechtzeitig antwortet.

Das Verhalten kann man aber ändern:

options rotate
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Jetzt würde ein entsprechend gut programmierter Resolver, das ist der Programmteil, der die DNS Auflösung macht, zufällig aussuchen, welchen der DNS er benutzt. Trägt man hier also viele öffentliche DNS Server in dieser Liste ein, verteilt man alle DNS Anfragen auf diese Server, was jedem einzelnen logischerweise die Möglichkeit nimmt, ein umfangreiches Profil zu erstellen.

Dummerweise juckt diese Anweisung kaum einen Resolver. Das geht sogar soweit, daß der erste in der Liste mal einfach überlesen wird 🙂 Also muß eine Lösung her, die diese Anweisung respektiert: NSCD

dnf install nscd
systemctl start nscd
systemctl enable nscd

Ab jetzt werden DNS Abfragen über den NameserverCacheDämonen abgewickelt, und der fragt zufällig die DNS in der Liste an. Da es sich auch um einen Cache handelt, fragt er im Laufe der Zeit ( TTL eines Eintrags ) nur einmal die Rootserver an ( Kleiner Fußabdruck ) .

Damit wäre das Trackingproblem erledigt, wenn Ihr viele DNS Server zur Verfügung habt.

Einen eigenen DNS Cache auf dem PC zu betreiben, ist nicht weiter wild, man müßte nur den named installieren und starten. Da aber bei DNS Abfragen einiges unterwegs schief gehen kann, ist eine starke DNS Infrastruktur wie bei Google durchaus ein starker Partner.

Welche Methode für Euch die richtige ist, müßt Ihr wissen.