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

Exim: TLS Protokollnamen haben sich geändert

Heute habe ich ein kleines exotisches Problem aus der Exim Welt für Euch, aus dem Ihr auch ohne Exim was lernen könnt.

Exim: TLS Protokollnamen haben sich geändert

Im Exim gibt es die Variable $tls_cipher. In dieser steht das TLS Protokoll drin,  auf welches sich die beteiligten Mailserver geeinigt haben. Rund eine Woche vor Exim 4.93 wurde „noch schnell“ ein Patch zur Standardisierung von SSL/TLS-Protokollnamen in das kommende Release (4.93) eingefügt. Leider war das eher unüberlegt, denn es wurde vergessen diesen Wechsel der Namen im ChangeLog von Exim 4.93 bekannt zu geben.

Nun setzten wir dies tatsächlich in einer ACL ein:

deny condition = ${if eq{${substr_0_7:$tls_cipher}}{TLSv1.2} {0}{1}}

Was dazu geführt hat, daß beim Wechsel auf Fedora 31 und in Folge auf Exim 4.94 die Config anpassen mußten:

deny condition = ${if eq{${substr_0_6:$tls_cipher}}{TLS1.2} {0}{1}}

Da diese Änderung nicht dokumentiert wurde, kam es nach dem Upgrade zu einer Störung des Mailverkehrs. Das möchte man natürlich vermeiden und deswegen liest ein Admin die Changelogs durch. Nutzte hier nur nichts.

Nehmt daher für Eure Projekte zwei Sachen mit:

1. Alles was zu Änderungen von Ausgaben und Variableninhalten führt, muß von Euch kommuniziert werden, sonst => Problem mit Nutzern.

2. „Testen! Testen! Testen!“

 

Ein Args für netstat

Wenn Dinge nicht so funktionieren, wie sie sollten, dann liegt das oft daran, daß falsche Entscheidungen getroffen wurden. Bei dieser Entscheidung geht es um netstat und IPv6.

Ein „Args!“ für netstat

netstat zeigt einem die Verbindungen, Sockets und Ports an, die auf einem Linux PC verfügbar sind. Solange es dabei um TCP und IPv4 Adressen geht, ist alles ok. Wenn man aber ein Problem mit einer IPv6 Adresse hat, dann sollte man sich informieren, weil netstat dummerweise IPv6 Adressen unvollständig anzeigt… ohne Warnung übrigens.

Nun würde man ja annehmen, daß ein „man netstat“ alles wissenswerte zu den Optionen von netstat anzeigt, oder? Tja, Pech gehabt liebe deutschsprechende Gemeinde, Ihr seid leider am Allerwertesten 🙂

BESCHREIBUNG
Netstat zeigt Informationen des Linux Netzwerkssystems an.

Bitte beachten Sie, dass der Inhalt der deutschen man-page nicht vollständig ist,im Moment.

„nicht vollständig“ ist eine leichte Untertreibung und dieser „Moment“ hält auch schon seit 2007 an 🙁 Tief durchatmen. Es gibt ja noch eine englische Originalversion. Aber wie kommt man da ran? Fragen wir doch mal „man man“ dazu …

Handbuchseiten finden
-L Locale, –locale=Locale
man wird in der Regel Ihre aktuelle Locale durch einen Aufruf der C-Funktion setlocale(3) bestimmen, welche verschiedene Umgebungsvariablen auswertet (darunter sind eventuell auch $LC_MESSAGES und $LANG). Um den ermittelten Wert vorübergehend außer
Kraft zu setzen, können Sie man mit dieser Option eine Locale vorgeben. Beachten Sie, dass dieser Wert erst wirksam wird, wenn die Suche tatsächlich beginnt. Programm-Meldungen wie Hilfe-Nachrichten werden immer in der zu Anfang ermittelten Locale
angezeigt werden.

Also tun mir mal, was da exemplarisch nicht steht: „man -L EN_en.UTF8 netstat“ und plötzlich haben wir Zugriff auf alle Infos zu allen Optionen, die in der deutschen Version nicht mal angedeutet wurden. Wer auch immer das übersetzt und dann auf die Deutschen losgelassen hat, mochte uns wohl nicht.

Zurück zum Problem: Die IPv6 Adressen werden abgeschnitten

Lösung:

–wide, -W
Do not truncate IP addresses by using output as wide as needed. This is optional for now to not break existing scripts.

Nun, die Begründung verschlägt einem ja praktisch die Sprache. Da IPv4 Adressen nicht verkürzt werden müssen, sieht man den Bug selten, bis man mal IPv6 braucht. Wer sein Script aber ohne IPv6 Support gebaut hat, der kann mit der Ausgabezeile eh nichts anfangen, weil da dann zu viele „:“und zu wenige „.“ in den IPs drin sind. Vorhandene Scripts stolpern also vermutlich sowieso über IPv6, da hätte man die IPs auch komplett ausgeben können.

Noch cleverer wärs gewesen, die Ausgabe wie „less“ oder „vim“ erzeugen zu lassen, die scrollen einfach nach rechts, wenn man die Cursorsteuertaste „->“ benutzt. Wenn man also keinen Platz mehr in einem 80-Spalten Terminal hat, dann macht man sich halt welchen, aber verkürzt sicher nicht wichtige Informationen.

Warum man nicht ss benutzt?

„ss“ ist der „Nachfolger“ von netstat, aber IMHO, und mit der stehe ich wohl nicht ganz alleine dar, ist die Ausgabe von ss unverhältnismäßig unübersichtlich :

Beispiel:

$ ss -6 -t -p

ESTAB 0 0 [::ffff:127.0.0.1]:58772 [::ffff:127.0.0.1]:mysql users:((„java“,pid=1525,fd=59))

$ netstat -lnapW

tcp6 0 0 127.0.0.1:58772 127.0.0.1:3306 VERBUNDEN 1525/java

Was ist jetzt einfacher zu lesen? Es steht zwar das gleiche an Information zur Verfügung, aber es ist einfacher zu erfassen finde ich.