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.

32 Sicherheitslücken in Chromium gefixt

Kleine Abschweifung in RHEL:

32 Sicherheitslücken in Chromium-Browser gefixt

Wie man einem Update aus dem RHEL Security Newsletter entnehmen kann, wurden im Chromiumbrowser 32 Sicherheitslücken in einem Rutsch gefixt. Da einige davon Pufferüberläufe waren, sollte man umgehend updaten, auch wenn man nicht bei RHEL ist, da hier typischerweise RCE Lücken schlummern können, sprich:  Jemand kann aus der Ferne Code ausführen. Das bedeutet nicht, daß es so ist, aber i.d.R.  ist das eine Grundvoraussetzung dafür.  Für drei habe ich die Bewertung mal rausgesucht, wer selbst mehr wissen will, kann die  CVE Nummer einfach bei Google eingeben und landet dann hier:

https://nvd.nist.gov/vuln/detail/CVE-2020-6513

Einfach die Nummer am Ende mit der gewünschten ersetzen und man bekommt auch diese Info.

Security Fix(es):

* chromium-browser: Heap buffer overflow in background fetch (CVE-2020-6510) (Score: 7.8 )
* chromium-browser: Side-channel information leakage in content security policy (CVE-2020-6511) (Score: 6.5)
* chromium-browser: Type Confusion in V8 (CVE-2020-6512)
* chromium-browser: Heap buffer overflow in PDFium (CVE-2020-6513) (Score: 8.8)
* chromium-browser: Inappropriate implementation in WebRTC (CVE-2020-6514)
* chromium-browser: Use after free in tab strip (CVE-2020-6515)
* chromium-browser: Policy bypass in CORS (CVE-2020-6516)
* chromium-browser: Heap buffer overflow in history (CVE-2020-6517)
* chromium-browser: Use after free in SCTP (CVE-2020-6532)
* chromium-browser: Type Confusion in V8 (CVE-2020-6537)
* chromium-browser: Inappropriate implementation in WebView (CVE-2020-6538)
* chromium-browser: Use after free in CSS (CVE-2020-6539)
* chromium-browser: Heap buffer overflow in Skia (CVE-2020-6540)
* chromium-browser: Use after free in WebUSB (CVE-2020-6541)
* chromium-browser: Use after free in developer tools (CVE-2020-6518)
* chromium-browser: Policy bypass in CSP (CVE-2020-6519)
* chromium-browser: Heap buffer overflow in Skia (CVE-2020-6520)
* chromium-browser: Side-channel information leakage in autofill (CVE-2020-6521)
* chromium-browser: Inappropriate implementation in external protocol handlers (CVE-2020-6522)
* chromium-browser: Out of bounds write in Skia (CVE-2020-6523)
* chromium-browser: Heap buffer overflow in WebAudio (CVE-2020-6524)
* chromium-browser: Heap buffer overflow in Skia (CVE-2020-6525)
* chromium-browser: Inappropriate implementation in iframe sandbox (CVE-2020-6526)
* chromium-browser: Insufficient policy enforcement in CSP (CVE-2020-6527)
* chromium-browser: Incorrect security UI in basic auth (CVE-2020-6528)
* chromium-browser: Inappropriate implementation in WebRTC (CVE-2020-6529)
* chromium-browser: Out of bounds memory access in developer tools (CVE-2020-6530)
* chromium-browser: Side-channel information leakage in scroll to text (CVE-2020-6531)
* chromium-browser: Type Confusion in V8 (CVE-2020-6533)
* chromium-browser: Heap buffer overflow in WebRTC (CVE-2020-6534)
* chromium-browser: Insufficient data validation in WebUI (CVE-2020-6535)
* chromium-browser: Incorrect security UI in PWAs (CVE-2020-6536)

Für Fedora steht dieses Update leider noch aus, da Chromium-Freeworld von RPMFusion kommt und „chromium“, was aus dem Fedora Repo kommt, vom Maintainer noch nicht gebaut wurde. Ich hab die mal beide angestupst, mal sehen was passiert 😉

CoronaChroniken: Corona-App öffnet Angriffen Tür und Tor

Liebe Kasernierte,

da nächste Woche die Corona-App der Bundesregierung (offiziell) lanciert werden soll, ist es Zeit da mal vor zu warnen.

CoronaChroniken: Corona-App öffnet Angriffen Tür und Tor

Solche Grafiken sind die beste Argumentationshilfe überhaupt.

Kommen wir zur Corona-App:

„Wenn wir in den kommenden Wochen einige Millionen Bürger von der App überzeugen, dann bin ich schon zufrieden“ (Jens Spahn).

Ich vermute, daß es dazu nicht kommen wird, denn die App schaltet dauerhaft Bluetooth ein. Bluetooth ist bekannt dafür den Akkustand zu drücken, denn anders als sonst, wird Bluetooth auch wirklich benutzt, um aktiv nach anderen Coronakennungen zu suchen. Das dürfte schon ohne weitere Informationen zum Thema dafür sorgen, daß es aus vielen Handies nach einigen Tagen wieder entfernt wird.

Diese Art der Selbsthygiene ist auch dringend nötig, denn Bluetooth hat eine Sicherheitslücke, die auf nahezu allen bislang gebauten Geräten vorhanden ist:

Managed to reproduce BIAS (Bluetooth Impersonation Attack) CVE 2020-10135.
Impersonation of any previously paired and connected Bluetooth device in
vulnerable setup. Reproduction on Linux host and Samsung S3 Neo+ mobile.

More info in the repo:
https://github.com/marcinguy/CVE-2020-10135-BIAS

Diese Lücke kam erst vor wenigen Tagen ans Licht. Kurz gesagt, jeder kann einem verwundbarem Geräte(so ziemlich alles was Android fährt) vorgaukeln ein anderes, früher bereits gepairtes Gerät zu sein. Je nachdem welche App dann mit Daten versorgt wird, kann der Angreifer von da an prinzipbedingt weitere Schwachstellen in Prozessen exploiten, von der offensichtlichen Lücke, sich z.B. als Lautsprecher auszugeben und Audio abzugreifen ganz zu schweigen.

Und diese Lücke ist nur eine von vielen, die ungepatcht durch die Handyhersteller, auf alten Geräten warten.

A.d.R. wer mit BT Kopfhörern rumrennt, wird von den CVEs nichts mitbekommen, bis seine Wiedergabeliste so merkwürdige Einträge enthalten wird.

Merke:

Bluetooth ist auf alten Geräten eine komplette Sicherheitslücke und gehört abgeschaltet!

Da wären z.B. noch CVE-2020-0022, eine Lücke mit der man durch Bluetooth Pings an Teile des Hauptspeichers kommt, weil es da wohl an Sanitychecks mangelt. Stichwort: negative memcpy-Länge args!

Das ist zwar im aktuellen Android durch Google gefixt worden, aber wieviele Handies haben das schon und wieviele mehr werden diesen Patch nie sehen, weil sie noch AOS 4,5,6,7 fahren? Die völlig verkappte Updatepolitik von Google und den Handyherstellern sorgt für unsichere Geräte. Was war so schwierig daran, die Treiber per OTA zu updaten ohne gleich Kernelreinstalls zu machen? {Irgendeine Gottheit} sei dank, wird sich das ja jetzt mit den reinen Linuxsmartphones beheben. Android kommt mir jedenfalls nicht mehr auf irgendwelche Geräte.

In 2019 hatten wir dann noch diese lustige Lücke, wo man durch gezielte Pakete die Verschlüsselung von Verbindungen bis auf NSA Niveau erniedrigen konnte:

https://arstechnica.com/information-technology/2019/08/new-attack-exploiting-serious-bluetooth-weakness-can-intercept-sensitive-data/

Auch die ist in AOS 4,5,6,7 nicht behoben worden.

Welchen Grund sollte man also haben, einen Chip mit Strom zu versorgen, der bestenfalls nur den Akku schnell entleert, aber schlimmstenfalls das Gerät kapern lässt? Der informierte Leser hat jedenfalls keinen.

Das waren die Rahmenbedingungen unter denen eine Corona-App laufen soll, kommen wir zum Knackpunkt der Sache: die App selbst.

Die zentrale dezentrale Lösung der Bundesregierung

Versprochen hatte man uns die dezentrale Lösung, also alle Daten auf den Smartphones und keinen zentralen Server. Bekommt habt Ihr jetzt: viele Daten auf dem Smartphone und … einen Zentralserver von dem sich Euer Handy eine Liste mit Kennungen zum Abgleich mit Euren lokalen Daten zieht. Dazu muß aber regelmäßig nachgesehen werden, ob es da Updates gibt. Außerdem mußte eine Trollvermeidungsstelle eingerichtet werden bei der Telekom 😀

Wie regelmäßig der Datenabgleich ist, habe ich derzeit nicht zu Hand, aber zu lange Perioden werden es nicht sein, sonst wäre das nämlich komplett unsinnig. Eine Woche nach dem Infektionszeitpunkt brauche ich die Info nicht mehr, da liege ich schlimmstenfalls schon im Bett oder habe gemerkt, daß ich mich nicht angesteckt habe. Ergo wird das im Stundenbereich liegen.

Eine rein dezentrale Lösung konnte schon gar nicht sein, weil irgendwoher muß ja die Info kommen, wer infiziert gewesen ist. Selbst wenn die App einen Schalter hätte mit „Ich bin infiziert“ darauf und den Status im Signal mit ausstrahlen würde ( da fällt mir sofort der Judenstern ein ) , potentiell nutzt das anderen Menschen nichts, weil man sich halt nicht immer zweimal im Leben sieht. Daher war ein Zentralserver zwangsläufig immer mit im Spiel.

Andere Zentralserverlösung nutzt Ihr übrigens auch laufend:

WhatApps, Facebook, Twitter, Wetterdienste, News- und Rss-Feeds usw.

Da gibt es nur einen Unterschied: die kommen nicht so leicht an Namen zu (Mobilfunk-)IPs. Gut, Facebook wird das auch nicht müssen, Ihr habt Ihnen ja schliesslich gesagt, wer Ihr seid 😉 Aber denkt mal drüber nach, wer so alles weiß, daß Ihr jetzt gerade in der Stadt rumrennt oder zur Ostsee fahrt. Wie gut die GEO-Locationdatenbanken heutzutage sind, ist echt erschreckend.

Corona-App öffnet Angriffen Tür und Tor

Nun hatte der Artikel die Überschrift, daß die Corona-App Angriffen Tür und Tor öffnet und damit sind nicht die Trollangriffe gemeint, die eine Infektion nur vortäuschen und so alle Empfänger in der Nähe unnötig in den Coronatest stürzen.

Ich denke, die Lücken im BT sprechen für sich und da die Corona-App BT automatisch aktiviert, stimmt das so auch. Selbst wenn die Software nicht selbst auch noch für bislang unbekannte Angriffe genutzt werden kann, reicht die Sache mit dem BT schon von alleine aus um diesen Zwang abzulehnen, da der Nutzen ohnehin fraglich ist.

Wie man an den Grafiken sieht, ist die Zahl der Neuinfektionen pro Tag zwar nicht Null, aber praktisch kaum vorhanden. Es ist also schwierig überhaupt jemandem zu begegnen, der die Krankheit gerade verteilt. Von den jüngsten Pressemitteilungen ausgehend, wird die derzeit maßgeblich betroffene Gruppe auch diese App nie einsetzen, da sie sich schon den Tests verweigert hat, die nachsehen sollten, ob die überhaupt infiziert sind.

Wenn man den Horizont seiner Blasengruppe nicht verlässt, dann lernt man eben nichts neues dazu. Das hätte den Dinos auch mal rechtzeitig jemand sagen sollen, bevor sie ausgestorben sind.

PS: unsere diesjährig direkt im Baum neben dem Schlafzimmer ziemlich ortsfeste Dinogruppe namens „Krähenschwarm“ trat dann doch nach Beginn der Bauarbeiten den Rückzug an, was besonders morgens um 5 für Ruhe sorgte. Leider wars dann nach 6 Uhr nicht mehr so ruhig 🙁  Bauarbeiter sind echt alle gleich, mirgens um 6 Uhr 1h Lärm machen und dann den ganzen Tag ruhig sein, anstatt abends 1h Lärm zu machen und morgens dann die ruhigen Arbeiten zu erledigen.

Fedora 30: Firefox 72.0.1 im Koji bereit

Aufgrund mehrerer schwerer Sicherheitslücken in Firefox und dem Umstand, daß die Version 72.0 nicht funktioniert hat, gibt es für Fedora jetzt auch die 72.0.1 im Koji zum Download

schwere Sicherheitslücken in Firefox < 72.0

Es ist recht ungewöhnlich, gleich nach einer Security Release wie Firefox 72, noch eine Lücke zu fixen, aber hey, es muß wichtig gewesen sein und hier ist sie:

Security Vulnerabilities fixed in Firefox 72.0.1 and Firefox ESR 68.4.1

Announced      January 8, 2020
Impact critical
Fixed in Firefox 72.0.1 , Firefox ESR 68.4.1

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

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.

Den wichtigen Teil, habe ich Euch mal farblich hervorgehoben 😉 Zusammen mit dieser Lücke:

#CVE-2019-17025: Memory safety bugs fixed in Firefox 72

Reporter Mozilla developers
Impact high
Description

Mozilla developers Karl Tomlinson, Jason Kratzer, Tyson Smith, Jon Coppeard, and Christian Holler reported memory safety bugs present in Firefox 71. 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.

ein Grund mehr sofort zu updaten!

Hier könnt Ihr die aktuelle Version für Euch passend herunterladen, da der Stablepush noch nicht durchgeführt wurde:

F30x32: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc30/i686/firefox-72.0.1-1.fc30.i686.rpm

F30x64: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc30/x86_64/firefox-72.0.1-1.fc30.x86_64.rpm

F31x32: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc31/i686/firefox-72.0.1-1.fc31.i686.rpm

F31x64: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc31/x86_64/firefox-72.0.1-1.fc31.x86_64.rpm

Fedora – ClamAV 0.99.3 installieren

Es kam gestern doch sehr überraschend in den Medien, daß ClamAV ein Rudel Schwachstellen hat und auf keinem normalen Weg wurde darüber informiert. Es gab weder eine Meldung über die CERTs, noch auf der Redhat Security Mailingliste. Die Schwachstelle ist so gravierend, daß auf unserer Serverfarm sämtliche ClamAVds bis zum Patch deaktiviert wurden.

Abhilfe schaffen

Derzeit gibt es in de Repos noch keine gepatchte Version, obwohl Sie bereits zur Verfügung steht. Wer den Early-Alpha-Beta-Test mitmachen will, der findet die Pakete für Fedora hier : https://koji.fedoraproject.org/

Folgende Pakete solltet Ihr dann downloaden:

clamav
clamav-data
clamav-filesystem
clamav-lib
clamav-server
clamav-update

installiert wird das dann mit „rpm -Uv /pfad/zu/den/rpms/clam*rpm„. Fertig.

 

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 🙂