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.

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.