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

Samsung: geplante Obsoleszenz oder Hack?

Der Fall hat das Potential zum PR-Desaster des Jahres zu werden: Samsung’s BlueRay-Player geben seit dem 18.6. 2020 reihenweise den Geist auf.

Samsung: geplante Obsoleszenz oder Hack?

Wenn man den Benutzerberichten im Samsungforum USA glaubt, dann schalten sich die BlueRay-Player ein und nach 3 Sekunden reseten sie wieder. Angefangen hat dies am 18.6. 2020 . Für eine fehlgeleitete geplante Obsoleszenz spricht, daß auch Reservegeräte von Kunden betroffen sind, die noch nie am Netz hingen und folglich auch kein Update bekommen haben können.

Andere Beiträge im Forum verlinken auf diesen Forbes Artikel:

Genius Hackers hijack Oxford University tech for masterpiece attack on Microsoft users

Dieser trägt das Datum vom 18.6. und berichtet von einem Hackangriff auf eine alte Kampangienseite von Samsungs-Canada, die über Mailserver der Oxford Universität versendet wurde. Da es sich um valide Adressen mit passenden DNS Einträge, Zertifikaten und anderen intakten Sicherheitsmerkmalen handelt, greifen z.b. bei Microsoft einige Antispamfilter nicht ein. Das erklärt dann auch das primäre Ziel der Hacker: Microsoft 365 Benutzer.

Ich vermute, daß diese Vorfälle nicht zusammen hängen und nur zufällig am gleichen Tag publik wurden. Daher gehe ich auch von einem Obsoleszenzdesaster bei Samsungs aus. Wie sollte man sonst Umsätze erschaffen, wenn die Consumerelektronik heute schon 5-10 Jahre hält?

Viel spannender ist die Frage, ob es sich hier um einen massiven Angriff aus dem IoT – Bug des Jahres „Ripple20“ handelt und diese Benutzer großflächig angegriffen und ausgenockt wurden. Wieso allerdings ein Fernseher oder BlueRay-Player via UPNP einen Serverport auf dem DSL-Router aufmachen sollte, über den er dann gehackt werden kann, aber sonst keine Funktion hat, ergibt auch irgendwie keinen Sinn. So ein Port wäre zwangsweise nötig, weil man ja erst durch den Router durch und dann zum Gerät muß. Jetzt kenne ich die US-Situation zum Anschluss von Endkunden ans Netz nicht, vielleicht sind deren Plasterouter noch schlechter als unsere.

Diese Player können übrigens auch Live-Streams anzeigen, was die wohl sehr beliebt gemacht hat. Ich bin gespannt wie Samsung das lösen will, wo die Geräte nicht mehr länger als 3 Sekunden am Stück laufen 🙂

Zum PR-Desaster wird das übrigens werden, wenn es mehr solcher Antworten des hauseigenen Samsung Moderator-BOTS(!) auf Meldungen wie diesen zu Geräten, die aufgrund Ihres Namens nicht in den USA vertrieben werden, aber trotzdem Defekte aufweisen, gibt:


Samsung Moderator

{…}

This forum is for the support of US products and customers. As your product is a non-US model and support for these models is very limited, please seek a support team for your area. You can do so by using this link: http://www.samsung.com/visitcountry  Thanks!

(Quelle: https://us.community.samsung.com/ )

Nachschlag:

Ein Nutzer schreibt:

Re: Blu-ray player BD-JM57C, keeps cycling on/off whenever plugged in

I just tried the ‚email CEO‘ option on the Samsung website.  Guess what…I got an error!

was ja nicht verwundern sollte, der Samsung CEO sitzt vermutlich schon wieder im Knast 😉

2017: https://www.manager-magazin.de/unternehmen/personalien/samsung-jay-y-lee-muss-fuenf-jahre-ins-gefaengnis-a-1164486.html

2018: auf Bewährung entlassen..

2020:  https://www.gsmarena.com/prosecution_files_arrest_warrant_for_samsung_heir_again-news-43592.php

Update: 21.6.2020

Immer mehr Menschen melden sich mit unterschiedlichen Samsunggeräten, die alle die gleichen Bugs haben. Egal ok aus USA oder Europa.

1.Vermutung: Gleiche Basisfirmware mit Bug.
2.Vermutung: Nicht patchbar für Kunden.

Ich hatte ja angedeutet, daß das zum PR Desaster wird und wie es scheint, tut Samsung gerade alles um es dazu kommen zu lassen:

Keine Statements
Keine Hilfe
und die Moderator schreiben so vorgefertigte Blöcke wie: „Hier zur Lösung … “ und wenn man da da klickt kommt nichts. In einem 80 Seiten langen Threat landet man auf Seite 40 und das wars dann.  Es folgt der übliche Murks eines Communitymanagerbots:

„SamsungSabrina:

Re: Blu-ray player BD-JM57C, keeps cycling on/off whenever plugged in

We are aware of customers who have reported an issue with boot loops on some Blu-Ray players and we are looking into this further. We will post an update here on this thread when we have more information.

 

Be sure to click “ ✓ Accept as Solution“ when you find an answer that works for you.“

Quelle: https://us.community.samsung.com/t5/Home-Theater/Blu-ray-player-power-cycling-whenever-plugged-in/m-p/1282948#M14224
Ich an Eurer Stelle würde da nicht auf ACCEPT as Solution drücken, nachher erkennt Ihr an, daß Ihr gar kein Problem hattet 🙁  Aber ist klar, daß es das Problem wirklich gibt, bei 40 Seiten Beiträge innerhalb von einem Tag! Das ist so so gravierend, daß ich als Firmenchef mal langsam übers Abdanken nachdenken sollte, denn wenn da rauskommt, daß die Firmware das absichtlich macht, und da habe ich kaum Zweifel dran, dann mal gute Nacht.

Vollversagen bei OpenSSH: Is a directory

Nehmt es mir nicht übel, aber anders als ein komplettes Versagen auf ganzer Linie kann man den Fall bei OpenSSH nicht bezeichnen, zumal es um einen kleinen, aber sinnvollen Bugfix geht.

Vollversagen bei OpenSSH: „Is a directory“

Damit Ihr versteht um was es geht, müssen wir zurückreisen ins Jahr 2010. Damals wurde ein Bugreport im Bugtracker von OpenSSH veröffentlicht: https://bugzilla.mindrot.org/show_bug.cgi?id=1768

Von dem wußte ich aber nichts, als ich 2015 über das Problem gestolpert bin. Das Problem sieht wie folgt aus:

scp testdatei user@servername:/topdir/subdir/

Wenn es „subdir“ als Directory gibt, dann wird testdatei dahin kopiert und alles ist gut. Wenn es „subdir“ aber nicht gibt, dann würde man ja wohl erwarten, eine Fehlermeldung zu bekommen, aus der genau das hervorgeht, oder? Tja, wie soll ich sagen, ähm…nein!

Actual results:

scp: /usr/doesnotexist/: Is a directory

Wow.. oder? Das komplette Gegenteil von dem was man annehmen würde 🙂 Diese Aussage bekommt jeder, der sich OpenSSH selbst aus den original Sourcen kompiliert, denn, obwohl der Fehler schon 2010 gemeldet wurde und 2015 Jakub Jelen von Red Hat einen kompletten Patch geschrieben hat und das seit Fedora 20 und RHEL8 an alle „Nutzer“ in einem „Feldtest“ ausgerollt wurde, sieht sich das Projekt hinter OpenSSH nicht dazu in der Lage.

Eingeführt wurde der Bug übrigens um das Jahr 2005 herum. Damit sind es streng genommen schon 15 Jahre, die der Bug da vor sich hin dümpelt. Da ich Fedora nutze, habe  ich das Problem nicht mehr und viele andere Distros haben den RH Patch übernommen, aber traurig ist das schon, oder?

Leider mußte ich gerade feststellen, daß die neue Fehlermeldung auch nicht gerade viel besser als die alte ist:

scp: /tmp/ugdjkfh/: Not a directory

Das stimmt zwar inhaltlich, gibt aber den wahren Ursprung meiner Meinung nach nur unzureichend wieder 😉 Daher war ich mal so frei, Jakub darauf hinzuweisen, zumal ich den Bug da auch bei RH reportet hatte, vielleicht bekommt man nach 10 Jahren dann doch nochmal ein „Does not exist“ 😀 Wobei man als Server ja unterscheiden können muß zwischen „directory gibts nicht“ und „Du User, darfst da nicht reinschreiben“ unterscheiden wenn so eine Anfrage kommt, sonst könnte ein User niedriger Privilegierung die Verzeichnisstruktur einfach durchtesten. Ok, er könnte das viel einfach, wenn er eingeloggt wäre, aber ggf. hat der Account nur SFTP Zugang, ohne Interaktiven Shellzugang zu haben. Wäre ja denkbar.

Wie man sieht, doch nicht ganz trivial so eine saubere Fehlermeldung 😉

Wenn Ihr jemanden im OpenSSH Team kennt, könnt Ihr Ihn ja mal auf dieses Problem ansprechen. Übrigens erinnert mich das ganz stark an meinen Bugreport an ProFTP, weil deren 20 Jahre alte CHROOT Anweisung den Fall, daß da einer das Ziel per Symlink umgeleitet hat, nicht abgedeckt hatte. Das wurde auch Jahrelang geblockt bis es dann doch wer geschafft hatte, die Entwickler umzustimmen. Leider durfte ich mit dem 20 Jahre Bug-Jubiläumsvortrag nicht auf dem CCC sprechen. Dabei wollte ich nur son 15 Minuten Vortragsfenster im Nebenraum haben. Ich hatte denen sogar einen Patch für das Problem geschickt. Das wäre bestimmt lustig geworden, wenn die ProFTP Devs sich auf der Vortragsliste gesehen hätten 😀 Vielleicht packe ich Euch den Vortrag als PDF mal auf die Seite.