CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Nein, heute geht es nicht um Dichtung, eher um Undichtigkeiten in Betriebssystemen 😉

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Google’s Projekt Zero hat im Oktober eine Serie von kritischen Bugs offengelegt, mit deren Hilfe iOS, Android, Windows, Macs und Linuxsysteme übernommen werden konnten. Die Lücken sind so groß, daß Apple sogar noch Iphone 5s aktualisiert und die sind seit Jahren im End-of-Live.

Ein Blick auf eine dieser Lücken zeigte, daß diese auch für Linux vorhanden war, aber unter dem Radar bliebt: FreeType < 2.10.4

„Bug #1890210 – CVE-2020-15999 freetype: heap-based buffer overflow via malformed ttf files“

Red Hat hat dazu im Bugreport geschrieben:

„A flaw was found in freetype in the way it processes PNG images embedded into fonts. A crafted TTF file can lead to heap-based buffer overflow due to integer truncation in Load_SBit_Png function.“

Wer in den letzten Tagen die Updates verfolgt hat, weiß, daß es für Chrome, FireFox, Thunderbird eine schere Sicherheitslücke beim Webseitenaufruf gab. Über den Bug im FreeType, einer Font-Rendering-Engine, die auch und gerade in Webbrowsern genutzt wird, konnte mit Hilfe eines manipulierten Fontfiles, und da zählen auch WebFonts zu, das komplette System übernommen werden.

Diese Lücke betraf uns alle, und mit alle meine ich wirklich ALLE auf dem Planeten.

Wie kann eine so simple Sache wie einen Fontrendern, zu einer Systemübernahme führen? Das liegt daran, daß es sich hierbei wohl um den ersten Schritt in einer ganzen Exploitchain handelt. Hat man erstmal den Fuß im Chrome oder Firefox, muß man nur noch dort ausbrechen können und das war bei Chrome über einen Sandbox-Escape möglich. Danach findet sich im Kernel schon eine Schwachstelle, gerade bei Handies.

Von der Tragweite der Lücke mal abgesehen, rankt sich um die Google Veröffentlichung noch einiges andere. In der Szene munkelt man von „Spionagekram“, wozu auch paßt, daß keiner der Beteiligten dazu irgendwas sagen möchte. Nachdem der Exploit verbrannt ist, dürften die früheren Nutzer ziemlich sauer auf Google sein. Das Google uns aber nicht sagen kann, woher die Exploits stammen und wie Sie darauf aufmerksam wurden, spricht dafür, daß es ein „us-heimischer“ Dienst war, sonst wären die Antworten vermutlich anders. Aber, genaueres weiß man nicht, da keiner reden will.

Also feiert, daß ein Angriff weniger auf Euch möglich ist und wer von Euch Software schreibt, denkt bitte daran, wirklich sauber zu arbeiten, weil auch die unbedeutendste Lib einen immensen Schaden anrichten kann!

Google Chrome löscht sich selbst per Update

„Google ist dumm, wie Esel ist schlau“ würde unser Lieblings-Pseudo-Osteuropäer sagen, denn Google selbst hat Chrome per Update auf allen RPM basierten Linuxservern unabsichtlich entfernt.

Grund war ein falsch zusammengebautes RPM im Google Repository. Die Datei /usr/bin/google-chrome-stable fehlte im Update vom 2. September 2016 einfach. Lustigerweise ist das ausgerechnet die wichtigste 😉

Sep 02 09:11:48 INFO Upgraded: google-chrome-stable-53.0.2785.89-1.x86_64
Sep 02 09:11:49 INFO Cleanup: google-chrome-stable-52.0.2743.116-1.x86_64

# rpm -ql google-chrome-stable

/opt/google/chrome/xdg-mime

/opt/google/chrome/xdg-settings
/usr/bin/google-chrome
/usr/share/applications/google-chrome.desktop
/usr/share/gnome-control-center/default-apps/google-chrome.xml
/usr/share/man/man1/google-chrome.1

Mit dem heutigen Update google-chrome-stable-53.0.2785.92-1.x86_64.rpm kam die Datei dann wieder auf die Computer drauf 🙂

Ursache für den Fehler dürfte eine neue Directoyhierarchie sein, die aus dem Binary einen Link gemacht hat:

0 lrwxrwxrwx. 1 root root   31  3. Sep 20:54 /usr/bin/google-chrome -> /etc/alternatives/google-chrome
0 lrwxrwxrwx. 1 root root   29  3. Sep 20:54 /etc/alternatives/google-chrome -> /usr/bin/google-chrome-stable

0 lrwxrwxrwx. 1 root root   32  2. Sep 01:20 /usr/bin/google-chrome-stable -> /opt/google/chrome/google-chrome
4 -rwxr-xr-x. 1 root root 2112  2. Sep 01:20 /opt/google/chrome/google-chrome

Update: 6.9..2016

Heute kam dann der Grund für das wohl überhastete Update :

Am 1. 9. 2016 gab es Advisories für Chrom und Chromium, die eine echt krasse Sicherheitslücke im Browser offenbaren:

Mehrere Schwachstellen in Google Chrome vor Version 53.0.2785.89 auf Windows,
Mac OS X und Linux Systemen ermöglichen einem entfernten, nicht
authentifizierten Angreifer das Ausführen beliebigen Programmcodes, Umgehen
von Sicherheitsvorkehrungen, Darstellen falscher Informationen, Durchführen
von Cross-Site-Scripting (XSS)-, Universal-Cross-Site-Scripting (UXSS)- und
Denial-of-Service (DoS)-Angriffen sowie weitere nicht spezifizierte Angriffe.

In dem Licht betrachtet, könnte es auch Absicht gewesen sein, die Browser zu deaktivieren und die User zu schützen.

Tracking über Browser API des Batteriestatuses

Wie die Webseite TheHackernews.com heute berichtet, ist es Forschern der Standford University bereits in 2015 gelungen, einen Super-Super-Cookie zu nutzen, in dem sie über die Browser API der mobilen Versionen von Chrome, Opera und Firefox den Batteriestatus abgefragt haben. Durch die Kombination von angezeigter „verbleibender Zeit in Sekunden“ und dem Prozentwert der Ladung, ergeben sich bis zu 14 Millionen Kombinationen, die man Geräten zu ordnen kann.

Steve Engelhard and Arvind Narayanan von der Princeton University, konnten nun in einem Forschungsbericht  zeigen, daß diese Technik bereits von Webseiten zum aktiven Tracken von Benutzern eingesetzt wird.

Zusammen mit anderen Techniken wird es damit immer schwerer dem Online-Tracking zu entgehen. Aber natürlich kann man etwas dagegen tun, denn auch für FireFox Mobile gibt es Noscript!  Ohne Javascript kann man Browser-Api’s nicht abfragen, was dazu führt, daß man nur ohne Javascript surfen muß.

Sollte man jetzt glauben, den Webseitenbetreibern ginge nur ums das reine Tracking dabei, weit gefehlt, daß ist nur zur Verbesserung der Identifikationsrate da, denn Tracking geht über sehr viele Browsermerkmale bereits gut ( mit Javascript).

Den Batteriestatus zu kennen, verleitet Verkäufer jetzt aber dazu, abhängig vom Stand die Preise zu ändern. Der Gedanke: „Der User ist unter Stress, weil seine Batterie bald schlapp macht und daher kauft er jetzt sofort das Erstbeste zum erstbesten Preis. Suchen bei der Konkurrenz kommen wegen des Batteriestandes nicht mehr in Frage. “

Damit könnte der Verkäufer sogar recht haben. Also, was heißt das ? Bei FireFox Javascript abschalten und gleichzeitig eine neue Kampagne starten, diese API zu begraben! Das man Chrome dazu bewegen kann, ist eher unwahrscheinlich. Google lebt ja vom Tracking anderer Leute 😉

Referenzen:

INRIA Privatics Forschungsbericht
Lukas Olejnik Blog
Random Walker – OpenWPM

Quelle: thehackernews.com