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