BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux und Android entdeckt. Bluetooth eingeschaltet zu haben, reicht aus um angreifbar zu sein.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux vor Kernel 5.9 entdeckt. Der Fix wurde am 29.9. bereits heimlich in einen Kernel Branch eingepflegt und wartet seitdem auf den Merge in den Hauptkernel. Erst für Kernel 5.9 war das der Fall, so daß derzeit alle Geräte die mit Linux angreifbar sind, bis auch dort Backportpatche verfügbar sind.

Gefunden hatten diese Lücken Intel ( „Intel – wie konnte das passieren, die finden doch sonst nichts“ )  und Google. Bei Google kann ich das verstehen, die verdienen damit Geld, aber Intel? 😉

Also RCE, Remote Code Execution, und das auch noch ohne Anmeldung. Meint: Jedes Gerät mit aktiviertem Bluetooth in der Nähe ist angreifbar, nur weil es da ist. BleedingTooth ist dabei nicht nur eine Lücke, sondern ein ganzes Sammelsurium an Schwachstellen, die kombiniert, den RCE mit Privilegien Eskalation erlauben.

Bis auf weiteres: BlueTooth abschalten!

Quellen:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq  ( Die erlaubt die Code Ausführung )

 

RCE: 68.8< Firefox Mobile <80.x Schwachstelle

Es ist vielleicht nicht das schlechteste, daß Mozilla seine Leute rausgekantet hat, denn je weniger da arbeiten, desto weniger können so richtig tief in die Scheiße greifen 🙁

RCE: 68.8< Firefox Mobile <80.x Schwachstelle

Wie gestern Abend von den Hacker News  berichtet wurde, gibt es im FireFox Mobile eine so gravierende Sicherheitslücke, daß sich einem die Fußnägel aufrollen. Wenn man mit einem FF M < Version 80 gemeinsam in einem WLAN oder anderen Netz ist, kann man dem Firefox eine Nachricht senden, und er führt das direkt aus: Eine Remote Code Execution Schwachstelle.Die Schwachstelle wurde im FireFox Mobile 80 für Android gefixt.

Hinweis: In einem FF Mobile 68.8 konnte das Verhalten, trotz absichtlicher Aktivierung des Features nicht reproduziert werden.

FireFox sendet SSDP Pakete ins Netz um Geräte zu finden, die man als Screencast verwenden kann. Das wäre a) der Job vom OS und b) nicht so schlimm, wenn man das Ergebnis, das einem unaufgefordert jeder im Netz senden kann, mal auf SINNVOLLE Werte prüfen würde, statt es BLIND auszuführen.

Über so einen Intent kann man auch Addons oder andere Apps Installieren’und natürlich auch Webseiten mit Exploits besuchen, das macht es so gefährlich.

Kleines Demo gefällig?

Dies Video stammt von Gitlab-Account des Red Teams:

Wer sich mit Android Programmierung nicht auskennt, ein „Intent“ ist eine Anfrage von App A an (meistens) alle anderen Apps, ob die mit dem Inhalt was anfangen können. So brauche ich bspw. als Browser keinen Videoplayer integrieren, weil das eine andere App vermutlich viel besser kann als ich.

Aber selbstverständlich nehme ich als Anwendung dazu keine Infos, die selbst von einer dubiosen anderen Stelle im Netz bekommen habe, sondern leite da nur Sachen hin, die „ich selbst“ erstellt oder runtergeladen habe vom Ziel.

So ein Verhalten ist grob fahrlässig und eines Anfängers ohne Security Schulung würdig, aber doch nicht den Entwicklern eines Marken-Browsers.

Fußnote

NetFlix Mobile scheint auch per SSDP nach Sachen zu suchen, aber ob die Entwickler den gleichen dicken Bug eingebaut haben, ist nicht bekannt. Wer selbst nachsehen will, soltle in seinem WLAN mal das hier starten: „sudo tcpdump -A -n not tcp and not icmp and port ssdp“

SSDP ist das Simple Service Discovery Protocol und gehört als UDP basiertem Dienst zum UPnP, den Universal Plug & Play. Diese ganzen Autodetect Sachen sind als Funktion ganz nett, aber führen immer mal wieder zu Schwachstellen. Per UPnP kann man z.b. als Programm der Firewall sagen, daß man gern ein Loch haben würde für seinen Dienst, ohne das der Firewall-Admin was davon mitbekommt. Wird oft von Instant-Messengern benutzt um durch die DSL-Router zu kommen.

Schwachstellen im Apache Webserver < 2.4.44

Wer Apache als Webserver einsetzt, sollte jetzt aufpassen, denn wir haben jeweils eine  RCE und eine DOS Schwachstelle.

Schwachstellen im Apache Webserver < 2.4.44

In Apache wurden drei Schwachstellen identifiziert und im August behoben. Leider hat man u.a. bei Fedora vergessen, das publik zu machen, deswegen hier die Erinnerung für Euch:

Im HTTP2 Modul sind zwei Schwachstellen enthalten, die zum Crash führen und damit als DOS (Denial of Service) gelten:

important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Beide Schwachstellen kann man auch per Konfigurationsänderung abwehren, falls man keine gepatchten Webserver bekommen kann, oder noch nicht hat:

Je nachdem was Ihr für eine Distro habt, wird HTTP2 an verschiedenen Stellen aktiviert. Bei Fedora bietet sich an, eine eigene kleine Config in conf.modules.d/ anzulegen. In die Datei kommen zwei Einträge:

99-mitigate-http2.conf:

H2Push off
LogLevel warn mod_http2.c:error

Dann mit „systemctl httpd restart“ den Server neustarten. Die erste Anweisung behebt die 2020-9490 und die zweite sagt dem HTTP2 Modul, es soll nur kritische Sachen loggen, anstatt auch Warnungen. Das ist wichtig, da Angreifer über einen provozierten Fehler den Logging-Pool der Prozesse stören können und das führt dann zum Crash, was aber nur geht, wenn der Fehler auch geloggt wird.

moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)

Wer mit dem WebSocket Proxy uwsgi arbeitet, der muß updaten, eine Mitigation der möglichen Remote-Code-Schwachstelle ist nicht möglich. Bis zum Update kann man das Modul auch abschalten:

Für Fedora wäre das hier in conf.modules.d/00-proxy.conf:

# LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

Einfach ein # vor die Ladeanweisung und den Webserver mit „systemctl httpd restart“ neustarten. Natürlich funktionieren die Proxy Tunnel, die auf „uwsgi:://server:port/uri“ lauten, dann nicht mehr. Habt Ihr noch einen vhost konfiguriert, der das benutzen möchte, wird der Start des Webservers nicht funktionieren.

Updates vorhanden

Updates auf die 2.4.46 liegen für Fedora bereit. Für alle, die Ihre Server per Autoupdate versorgen, hat sich das Problem damit bereits erledigt.