Spammer und Scammer drehen immer mehr ab

Heute morgen hatte ich eine merkwürdige Email im Kasten. Gut, das kommt öfters vor, manche davon haben sogar einen legitimen Inhalt, aber diese hier ist derzeit Platz #2 der Hitliste. Platz #1 ist übrigens die leere Spammail, die an tausend Empfänger ging 🙂

Spammer und Scammer drehen immer mehr ab

Schauen wir uns erstmal die Header an:

From: Orabelle Cadwell <orabellekbdcad@hotmail.com>
Date: Mon, 6 Jul 2020 12:03:20 +0000
Subject:  2017-05-27 00:27:08  csq2qvXHzJr

Keine Ahnung ob da jemand einen Kontakt von vor 3 Jahren wiederbeleben wollte, oder ob er sich dachte, daß Zufallsdaten immer ein Datum sein müssen , aber völlig unsinnig wird erst der Inhalt:

https://fksC6I jO1.arpa ,) $>< https://1fCIjOs6k .arpa ,) $>< https://fk1Osj 6CI.arpa ,) $>< https://1Ojs6fkC I.arpa = 09 ,) $>< https://kIs1O6Cj f.arpa ,) $>< https://OIskC 16jf. arpa ,) $>< https://1OjCI ksf6.arpa ,) $>< https://kIC6f js 1O.arpa ,) $>< https://jIks fC16O.arpa ,) $>< https:/ /s 6OfIj1kC.arpa ,) $>< https://1 O6sjfkIC.arpa ,) $>< h ttps://k1sIOjC f6.arpa ,) $>< https://kO1jfI sC6.arpa ,) $>< https://kjIs1Of 6C.arpa ,) $>< https://sf1kCIj 6O.arpa , ) $>< https://OC sk1I6fj.arpa ,) $>< https://6I jO1sfCk.arpa ,) $>< https://s jIk1C6fO.arpa ,) $>< https://6fksIOj1 C .arpa ,) $>< https://1CkI6O jfs.arpa ,) $>< https://Okjf I1 6sC.arpa ,) $>< https://jfI 1sCk6O.arpa ,) $>< https: //6IjOCf s1k.arpa ,) $>< https://jskIOfC16 .arpa ,) $>< https://skjfO1IC6 .arpa ,) $>< https://ksCI61j fO.arpa ,) $>< https://Cs6Ifk j1O.arpa ,) $>< https://6fO IjCk1s.arpa ,) $>< https://jfC16IO ks.arpa ,) $>< https://CsO 1Ifj6k.arpa ,) $>< https://fCsj1I6O k.arpa ,) $>< https://C6O1sf jk I.arpa ,) $>< https://16C OIkfjs.arpa ,) $>< https://Ijf 6sOk1C .arpa ,) $>< https://s6OCf1jk I.arpa ,) $>< https ://Isjk1O6f C.arpa ,) $>< https://Ij 16COfks.arpa ,) $>< https://1 jsCfIkO6.arpa ,) $>< https://6j O1CIfks.arpa ,) $> < https://6CIkfs j1O.arpa ,) $>

Wenn man mal davon absieht, daß es die .arpa Domain zwar gibt, diese aber ausschließlich für PTR Records, also IP zu Domainnamen Umwandlung, benutzt wird und es somit keine wie auch immer generierten Domain im klassischen Sinne gibt, mußte man den Inhalt erst doppelt von „quoted-printable“ zu „lesbar“  umwandeln, was kein Mailprogramm der Welt macht. Schlußfolgerung: Der Block, der übrigens mehrere KB lang ist, dient nur der Verwirrung der Antispamprogramme.

Jetzt wirds richtig wirr, weil den Block oben gab  es als ASCII-Block, als HTML-Block und als .. tada.. PDF-Block 😀 Da wollte jemand auf Nummer sicher gehen 😉

Ok, ich denke, die Mission isterfüllt: Alle sind verwirrt – Der Verfasser, das Antispamprogramm und die 2.500 Empfänger 😀

AVAST Schlangenöl, das Zweite diese Woche

Moin,

schaut mal was heute in die Mailbox gespült wurde:

30.06.2020____________________________________________________________________________________________________
Betroffene Systeme:
Avast Antivirus < free 20.4
AVG Technologies Anti-Virus < free 20.4
____________________________________________________________________________________________________
Zusammenfassung:
Ein lokaler Angreifer kann eine Schwachstelle in Avast Antivirus und AVG Technologies Anti-Virus 
ausnutzen, um seine Privilegien zu erhöhen.

und das war vor ein paar Tagen, am 25.6. : Es häufen sich die Bugs in AV Software

Da hatte es F-SECURE und BITDEFENDER erwischt. 2020 ist echt nicht das Jahr der Window AV Programme 😀

Es häufen sich die Bugs in AV Software

Das willst Du als Schlangenölbenutzer nicht hören:

Art der Meldung: Sicherheitshinweis
Risikostufe 3
Bitdefender Total Security: Schwachstelle ermöglicht Ausführen von beliebigem Programmcode mit den 
Rechten des Dienstes

25.06.2020____________________________________________________________________________________________________
Betroffene Systeme:
Bitdefender Total Security < 2020 24.0.20.116

Womit Sie ja in guter Gesellschaft sind:

Art der Meldung: Sicherheitshinweis
Risikostufe 2
F-Secure Linux Security: Mehrere Schwachstellen ermöglichen Umgehen von Sicherheitsvorkehrungen

19.05.2020____________________________________________________________________________________________________
Betroffene Systeme:
F-Secure Linux Security 11.00
F-Secure Linux Security 11.10

Und dann ist das auch noch für Linux .. args 🙁

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.

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.

Jitsi-Meet-Docker failed mit Cgroups2

Ich habe es bei FlatPak gesagt, ich habe es bei Snap gesagt, und ich sags bei Docker: Container sind Scheisse!

Jitsi-Meet-Docker failed mit Cgroups2

Die Jitsi-Meet-Docker Instanz hatte ja bereits am Anfang leichte Probleme: Das erste Update ging gründlich schief, weil es mit der selbst erstellten Laufzeitconfig nicht mehr zurecht kam. Ein komplettes „rm -rf“ war die Folge. Zum Glück lies es sich dann recht einfach reinstallieren. Die Folge war allerdings, daß es nachts abstürzte und per Cron restartet werden mußte.

Der Wechsel von Fedora 30 ( CGroups V1 ) auf Fedora 31 ( CGroups V2 ) hat dem Dockerimage dann den Rest gegeben. zwei der vier Server starten halt nicht mehr.

# ./update.sh
Removing docker-jitsi-meet_web_1 … done
Removing docker-jitsi-meet_prosody_1 … done
Removing network docker-jitsi-meet_meet.jitsi
Bereits aktuell.
Creating network „docker-jitsi-meet_meet.jitsi“ with the default driver
Creating docker-jitsi-meet_web_1 …
Creating docker-jitsi-meet_prosody_1 … error
Creating docker-jitsi-meet_web_1 … error
ERROR: for docker-jitsi-meet_prosody_1 Cannot start service prosody: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for docker-jitsi-meet_web_1 Cannot start service web: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for prosody Cannot start service prosody: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for web Cannot start service web: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown
ERROR: Encountered errors while bringing up the project.

Der resultierende Bugreport im GitHub wird seit dem ignoriert.

Die mangelnden Updates am den Basisimages, bzw. die Vorherschaft von Debianimages in den Containern führt wegen dem lahmen Updatezyklus von Debian und dem mangelnden Druck zu Updates durch die Containerhersteller, dann unweigerlich ins Nirvana.

Fazit: Man kann eben doch nicht einfach Container von A nach B und zwischen Osen verschieben wie man will.

Schweres Defizit im Dockersystem

Wie ich gerade feststellen muß, ist es nicht möglich in einen nicht laufenden Container zuwechseln. Das macht das Debuggen natürlich extrem toll, wenn man nicht mal die Logfiles auslesen kann!

# docker-compose ps
Name Command State Ports
——————————————————–
docker-jitsi-meet_prosody_1 /init Exit 128
docker-jitsi-meet_web_1 /init Exit 128
# docker-compose logs web
Attaching to docker-jitsi-meet_web_1

Ich hab jetzt keine große Lust das Filesystem umständlich zu mounten und da so reinzusehen 🙁

So lustige Sachen wie : „docker export CONTAINER|tar -t“ gehen auch nicht.

Meine Meinung: wer Docker produktiv einsetzt, sollte aus dem Zirkel der ITler exkommuniziert werden.

UPDATE – LÖSUNG

Es gibt noch Leute, die da durchblicken, „{hier ihre Gottheit einsetzen} sei Dank“!

Seit ner Weile gibt es im Kernel die neuen Control Groups 2. Fedora hat mit 31 auf cgroups2 umgestellt, aber Docker kann das nicht, weswegen die Container sauber wegcrashen.

Die Lösung des Problems ist zwar einfach, aber sollte echt nicht nötig sein:

# cat /etc/default/grub

GRUB_CMDLINE_LINUX=“rhgb quiet audit=0 systemd.unified_cgroup_hierarchy=0

Dann die grub Config neu erzeugen, oder einfach die /boot/grub/grub.cfg (Legacy)  kurz anpassen und rebooten. (Mehr Hinweise dazu in: Wenn sich Grub und Grubby uneins sind )

Danach starten die Container wieder, außer der Container hat beim Update was anderes verbrochen, was Jitsi tatsächlich hinbekommen hat:

Die JICOFO Komponente prüft doch jetzt tatsächlich, ob das Passwort nicht das Defaultpasswort ist. Das finde ich ja prinzipielle richtig gut, wäre da nicht der Umstand, daß das gar nicht eingeschaltet ist 😀

2. UPDATE:

Kleines Sicherheitsloch bei Jitsi-Meet:

Die Passwörter für die Instanzen werden in ENV variablen übergeben und nie gelöscht. Sobald jemand, wie auch immer, Zugang zur Prozessenviron bekommt, kann man das auslesen. Da potentiell noch andere priviligierte Prozesse im System laufen, ist generell eine dumme Idee.

Infos aus ENV variablen, die man nicht mehr braucht, gehören getilgt, in dem die Variable entfernt wird. Passwörter gehören übrigens GAR NICHT in ENV Variablen.

 

ClamAV < 0.102.3 mit DOS Schwachstelle

Derzeit ist kein Update für Fedora in Sicht, daher ggf. den Mailserver so umkonfigurieren, daß er keine PDF Files scannt.

Update 14.5.: die Updates für Fedora stehen bereit. Es wird aber noch etwas dauern, bis die in den Stables sind. Im Koji kann man sich die Builds für FC30-FC33 bereits ziehen. Exemplarisch für FC30, wäre das hier:

https://koji.fedoraproject.org/koji/search?terms=clamav-0.102.3-1.fc30&type=build&match=glob

Für FC30 haben wir den Build ausprobiert. er funktioniert. kann also bedenkenlos eingespielt werden.

Eilmeldung: ClamAV mit DOS Schwachstelle

Leider ist derzeit keine Fedora Version in der Mache für diese Schwachstelle:

Versionen: ClamAV < 0.102.3

In ClamAV bestehen mehrere Schwachstellen bei der Verarbeitung von bösartigen ARJ Archiven und PDF Dateien. Ein Angreifer kann dadurch den Virenscanner zum Absturz bringen. Zur Ausnutzung genügt es, eine entsprechende ARJ oder PDF Datei mit ClamAV zu scannen.

Hier die Meldung komplett:

ClamAV 0.102.3 is a bug patch release to address the following issues:

  • CVE-2020-3327: Fixed a vulnerability in the ARJ archive-parsing module in ClamAV 0.102.2 that could cause a denial-of-service condition. Improper bounds checking of an unsigned variable results in an out-of-bounds read which causes a crash. Special thanks to Daehui Chang and Fady Othman for helping identify the ARJ parsing vulnerability.
  • CVE-2020-3341: Fixed a vulnerability in the PDF-parsing module in ClamAV 0.101 – 0.102.2 that could cause a denial-of-service condition. Improper size checking of a buffer used to initialize AES decryption routines results in an out-of-bounds read, which may cause a crash. OSS-Fuzz discovered this vulnerability.
  • – Fixed „Attempt to allocate 0 bytes“ error when parsing some PDF documents.
  • – Fixed a couple of minor memory leaks.
  • – Updated libclamunrar to UnRAR 5.9.2.

Das hat wohl einige kalt erwischt, als das Bürger-CERT dazu heute eine Warnung rausgehauen hat. Ich werde Euch Informieren, wenn sich das ändert.

Quellen:https://blog.clamav.net/2020/05/clamav-01023-security-patch-released.html

 

Installer loggen LUKS Passwort mit

Moin, Moin,

na auch schon die Platte aufgeräumt und die alten Installerlogfiles gelöscht?

Installer loggen LUKS Passwort mit

Ubuntu ist da mal was „passiert“ was wohl auch anderen Installern in der Gemeinde passiert sein könnte:

https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1878115

Der Bugreporter hat festgestellt, daß sein Ubuntuinstaller sein LUKS Festplattenpasswort einfach mal mit ins Logfile geschrieben hat. Diese Datei liegt zwar in der verschlüsselten Platte selbst, könnte aber durch einen „Besucher“ geleakt werden oder in Backups gefunden werden, die nicht auch in der Krypto vergraben wurden.

Da hat der Bugreporter wohl recht, auch wenn ich das Risiko als äußerst gering ansehe. Die Logfiles landen z.B. bei Anaconda üblicherweise in /root/, wenn da ein Besucher dran kommt, hat man ganz andere Probleme als das es da drinsteht. Insofern: gut gebrüllt, Kätzchen 😀