Tablet: Fedora 33 Beta auf Surface Pro 4

Wieso würde ich Euch eine Nachricht antun, daß Fedora 33 Beta Linux auf meinem Tablet läuft? 🙂

Tablet: Fedora 33 Beta auf Surface Pro 4

Also ein Grund ist, das es Gnome 3.38 hat:

der andere Grund ist, daß es bis vor 10 Minuten nicht ging 😉

Im LiveImage von Fedora 33 kommen neue Grub Bootloader zum Einsatz und die starten nicht auf dem normalen Surface Pro 4, weil das wohl ein Firmware Update braucht, was es natürlich als reines Linux System nicht bekommen wird.

Ihr entsinnt Euch vielleicht an diesen Artikel: Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Grub 2 hatte da einen bedauerliches Problem. Das wirkt sich nun scheinbar auf das Liveimage aus.

Beheben lies sich das durch ein Transplant der Grubbootloader in der Boot-Partition von F31 auf F33. Fedora ist dran, wird da aber ein kleines Problem haben, weil das Firmwareupdate von Microsoft kommen müßte.

GGf. können die Jungs vom Surface Kernel Projekt helfen, aber das wird sich erst in den nächsten Tagen entscheiden, denn noch wissen die nichts von Ihrem Glück.

PS: ich staune. Mein nur zu 77% gefüllter Akku soll angeblich noch 6 Stunden bei 4 Kernen und aktivem Turbo halten. Wie lange wäre das denn, wenn der voll wäre??? und schon sprang er auf 5h 45m. Verdacht: Es lügt mich in freundlicher Absicht an 😀

Hmm.. „Suspend“ funktioniert, der wacht sogar sofort wieder auf, wenn man auf den Power-Knopf drückt. Leider killt er dabei den Wifichip 🙁

UPDATE:

Stellt sich gerade raus, es ist wohl ein Timing Problem, denn 1 von ca. 10 Boots klappt und je schneller man bootet, nachdem der USB Stick eingesteckt ist, desto wahrscheinlicher der Start. Ich hoffe wir finden das raus. Der Grubsfiles sind da wohl nicht von Bedeutung.

Fedora: systemd-resolved Diskussion eskaliert

Wow, das habe ich nicht kommen sehen: Leonard Pöttering macht sich einen Feind fürs Leben, auf der Fedora-Devel Mailingliste 😐

Fedora: systemd-resolved Diskussion eskaliert

Das die Diskussion so schnell in einen Developerkrieg eskaliert, hätte ich nie für möglich gehalten:

„As we share the same employer, I encourage you to escalate my „derogatory behaviour“ to our magenement.

I did not read the rest of your email. I will not read or respond to further emails from you on mailing lists.“ (Paul Wouters, 29.9.2020 18:56 Uhr)

zu Deutsch:

„Da wir denselben Arbeitgeber haben, ermutige ich Sie, meine „abfälliges Verhalten“ unserem Arbeitgeber zu melden.

Den Rest Ihrer E-Mail habe ich nicht gelesen. Ich werde sie weder lesen, noch auf weitere E-Mails von Ihnen auf Mailinglisten antworten.“

Herr Pöttering schrieb dies vorher an die Mailingliste:

„“Custom“ is in the eye of the beholder. It appears to me you mean that in a derogatory way.

I mean, given that Ubuntu has been enabling systemd-resolved since quite some time by default I have the suspicion our codebase is more often deployed IRL than the ones you listed? I mean, maybe I am wrong, but it’s certainly not that this is exotic stuff as you imply.

I have the suspicion this is a territorial thing, no? It feels as if you believe that DNS clients that people wo are not core members of the DNS community are inherently a bad thing, and should go away, and leave the real work to the people who actually know how things work, right? I got that kind of behaviour once before when people told us to just leave service management to the real holy men of UNIX.“ (Leonard Pöttering, 29.9.2020 18:18 Uhr)

zu Deutsch:

„Kundenspezifisch“ liegt im Auge des Betrachters. Mir deucht, Sie meinen daß in abfälliger Weise.

Ich meine, angesichts der Tatsache, dass Ubuntu seit geraumer Zeit standardmäßig systemd-resolved aktiviert hat, habe ich den Verdacht daß unsere Codebasis häufiger IRL eingesetzt wird als die, die Sie aufgelistet haben? Ich meine, vielleicht irre ich mich, aber es ist sicher nicht so, dass dies so exotisch ist wie Sie andeuten.

Ich habe den Verdacht, dass dies eine territoriale Angelegenheit ist, nicht wahr? Es fühlt sich an, als ob Sie glauben, dass DNS-Clients, von Personen die keine Kernmitglieder der DNS-Kern-Gemeinschaft sind, von Natur aus eine schlechte Sache sind und verschwinden sollten, und überlassen Sie die eigentliche Arbeit den Menschen, die tatsächlich wissen, wie die Dinge funktionieren, richtig? Ich habe diese Art von Verhalten schon einmal erlebt, als man uns sagte „Überlassen Sie die Verwaltung der Dienste einfach den wahren heiligen Männern von UNIX“.“

Irgendwie kann ich beiden zustimmen, auf der einen Seite gibts extra eine teuer bezahlte Arbeitsgruppe bei der IETF, die Sachen entwicklen sollte, auf der anderen Seite kommen die nicht zu potte ( schreibt Pöttering einen Absatz später ). Trotzdem sehe ich das eher so, daß allein schon wegen fehlendem DNSSEC und dem Default Fallback zu Cloudflare und Google DNS-Servern, systemd-resolved nicht einfach so eingesetzt werden kann.

Angebot

Viele der Probleme, die resolved lösen soll, sind eherlich gesagt Luxusprobleme, die sich mit ein klein wenig Hirnschmalz lösen lassen. Bis auf ganz exotische Szenarien, wo jemand für alles, was er per Interface 1 erreichen kann, DNS 1und2  benutzen will und für Interface 2 dann DNS 3und4, reicht das. Wer ein echt komplexes Setup hat, mit VPN Tunneln durch VPN Tunnel der darf mir gern einen Leserbrief schicken und das mal darstellen. Dann schaue ich mir das gern mal an und gucke, ob das nicht einfacher geht. Herrn Pöttering habe ich auch um ein Beispiel angemailt, mal sehen ob eins kommt.

 

Fedora: Die DNS Geschichte trägt Früchte

Wer die Mailingliste von Fedora-Devel gelesen hat, wird es mit bekommen haben: Das Thema systemd-resolved & DNS trenden enorm.

Fedora: Die DNS Geschichte trägt Früchte

Als eine Konsequenz der Diskussion wurde ein Änderungsvorschlag der DNS Gruppe von Michael Catanzaro eingereicht, daß systemd-resolved ab sofort mit einem optimistischen DoT aktiviert wird, also DNS-over-TLS, dem älteren Bruder von DNS-over-HTTPS ( DoH ).

Das meint für den Benutzer, wenn ein eingestellter DNS Server DoT unterstützt, und das findet man leicht mit einem Connectversuch auf den passenden Port 853 heraus, soll automatisch die Verschlüsselung benutzt werden. Das ist natürlich aus Datenschutzgründen zu bevorzugen.

Der Nachteil der Sache ist leider, daß die DNS Anfragen nicht ganz so schnell kommen, wie man das gewohnt ist, weil ja mehr Daten und Verschlüsselung im Spiel sind. Es ist aber ein Weg in die richtige Richtung.

Ein bisschen laut Lachen mußte ich allerdings bei der Passage:

== Benefit to Fedora ==

DNS queries are encrypted and private by default, if the user’s ISP supports DoT. Most probably don’t, but users who manually configure a custom DNS server (e.g. Cloudflare or Google) will automatically benefit from DNS over TLS.

Ausgerechnet die beiden DNS Server zu empfehlen, die das Privatsspährenproblem im systemd-resolved sind, ist schon eine Farce 😀

 

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

Wow, was für eine Hammermeldung. Damit hatte vermutlich niemand gerechnet, daß der Wechsel zu systemd-resolved als DNS Resolver des Systems einfach mal die einzige Sicherheitsmaßnahme im DNS aushebelt, die überhaupt spürbar Sicherheit gebracht hat 🙂

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

„Seit heute morgen 6:44 Uhr wird zurück geschossen“ :  Paul Wouters, bekannt aus dem Bereich Transparenz und Sicherheit der IETF, updatete seinen Server auf Fedora 33, was er quasi sofort bereut hat. Mit dem Wechsel kam die Umstellung auf systemd-resolved, über den wir vor Monaten in der Fedora Mailingliste gesprochen hatten und ich eigentlich der Meinung war, daß die Umstellung der /etc/resolv.conf hin zu systemd-resolved in der Form gar nicht kommt.

Man merkt, daß Paul bei seinem Posting an die Fedora-Devel-Mailingliste auf Krawall gebürstet war, und das vollkommen zu Recht. Seine ganzen Serverdienste benutzen DNSSEC um die Verbindungen zu Mailserver, VPN usw. abzusichern, so daß niemand für seine Dienste eine MITM-Attacke fahren kann und dann kann der eingesetzte DNS-Resolver plötzlich kein DNSSEC mehr:

„It is my opinion as a long time DNS RFC author and package maintainer that systemd-resolved is not a suitable DNS resolver. Downgrading DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I read on:

https://fedoraproject.org/wiki/Changes/systemd-resolved

that DNSSEC is now completely disabled. Again, this is completely unacceptable. DNSSEC is part of the core of DNS protocols.“ (Paul Wouters)

Ich hätte nicht gedacht, daß jemand wirklich so verrückt wäre, Millionen von PCs mit einem DNS-Resolver aus der Steinzeit zuversehen, wo das Update doch eine Verbesserung und kein Rückschritt sein sollte. Seinen weiteren Ausführungen kann man sich nur anschliessen:

„This change is harmful to network security, impacts existing installations depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but to 20years+ developers of the bind software as well.

The first mandatory step is to not disable DNSSEC. If I put on my security hat, I would actually have to look into filing a CVE for Fedora 33.“ (Paul Wouters)

Und der Mann weiß was er da schreibt, er hat 20 Jahre an Bind mitgeschraubt. Zum Glück für uns ist nichts in Stein gemeiselt, daher jetzt die Befehle, um nach dem Upgrade für Ordnung zu sorgen:

sudo rm -f /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl disable –now systemd-resolved.service
sudo systemctl mask systemd-resolved.service
sudo systemctl reboot

Damit haben wieder die DNS Einstellungen das sagen, die der User beim Anlegen der Netzwerkverbindung getroffen hat. Ich finde ja schon lange, daß der Systemd sich deutlich zu weit aus dem Fenster hängt. Das ist ein Bootsystem und kein eigenes Betriebssystem Leonard! Aber stellt sich doch glatt raus, daß der resolved vom systed das könnte, wenn man es nur einschalten würde, was es per default nicht ist :facepalm:

 

Das Update ist der Anfang vom Ende

Noch letzte Woche habe ich einer Linux-Usergroup Sitzung die Material-Shell Erweiterung für Gnome gezeigt und für sinnvoll erklärt. Zum Glück bin ich kein Politiker.

Das Update ist der Anfang vom Ende

Das keine 5 Tage später mein vorsichtiges Empfehlen dieser Erweiterung zu einem rüden Stop kommen würde, konnte da noch keiner ahnen. Leider kann ich Euch nicht zeigen, wie die Material-Shell funktioniert, da sie sich sehr erfolgreich durch ein Gnome-Extensions-Update selbst zerbröselt hat.

Trotz diverser Versuche, inkl. Neustarts von Gnome, war ich nicht in der Lage die Erweiterung auf diesem Benutzeraccount wieder zum Laufen zu bekommen. Da darf man gespannt sein und vermutlich alles, was mit der Erweiterung zu tun hat wie „Config“,“Cache“,“Erweiterung selbst“ aus den Verzeichnissen löschen und dann von vorn anfangen. Ohne diese Maßnahme kommt es zur sinnlosesten Fehlermeldung ever: „Error“

Damit kann man als Gnome-Benutzer natürlich nichts anfangen, außer die Erkenntnis gewonnen zu haben, daß es sich da jemand sehr einfach gemacht hat. Zum Glück kann man mit der Looking-Glass Konsole von Gnome doch etwas erfahren, aber halt nur als Eingeweihter in die Tücken der Gnome-Erweiterungen. Diese sind z.Z. in Javascript geschrieben und können daher tatsächlich von Webentwicklern geändert werden, die JS verstehen. Das hilft zwar nicht immer, weil es kein Browser-JS ist, aber kleinere Fehler kann man beheben.

Eine Debugkonsole von Gnome mit InhaltWir haben also den Fehler „TypeError: GObject.registerClass() used with invalid base class ( is Source )“

Scheint also ein Programmierfehler zu sein in der neuen Version. Das hätte ja eigentlich beim Testen mal auffallen müssen. Mit einem Trick kann man das ganze „Retten“:

Mit Firefox ladet Ihr jetzt die V4 der Gnome-Erweiterung für die passende Shellversion (34) runtern:

Die gespeicherte Version ist ein ZIP File, das packt Ihr einfach aus und wechselt in das erstellte Verzeichnis.

Ihr macht nun einen zweiten Dateibrowser auf und navigiert nach: „./local/share/gnome-shell/extensions/material-shell@papyelgringo“ . Alles was Ihr findet wird gelöscht, der Ordner bleibt.

Dann kopiert Ihr den Inhalt des frisch ausgepakten ZIP Files in das leere Verzeichnis:

Zwei Dateibrowser mit Inhalt einer Gnome-Erweiterung beim kopieren von Dateien

Drückt „ALT+F2“ und gebt „r“ ein. Das startet Gnome neu und siehe, die Material-Shell geht wieder. Problem gelöst, aber Updates gibt es erstmal keine mehr 🙂

 

 

Arbeiten an Fedora 34 starten

Die Arbeiten an Fedora 34 haben begonnen. Das neue Repo wird derzeit erstellt und die ersten Pakete sind bereits gebaut worden.

Arbeiten an Fedora 34 starten

Soweit ich erkennen kann, gibt es leider noch Probleme beim Rawhide Repo. Der Build ist leider gefailed. Macht nichts, denn dies war trotzdem der Startschuss für Fedora 34 🙂

Für Fedora 31 User bedeutet es, sich langsam auf die Umstellung Richtung F32 einzustellen. Die Updates können entweder über den Softwarecenter gemacht werden, der nervt ja sowieso schon seit Monaten damit, daß es Fedora 33 gäbe, oder über dnf. dnf  hat den Vorteil, daß man im Verlauf wenigsten zusehen kann und weiß, wann das durch ungefähr durch sein wird.

Ich mag das Update mit dnf als Admin ja ohnehin lieber, weil man dann auch Fehler vorbeiscrollen sieht, die man behandeln und melden könnte. Natürlich hoffen wir alle, daß es keine geben wird 😉

 

Schwachstellen im Apache Webserver < 2.4.44

Wer Apache als Webserver einsetzt, sollte jetzt aufpassen, denn wir haben jeweils eine  RCE und eine DOS Schwachstelle.

Schwachstellen im Apache Webserver < 2.4.44

In Apache wurden drei Schwachstellen identifiziert und im August behoben. Leider hat man u.a. bei Fedora vergessen, das publik zu machen, deswegen hier die Erinnerung für Euch:

Im HTTP2 Modul sind zwei Schwachstellen enthalten, die zum Crash führen und damit als DOS (Denial of Service) gelten:

important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Beide Schwachstellen kann man auch per Konfigurationsänderung abwehren, falls man keine gepatchten Webserver bekommen kann, oder noch nicht hat:

Je nachdem was Ihr für eine Distro habt, wird HTTP2 an verschiedenen Stellen aktiviert. Bei Fedora bietet sich an, eine eigene kleine Config in conf.modules.d/ anzulegen. In die Datei kommen zwei Einträge:

99-mitigate-http2.conf:

H2Push off
LogLevel warn mod_http2.c:error

Dann mit „systemctl httpd restart“ den Server neustarten. Die erste Anweisung behebt die 2020-9490 und die zweite sagt dem HTTP2 Modul, es soll nur kritische Sachen loggen, anstatt auch Warnungen. Das ist wichtig, da Angreifer über einen provozierten Fehler den Logging-Pool der Prozesse stören können und das führt dann zum Crash, was aber nur geht, wenn der Fehler auch geloggt wird.

moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)

Wer mit dem WebSocket Proxy uwsgi arbeitet, der muß updaten, eine Mitigation der möglichen Remote-Code-Schwachstelle ist nicht möglich. Bis zum Update kann man das Modul auch abschalten:

Für Fedora wäre das hier in conf.modules.d/00-proxy.conf:

# LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

Einfach ein # vor die Ladeanweisung und den Webserver mit „systemctl httpd restart“ neustarten. Natürlich funktionieren die Proxy Tunnel, die auf „uwsgi:://server:port/uri“ lauten, dann nicht mehr. Habt Ihr noch einen vhost konfiguriert, der das benutzen möchte, wird der Start des Webservers nicht funktionieren.

Updates vorhanden

Updates auf die 2.4.46 liegen für Fedora bereit. Für alle, die Ihre Server per Autoupdate versorgen, hat sich das Problem damit bereits erledigt.

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Eine wichtige Ressource für alle, denen der Grub2 Security Fix ihrer Distribution das Booten sabotiert hat, ist:

https://docs.pagure.org/docs-fedora/the-grub2-bootloader.html

Die ist zwar für Fedora, aber da steht alles in Kleinarbeit drin, wie man Bootloaderprobleme selbst behebt.

Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Für alle != Fedora oder RH basierten Distris gelten die gleichen Schritte nur die Pakete heißen anders.

Das Vorgehen ist immer das Gleiche:

1. Von einem USB Stick booten
2. die lokale Systemplatte mounten
3. chroot /*mount_systemplatte*
4. /boot/ einhängen
5. mit dem hoffentlich eingerichteten Netzwerk die alte Grubversion aus dem Repo ziehen.

Beispiel DNF:  „dnf downgrade shim grub2*“

6.  grub2-install /dev/sda

wobei /sda  das richtige Laufwerk von Eurer Systemplatte sein muß, müßt Ihr mal schauen wie das heißt.

7. aus der chroot raus, alles unmounten, rebooten .. sollte wieder gehen.

Für alle, die das mit dem alten Grub2 Paket nicht hinbekommen, auf der LIVE-Disk die Ihr dafür benutzt IST einen alter Grub2 drauf! Den könnte man auch mal direkt versuchen 😉

Wenn Ihr EFI bootet, dann braucht es auch den passenden shim im /boot/efi/ Pfad, das ist schliesslich der Auslöser des Übels gewesen 😉  Und oh Freude, auch der ist schon passend zum Grub2 auf der Livedisk drauf, braucht man nur kopieren.

Noch etwas: Für Fedora gibt es noch kein Grub2 Update, nicht mal im Alpha Stadium. Die wissen schon wieso 😉 (hoffe ich)

RCE: Firefox 79.0 Update einspielen

Mojn, Moin,

bitte spielt mal Eure FireFox Updates auf 79.0 ein, da <79 leider eine RCE Schwachstelle hat ( Remote Code Execution ). Also das Schlimmste vom Schlimmen.

RCE: Firefox 79.0 Update einspielen

Das BSI-Bürger-Cert schreibt dazu:

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Mozilla Firefox und Mozilla
Thunderbird ausnutzen, um Schadcode auszuführen, einen Absturz zu verursachen, vertrauliche
Informationen auszuspähen oder Sicherheitsvorkehrungen zu umgehen. Zur Ausnutzung genügt es, eine bösartige E-Mail, Webseite oder einen Link dorthin zu öffnen.

so spielt Ihr das Update für Fedora ein:

sudo dnf -y update –enablerepo=updates-testing firefox

Einfach noch das Rootpasswort bestätigen, fertig.

Cato der Ältere meinte dazu übrigens: Ave RPM!

Wer wissen will, was das jetzt sollte, die BS LUG trifft sich einmal die Woche zu einem VideoChat, da löse ich das auf 😉

libvncserver Sicherheitslücke erreicht 9.8/10 und wurde lange nicht gefixt

„WOW“ entfleuchte es mir vorhin kurz, deswegen kommt Ihr jetzt in den Genuß einer drei Jahre alten Sicherheitslücke.

libvncserver Sicherheitslücke erreicht 9.8/10 und wurde lange nicht gefixt

Beim Durchsehen von Securityadvisories bei Red Hat Enterprise Linux stolperte ich über eine CVE Nummer aus 2017:

* libvncserver: websocket decoding buffer overflow (CVE-2017-18922)

For more details about the security issue(s), including the impact, a CVSS
score, acknowledgments, and other related information, refer to the CVE
page(s) listed in the References section.

Da nicht dabei stand, was da los war und wieso das erst jetzt gefixt wurde bei Red Hat, habe ich kurz recherchiert. Was dabei raus kam war diese Meldung von Red Hat:

Date: Tue, 30 Jun 2020 10:50:09 +0200
From: Stefan Cornelius <scorneli@...hat.com>
To: <eine Distri übergreifende ML>
Subject: libvncserver: old websocket decoding patch

Hi,

Upstream libvncserver fixed a websocket decoding issue >3years ago in
https://github.com/LibVNC/libvncserver/commit/aac95a9dcf4bbba87b76c72706c3221a842ca433

AFAICT, this never got a CVE and wasn't backported by some
distributions.

Thanks and kind regards,

[I sent a heads-up about this to distros last Friday, 'embargo' ran out
on Monday 20:00 UTC]
-- 
Stefan Cornelius / Red Hat Product Security

Da fixt also jemand eine drei Jahre alte Sicherheitslücke, weil die damals wohl keine CVE Nummer bekommen hatte, oder jemand diesen Umstand übersehen hat. (Könnte ja auch den besten mal passieren). Wäre das jetzt irgendeine schwer auszunutzende Lücke gewesen, hätte ich das achselzuckend abgehakt, aber das war es nicht.

In der NIST Datenbank findet sich nämlich das hier dazu:

It was discovered that websockets.c in LibVNCServer prior to 0.9.12 did not properly decode certain WebSocket frames. A malicious attacker could exploit this by sending specially crafted WebSocket frames to a server, causing a heap-based buffer overflow.

Severity

Base Score: 9.8 CRITICAL
Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.8 von 10.0 möglichen Punkten auf der Destruktionsskala, also eine leicht auszunutzende Lücke, die ohne Autorisierung am System funktioniert und eine Übernahme des Servers ermöglicht. Und DAS haben die übersehen… => WOW!
Als wenn das nicht schon genug wäre, kommt bei der Durchsicht der Updatemeldungen bei Fedora raus, das da gleich noch 3 andere jahrealte mit CVE Nummern versehen Sicherheitslücken gestopft wurden:
[ 1 ] Bug #1849877 – CVE-2019-20839 (Score 7.5) libvncserver: „ConnectClientToUnixSock()“ buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1849877
[ 2 ] Bug #1849881 – CVE-2019-20840 (Score 7.5) libvncserver: unaligned accesses in hybiReadAndDecode can lead to a crash https://bugzilla.redhat.com/show_bug.cgi?id=1849881
[ 3 ] Bug #1849886 – CVE-2018-21247 (Score 7.5)  libvncserver: uninitialized memory contents are vulnerable to Information Leak https://bugzilla.redhat.com/show_bug.cgi?id=1849886
[ 4 ] Bug #1852356 – CVE-2017-18922 (Score 9.8) libvncserver: websocket decoding buffer overflow https://bugzilla.redhat.com/show_bug.cgi?id=1852356
Also das ist sicherheitstechnisch mal gründlich in die Hose gegangen. Jetzt denkt Ihr, betrifft mich nicht, ist ja Fedora und Red Hat.. leider Pech gehabt! betroffen sind auch:  OpenSUSE & Ubuntu. Man darf annehmen, daß Arch & Debian auch mit von der Partie sind. (kann ja mal kurz wer verifizieren, der die jeweiligen Updatesysteme kennt)

Quelle: https://nvd.nist.gov/vuln/detail/CVE-2017-18922
Quelle: https://www.openwall.com/lists/oss-security/2020/06/30/2