Nvidia: 2 Sicherheitslücken im Linux-Treiber

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed
Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967
GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Security: Angriff auf WPA2 möglich, wenn Broadcom&Cypress Chips im Spiel sind

Eine Meldung der Hacker News erfreut die Gemütslage von allen Admins weltweit: WPA2 + Broadcomships sind eine schlechte Kombination 🙁

Angriff auf WPA2 möglich, wenn Broadcom & Cypress Chips im Spiel sind

Die mit CVE-2019-15126 registrierte Schwachstelle mit dem Namen „Kr00k“ erlaubt es in Kombination mit dafür anfälligen Chips von Broadcom &  Crypress, die WLAN Verschlüsselung teilweise zu verhindern.

Das funktioiert so, daß ein Angreifer ohne überhaupt im Funktnetz zu sein, ständig Disassoziationen auszulöst, indem er Deauthentifizierungspakete an alle sendet. Das führt dazu, daß sich die Chips aus dem WLAN lösen und den WLAN Schlüssel intern auf NULL setzen. So weit wärs noch ok, aber nun senden anfällig Broadcom und Crypress Chips die Restpufferinhalt im Chipspeicher ohne die Verschlüsselung ans Ziel. Streng genommen verschlüsseln die die Daten mit 000000000000000000, was dann keine Verschlüsselung mehr ist. Ist also ein Bug in der Chipfirmware, weil die müßte den Puffer auch leeren, statt den Inhalt denn zu senden.

„Unsere Tests bestätigten, dass einige Client-Geräte von Amazon (Echo, Kindle), Apple (iPhone, iPad, MacBook), Google (Nexus), Samsung (Galaxy), Raspberry (Pi 3), Xiaomi (RedMi) sowie einige Zugangspunkte von Asus und Huawei für Kr00k anfällig sind“, so die ESET-Forscher.“ schreiben die Hacker News.

Diese Lücke hackt also nicht Eurer WLAN Passwort, weswegen ein Wechsel des Passworts nichts bringt. Da Broadcom Chips in allen möglichen Geräten zu finden sind und damit in allem was IoT, Accesspoints, alte Handies etc. ist ungepatcht laufen, wird das ein schöner Mitschmatsch werden.

Wie könnt Ihr euch schützen?

Das schlimmste was mit dem Angriff passiert ist, daß einige eurer Pakete im WLAN so übertragen werden, als wenn es ein OFFENES-WLAN wäre. Damit sind alle die Datenübertragungen betroffen, die Klartextverbindungen beinhalten, z.b. HTTP:// Traffic, FTP, SMTP, POP, IMAP, DNS und jede Menge IoT Geraffel. Wer seine Dienste alle mit TLS Verbindungen wie HTTPS, FTPS, SFTP, SCP, SSH, STARTTLS für SMTP, POP und IMAP schützt, muß sich keine Sorgen machen. Aber wer zu Hause intern von einem PC per Samba auf einen anderen PC zugreift, dessen Daten könnten damit abgelauscht werden.

Ein gezielter Angriff auf bestimmte Daten ist mit dem Angriff nicht möglich, der Angreifer weiß also nie was er da so bekommt, aber je mehr er mitschneidet, desto schlechter für Euch.

Wie bekomme ich raus, daß ich betroffen bin?

Für Eurer Linux braucht Ihr erstmal eine Version von „lshw„, also für Fedorabenutzer eingeben: „sudo dnf install -y lshw

Ihr werdet Rootrechte brauchen, also „sudo su“ eingeben. Mit „ip l“ bekommt Ihr Eure Interfacenamen heraus, „ifconfig“ würde es auch tun:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:76:1c:be:39:c8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 34:e6:ad:5d:18:ee brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:e7:5f:07 brd ff:ff:ff:ff:ff:ff

Wir brauchen das wlp3s0 WIFI Interface. Jetzt gebt Ihr „lshw | less“ ein und bekommt eine lange Liste mit Info zu Eurer Hardware. Den Befehl solltet Ihr Euch also merken, den braucht man häufiger mal. In der Ausgabe sucht Ihr nach Eurem Interfacenamen und stoßt so auf solch einen Block:

*-network
description: Wireless interface
product: Wireless 3160
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlp3s0
version: 83
serial: 34:e6:ad:5d:18:ee
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=5.2.18-100.fc29.x86_64 firmware=17.3216344376.0 ip=192.168.0.103 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:54 memory:c4000000-c4001fff

Entweder verrät es euch jetzt schon die Herstellerbezeichnung, hier Intel Corporation, oder der Drivername (hier iwlwifi) gibt den Chiphersteller preis. Wenn da BC drin vorkommt, war es ein Broadcom. Den Code für Crypress Chips kenne ich jetzt leider nicht auswendig, aber das findet Ihr vermutlich im Netz auf Linux-Wifi-Infoseiten.

Wie gehts weiter?

Apple soll wohl bereits Patches für seine Benutzer veröffentlicht haben. Wann die anderen patchbaren Systeme hinterher ziehen, bleibt offen. Für alles was IoT, oder mehr als 2 Jahre alte Accesspoints, Handies etc. kommt wohl jede Hilfe zu spät, da hilft nur entsorgen. Vorher würde ich aber einen Blick auf die Webseite meines Herstellers werfen, vielleicht gabs ja doch ein Gnadenupdate.

Quelle: https://thehackernews.com/2020/02/kr00k-wifi-encryption-flaw.html

Exim: neue mögliche RCE Schwachstelle gefunden

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉