Let’s Encrypt gibt milliardstes Zertifikat aus \o/

Am 27.2. wurde die eine Milliarde SSL Zertifikate von Let’sEncrypt überschritten. Bei 46 Millionen Webseiten für die Zertifikate ausgestellt wurden, war das ja auch nur eine Frage der Zeit, wenn man 4 Zerts pro Jahr pro Domain durchbringen muß 🙂

Herzlichen Glückwunsch – Let’s Encrypt 😀

„We issued our billionth certificate on February 27, 2020. We’re going to use this big round number as an opportunity to reflect on what has changed for us, and for the Internet, leading up to this event. In particular, we want to talk about what has happened since the last time we talked about a big round number of certificates – one hundred million. One thing that’s different now is that the Web is much more encrypted than it was. In June of 2017 approximately 58% of page loads used HTTPS globally, 64% in the United States. Today 81% of page loads use HTTPS globally, and we’re at 91% in the United States! This is an incredible achievement. That’s a lot more privacy and security for everybody. Another thing that’s different is that our organization has grown a bit, but not by much! In June of 2017 we were serving approximately 46M websites, and we did so with 11 full time staff and an annual budget of $2.61M. Today we serve nearly 192M websites with 13 full time staff and an annual budget of approximately $3.35M. This means we’re serving more than 4x the websites with only two additional staff and a 28% increase in budget. The additional staff and budget did more than just improve our ability to scale though – we’ve made improvements across the board to provide even more secure and reliable service.“

Das selbstgesteckte Ziel haben Sie jedenfalls erreicht, das ist mal sicher. Ob das Netz wirklich sicherer geworden ist, ist eine andere Frage 😀

CoronaV19 vs. Influenza

Um sich mal einen Überblick über die Lage zugeben, hier ein Vergleich der Zahlen vom Robert-Koch-Institute vom 28.2.2020 für Deutschland:

GRIPPE/Influenza: 98.500* Infizierte
SARS-VoV-2:         53 Infizierte

Meint, wir haben mehr Grippekranke in dieser Session diesem Land, als es derzeit  Corona Infizierte (83k) weltweit gibt.

Im Influenza-Wochenbericht des RKI stehen dazu folgende Belege:

„Für die 8. Meldewoche (MW) 2020 wurden nach Infektionsschutzgesetz (IfSG) bislang 17.898 labor-diagnostisch bestätigte Influenzafälle an das Robert Koch-Institut übermittelt (Datenstand: 25.2.2020).“ und „Seit der 40. MW 2019 wurden insgesamt 98.442 labordiagnostisch bestätigte Influenzafälle an das RKI übermittelt“

Die Dunkelziffer dürfte größer sein, schon weil dieser Bericht die letzte aka diese Woche noch gar nicht berücksichtigt.

Quelle: https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/Fallzahlen.html

Quelle: https://influenza.rki.de/

XRDP und das screen-Tool

Ihr wisst noch, daß man nicht so genau hinsehen sollte, wenn man mehr Freizeit haben will? 😉 Den Grundsatz habe ich mal wieder bei RDP ignoriert und bin prompt in die Falle getappt.

XRDP, die Session und das screen-Tool

Wer von Euch weiß, was PID 1 ist? Ok, eine rhetorische Frage, jeder weiß das. Für die, die das vergessen haben, kleine Auffrischung:

Der erste Prozess, der beim Start des PCs erstellt wird, hat die Process-ID 1 ( PID ). Jeder andere Prozess danach, ist ein Kind(Child) vom Prozess mit PID 1. Der Prozess ist also das Elternteil(Parent) von dem gestarteten Prozess. Beim Systemd-Init-System heißt der PID 1 Prozess sinnigerweise „systemd“, beim Vorgänger System-V  wars noch „init“.

Beispiel:

systemd(1)-+-ModemManager(1300)-+-{ModemManager}(1352)
           |                    `-{ModemManager}(1354)
           |-NetworkManager(1319)-+-{NetworkManager}(1360)
           |                      `-{NetworkManager}(1362)

Hier im Beispiel, ist systemd(1) der Eltern-Prozess und ModemManager(1300) und NetworkManager(1319) sind die Kinder-Prozesse. Wenn der Rechner runtergefahren wird, terminiert der PID1 Prozess alle seine Kinder-Prozesse und wenn keins mehr da ist, beendet er sich selbst, in dem er der HW das Strom-Aus-Kommando sendet.

Merke: Alle Prozesse sind Kinder oder Kinds-Kinder von PID1, weil das eine baumartige Struktur ist.

Wer sich das mal selbst ansehen will: einfach „pstree -up | less“ in ein Terminalfenster eingeben.

Was passiert, wenn der Elternprozess eines Kindes terminiert wird und dieser Elternprozess nicht PID1 ist?

Im Beispiel oben, terminieren wir mal gedanklich den NetworkManager(1319) der ja 1360 und 1362 als Kinder hat. Was jetzt passiert ist, daß die Kinder-Prozesse als Waisen dem PID1 übertragen werden. Sie bekommen also einen neuen Eltern-Prozess, aber sonst ändert sich nichts: Sie laufen i.d.R. weiter.

Es gibt auch Situationen, wo das nicht der Fall ist, aber die lassen wir mal aus.

Ich merke gerade ich muß weiter ausholen, sonst verstehen das nicht alle Leser, daher nicht wundern, wenn alles etwas schlicht gehalten ist und es einem trotzdem wie eine Wüstenwanderung ohne Wasser vorkommt.

Der Benutzer meldet sich an

Stellen wir uns vor, Systemd hat das System(PC) soweit hochgefahren, daß uns am Monitor eine Anmeldemaske(Login-Dialog) begrüßt. Wenn der Benutzer einloggt(sich anmeldet), wird die Desktop-Session gestartet, das kann z.b. Gnome, Cinnamon oder sonst eine andere Deskopumgebung sein. Die Startet dann wieder Programme bis so eine Arbeitsoberfläche entstanden ist, wie man die von Fotos kennt:

Ein GNOME Remotearbeitsplatz mit laufendem VideoEs laufen jetzt rudelweise Prozesse im Namen des Benutzers:

systemd(1)-+-ModemManager(1300)-+-{ModemManager}(1352)
          ...
           |-csd-printer(2448,marius)-+-{csd-printer}(2449)
           |                          `-{csd-printer}(2450)
           |-cupsd(1364)
           |-dbus-broker-lau(1276,dbus)---dbus-broker(1277)
           |-dbus-daemon(5007,marius)---{dbus-daemon}(5011)
           |-dbus-daemon(5153,marius)---{dbus-daemon}(5154)
           |-dbus-daemon(5282,marius)---{dbus-daemon}(5283)
           |-dbus-daemon(5868,marius)---{dbus-daemon}(5869)
           |-dbus-daemon(8160,marius)---{dbus-daemon}(8161)
           |-dbus-daemon(12280,marius)---{dbus-daemon}(12281)
           |-dbus-daemon(27861,marius)---{dbus-daemon}(27862)
           |-dconf-service(5201,marius)-+-{dconf-service}(5202)
           |                            `-{dconf-service}(5203)
           |-dconf-service(5330,marius)-+-{dconf-service}(5331)
           |                            `-{dconf-service}(5332)
           |-dconf-service(5372,marius)-+-{dconf-service}(5378)
           |                            `-{dconf-service}(5379)
           |-dconf-service(5924,marius)-+-{dconf-service}(5925)
           |                            `-{dconf-service}(5926)
           |-dconf-service(12329,marius)-+-{dconf-service}(12330)
           |                             `-{dconf-service}(12331)
           |-dconf-service(28004,marius)-+-{dconf-service}(28007)
           |                             `-{dconf-service}(28008)
          ...

und die sind, wie man oben sehen kann, Kinder vom PID1. Die „Ausreißer“-Prozesse die auch laufen, wenn sich kein Benutzer anmeldet, habe ich mal rot markiert. Die gehören i.d.R. root oder einem Servicebenutzer „nobody“,“www-data“,“mysql“ so in der Art. Die werden gleich wichtig.

Wenn der Benutzer sich ausloggt

Kommen wir zu dem Punkt, wo sich der Benutzer aus dem PC ausloggt. Der Abmelden-Vorgang(Logout) stößt eine Kaskade an, die alle Benutzerprozesse terminiert. Wenn keine anderen Prozesse mehr laufen, dann terminiert sich der PID1 auch. I.d.R. ist das aber nicht der Fall, weil Root ja auch ein ganzes Rudel an Diensten gestartet hat, die alle Kind von PID1 sind.

Screen

Wenn man auf verschiedenen Servern zu tun hat, kommt man unweigerlich an den Punkt, wo man Programme laufen lassen muß die tage- oder wochenlang laufen müssen (ggf. auch ewig) oder man muß einfach zwischenzeitlich mal weg und will den Arbeitsstand den man erreicht hat nicht verlieren.

Einen Desktop-PC würde man einfach nicht abschalten und als Benutzer nur den Bildschirm sperren. Wenn man sich aber doch mal als anderer Benutzer an dem PC anmelden muß, und die Programme trotzdem nicht beendet werden sollen, kommt „screen“ ins Spiel.

Dies startet man in einer Konsole bevor man mit der Arbeit anfängt. Wenn man sich auf einem entfernten Server per SSH anmeldet, ist es oft der einzige Weg, wie man sicherstellen kann, daß ein Verbindungsverlust nicht im Desaster endet. Screen kann man aber natürlich auch in einem Desktop-Terminal starten.

Ich kann also als Benutzer meinem PC auch in einer Screensitzung längerfristig mit Aufgaben versorgen, mich dann ausloggen oder Bildschirm sperren und per SSH von Zuhause aus nachsehen, ob die Prozesse noch laufen oder schon fertig sind. Da jeder mit der richtigen Berechtigung eine Screensitzung betreten kann, kann ich dann also auch von Zuhause aus an der Stelle weiter machen, wo ich aufgehört habe.

Wenn ich das nur in einem Terminalfenster als eingeloggter Desktopbenutzer mache, kann ich das nicht tun, da man das Terminal nicht von außen betreten kann.

Damit dürfte die Idee hinter Screen klar sein:

Screen starten, Programme arbeiten lassen, die Benutzersitzung am Desktop oder per SSH beenden und dann später von irgendwo anders fortsetzen.

Jetzt kommt XRDP ins Spiel

Nun hatte ich einen PC bei einer Firma, den ich per getunneltem RDP von außen mit einer Desktop-Session benutzt habe und wollte die stundenlange Kopieraktion in einer Screensitzung laufen lassen und mich dann ausloggen. RDP hat das Problem, daß man nicht gleichzeitig per RDP und am Bildschirm eingeloggt sein kann.

Also muß man die Remote-RDP-Sitzung beenden, falls man am Bildschirm einloggen muß, weil der Job so lange lief, daß man schon wieder im Büro ist.  Das passiert öfters als man glauben mag.

Wenn man das tut, vertraut man darauf, daß man ja screen gestartet hatte und der Prozess noch da ist, wenn man wieder ins Büro kommt. War er aber nicht.

Ta Ta Daaaaaaa !!!

Eine per XRDP gestartete Desktop-Session bekommt nämlich einen eigenen systemd Prozess als Startprozess, genau wie der PC beim hochfahren auch, nur das dieser systemd Prozess keine anderen Dienste gestartet hat und daher alle seine Kinderprozesse terminiert, wenn die Sitzung endet… auch Screen!

Beispiel:

systemd(1)-+-ModemManager(1300)-+-{ModemManager}(1352)
           |                    `-{ModemManager}(1354)
           |-NetworkManager(1319)-+-{NetworkManager}(1360)
           |                      `-{NetworkManager}(1362)
	  ...
           |-gnome-terminal-(5111,marius)-+-bash(5412)---screen(13881)---screen(13882)---bash(13883)-+-less(14632)
           |                              |                                                          `-pstree(14631)
          ...
           |-systemd(5996,remote)-+-(sd-pam)(6006)
           |                             |-abrt-applet(6657)-+-{abrt-applet}(6671)
           |                             |                   |-{abrt-applet}(6672)
          ...
           |                             |                       `-{evolution-calen}(7037)
           |                             |-evolution-sourc(6381)-+-{evolution-sourc}(6383)
           |                             |                       |-{evolution-sourc}(6384)
           |                             |                       `-{evolution-sourc}(6385)
           |                             |-gnome-shell-cal(6374)-+-{gnome-shell-cal}(6378)
           |                             |                       |-{gnome-shell-cal}(6380)
           |                             |                       |-{gnome-shell-cal}(6432)
           |                             |                       |-{gnome-shell-cal}(6433)
           |                             |                       `-{gnome-shell-cal}(7050)
           |                             |-gnome-terminal-(11250)-+-bash(11424)---screen(21255)---screen(21326)---bash(21331)---les+
           |                             |                        |-{gnome-terminal-}(11277)
           |                             |                        |-{gnome-terminal-}(11278)
           |                             |                        `-{gnome-terminal-}(11310)
          ...

In dem Auszug oben seht Ihr den Unterschied:

systemd(1) -> systemd(????) -> gnome-terminal -> bash -> screen

statt:

systemd(1) -> gnome-terminal -> bash -> screen

Da systemd(????) (die ???? stehen für eine beliebige PID) nach dem Logout keine Prozesse von „anderen“ Benutzer gestartet hat, terminiert er sich auch selbst, was dann in Folge auch das Screen noch terminiert.

In der Desktopkette (in grün) bleibt der systemd (1) Prozess stehen, weil noch andere Prozesse von anderen Benutzern laufen (inkl. root), deswegen wird Screen dann nicht terminiert und läuft weiter.(denkt dran, einfache Darstellung 🙂 )

Am Beispiel von SSH schön zu sehen:

|-sshd(20153)-+-sshd(21640)—sshd(21661)—bash(21671)—screen(22867)—screen(22881)—bash(22882)

wird zu

|-screen(22881)—bash(22882)

Merke:

Wenn Du per XRDP eingeloggt bist und screen benutzen willst, melde Dich lokal per SSH an, starte dann screen und arbeite damit.

Es klingt bescheuert, weil man von Screen genau erwarten würde, daß es weiterläuft, aber es passiert halt nicht, weil der das screen in der Konsequenz startende Prozess ( systemd(????) ), alles terminert, weil er selbst terminieren will/muß.

Ich befürchte wir bekommen Pöttering nicht dazu, dafür eine Ausnahme in systemd einzubauen und müssen damit leben.

 

 

 

Security: Angriff auf WPA2 möglich, wenn Broadcom&Cypress Chips im Spiel sind

Eine Meldung der Hacker News erfreut die Gemütslage von allen Admins weltweit: WPA2 + Broadcomships sind eine schlechte Kombination 🙁

Angriff auf WPA2 möglich, wenn Broadcom & Cypress Chips im Spiel sind

Die mit CVE-2019-15126 registrierte Schwachstelle mit dem Namen „Kr00k“ erlaubt es in Kombination mit dafür anfälligen Chips von Broadcom &  Crypress, die WLAN Verschlüsselung teilweise zu verhindern.

Das funktioiert so, daß ein Angreifer ohne überhaupt im Funktnetz zu sein, ständig Disassoziationen auszulöst, indem er Deauthentifizierungspakete an alle sendet. Das führt dazu, daß sich die Chips aus dem WLAN lösen und den WLAN Schlüssel intern auf NULL setzen. So weit wärs noch ok, aber nun senden anfällig Broadcom und Crypress Chips die Restpufferinhalt im Chipspeicher ohne die Verschlüsselung ans Ziel. Streng genommen verschlüsseln die die Daten mit 000000000000000000, was dann keine Verschlüsselung mehr ist. Ist also ein Bug in der Chipfirmware, weil die müßte den Puffer auch leeren, statt den Inhalt denn zu senden.

„Unsere Tests bestätigten, dass einige Client-Geräte von Amazon (Echo, Kindle), Apple (iPhone, iPad, MacBook), Google (Nexus), Samsung (Galaxy), Raspberry (Pi 3), Xiaomi (RedMi) sowie einige Zugangspunkte von Asus und Huawei für Kr00k anfällig sind“, so die ESET-Forscher.“ schreiben die Hacker News.

Diese Lücke hackt also nicht Eurer WLAN Passwort, weswegen ein Wechsel des Passworts nichts bringt. Da Broadcom Chips in allen möglichen Geräten zu finden sind und damit in allem was IoT, Accesspoints, alte Handies etc. ist ungepatcht laufen, wird das ein schöner Mitschmatsch werden.

Wie könnt Ihr euch schützen?

Das schlimmste was mit dem Angriff passiert ist, daß einige eurer Pakete im WLAN so übertragen werden, als wenn es ein OFFENES-WLAN wäre. Damit sind alle die Datenübertragungen betroffen, die Klartextverbindungen beinhalten, z.b. HTTP:// Traffic, FTP, SMTP, POP, IMAP, DNS und jede Menge IoT Geraffel. Wer seine Dienste alle mit TLS Verbindungen wie HTTPS, FTPS, SFTP, SCP, SSH, STARTTLS für SMTP, POP und IMAP schützt, muß sich keine Sorgen machen. Aber wer zu Hause intern von einem PC per Samba auf einen anderen PC zugreift, dessen Daten könnten damit abgelauscht werden.

Ein gezielter Angriff auf bestimmte Daten ist mit dem Angriff nicht möglich, der Angreifer weiß also nie was er da so bekommt, aber je mehr er mitschneidet, desto schlechter für Euch.

Wie bekomme ich raus, daß ich betroffen bin?

Für Eurer Linux braucht Ihr erstmal eine Version von „lshw„, also für Fedorabenutzer eingeben: „sudo dnf install -y lshw

Ihr werdet Rootrechte brauchen, also „sudo su“ eingeben. Mit „ip l“ bekommt Ihr Eure Interfacenamen heraus, „ifconfig“ würde es auch tun:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:76:1c:be:39:c8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 34:e6:ad:5d:18:ee brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:e7:5f:07 brd ff:ff:ff:ff:ff:ff

Wir brauchen das wlp3s0 WIFI Interface. Jetzt gebt Ihr „lshw | less“ ein und bekommt eine lange Liste mit Info zu Eurer Hardware. Den Befehl solltet Ihr Euch also merken, den braucht man häufiger mal. In der Ausgabe sucht Ihr nach Eurem Interfacenamen und stoßt so auf solch einen Block:

*-network
description: Wireless interface
product: Wireless 3160
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlp3s0
version: 83
serial: 34:e6:ad:5d:18:ee
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=5.2.18-100.fc29.x86_64 firmware=17.3216344376.0 ip=192.168.0.103 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:54 memory:c4000000-c4001fff

Entweder verrät es euch jetzt schon die Herstellerbezeichnung, hier Intel Corporation, oder der Drivername (hier iwlwifi) gibt den Chiphersteller preis. Wenn da BC drin vorkommt, war es ein Broadcom. Den Code für Crypress Chips kenne ich jetzt leider nicht auswendig, aber das findet Ihr vermutlich im Netz auf Linux-Wifi-Infoseiten.

Wie gehts weiter?

Apple soll wohl bereits Patches für seine Benutzer veröffentlicht haben. Wann die anderen patchbaren Systeme hinterher ziehen, bleibt offen. Für alles was IoT, oder mehr als 2 Jahre alte Accesspoints, Handies etc. kommt wohl jede Hilfe zu spät, da hilft nur entsorgen. Vorher würde ich aber einen Blick auf die Webseite meines Herstellers werfen, vielleicht gabs ja doch ein Gnadenupdate.

Quelle: https://thehackernews.com/2020/02/kr00k-wifi-encryption-flaw.html

Datenschutz: Wie peinlich T-Online ist

Peinlicher, aber nicht ganz unerwarteter, Fauxpas von T-Online:

2020-02-25 04:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 04:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 05:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 06:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 07:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 08:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 09:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support

angemerkt sein, daß die Server für Kundenmails davon nicht betroffen sind. Das ändert aber nichts daran.

T-Online mit Datenschutzverstoß

Der Verzicht auf TLS stellt meiner Meinung nach, mal einen soliden Verstoß gegen Artikel 32 DSGVO dar, weil man als Mailserverbetreiber ja vorher nicht wissen kann, ob da drüber Personenbezogene Daten transportiert werden sollen oder nicht. Hellsehen, was einem einer jemals schicken wird, kann man ja nicht und daher muß man zwangsläufig vorher die Sicherheit der Datenübertragung aktiviert haben, weil nachträglich Sicherheit herstellen geht in dem Fall nun mal nicht.

Artikel 32
Sicherheit der Verarbeitung
(1) Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen  Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen unter anderem Folgendes ein:

a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten;

Das kombiniert mit Artikel 4 2. schließt den Transport von Daten mit in den Begriff „Verarbeitung“ ein und erzwingt, weil der Aufwand praktisch nicht vorhanden ist und somit auch keine Kosten entstehen, die Verschlüsselung von Emails beim Transport durch den Einsatz von aktuellen Techniken ( STARTTLS mit TLS 1.2+).

In dem Fall wären es tatsächlich Personenbezogene Daten gewesen, weswegen unser Mailserver so eingestellt ist, daß er das in dem Fall auf keinen Fall über unsichere Leitungen schicken darf.

Die Adresse tosa@rx.t-online.de ist übrigens eine T-Online Adminadresse, falls man mal mit seinem Server gesperrt ist(, weil T-Onlinekunden Spams an ihre echten Adressen einfach ungefiltert an T-Onlineadressen weiterleiten) . Ich gehe mal davon aus, daß wie bei großen Organisationen üblich, Links nicht weiß was Rechts hätte tun sollen.

Die notwendigen Schritte den Verstoß abzustellen, werde ich jetzt anstoßen.

Update: 18:50 Uhr

Es gab Antwort von T-Online… und jetzt schön hinschauen… nicht lachen…

Received: from mailout02.t-online.de ([194.25.134.17])
	by userserver with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.93)
	(envelope-from <postmaster@rx.t-online.de>)
	id ---
	for unsere@adresse; Tue, 25 Feb 2020 13:26:31 +0100
Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137])
	by mailout02.t-online.de (Postfix) with SMTP id ---
	for <unsere@adresse>; Tue, 25 Feb 2020 13:26:31 +0100 (CET)
Received: from mail.t-online-team.de (SU1DYkZrrhdrbk+8MoWoNLfFvJAGt3hYNV-3h42o51p2-46yGQLhcUQTxiv6TV2wPu@[194.25.187.129]) by fwd37.t-online.de
	with (TLSv1:ECDHE-RSA-AES256-SHA encrypted)
	esmtp id ---; Tue, 25 Feb 2020 13:26:30 +0100
From: Deutsche Telekom E-Mail Engineering ************* <postmaster@rx.t-online.de>
Date: Tue, 25 Feb 2020 13:26:31 +0100
Organization: Deutsche Telekom AG
X-Mailer: Forte Agent 6.00/32.1186
Content-Type: text/plain; charset=ISO-8859-1

Diese Email ist der nächste Verstoß gegen den Datenschutz, weil in der DSGVO steht drin, daß man auch bei internem Datentransport an die Absicherung denken muß.

Wie man sieht nutzt der erste Mailserver (mail.t-online-team.de) auf dem Weg zu unserem Mailserver (oberster Eintrag) TLSv1.0 , ein seit spätestens 2015 final geknacktes Protokoll. Der nächste interne Server  (fwd37.aul.t-online.de) benutzt für den internen Transport zu mailout02.t-online.de gleich gar keine Verschlüsselung mehr. Der letzte Mailserver mailout02.t-online.de macht dann endlich mal was richtig auf dem weg zu uns und benutzt TLSv1.2.

D.b. das „mailout02.t-online.de“ und „fwd37.aul.t-online.de“ können entweder miteinanders kein gemeinsames Protokoll finden, oder haben TLS/SSL gar nicht im Programm. Da aber jeder von denen auf der jeweils anderen Seite der Verbindung irgendwie TLS kann, muß da bei T-Online das Chaos pur herrschen. Ob das absichtlich, unabsichtlich oder fahrlässig so ist, werden die Datenschutzbehörden klären.

„Hallo T-Online, das Jahr 2005 will seinen Uralt-Zeichensatz zurück haben!“

Von dem ISO-8859-1 Fail des Mailprogramms will ich gar nicht erst anfangen, aber wirklich, was für einen uralt Krempel nutzen die da??? de-latin1 und TLSv1 passen historisch natürlich gut zusammen 🙂

Ältere Fälle:

Willkommen im Club der TLS Verweigerer: Apache Foundation!

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

Sächsische Polizei benutzte gebrochene Verschlüsselung

RemoteDesktop mit XRDP & XFreeRDP

Von Remotearbeitsplatzlösungen hat bestimmt sicher jeder schon mal etwas gehört. Die Technik dafür ist in der Regel auf VNC aufgebaut und trägt viele Namen: AnyDesk, Teamviewer, RDP oder auch direkt VNC.

RemoteDesktopProtocol

Wenn es bei VNC eher um die rudimentären Funktionen der Bildübertragung geht, so daß auf zwei Monitoren das Gleiche zu sehen ist, kann man sich mit RDP, Teamviewer und Anydesk auch als ein Benutzer auf einem anderen PC anmelden.

Ein GNOME Remotearbeitsplatz mit laufendem VideoUnter Windows nutzt man dazu das RemoteDesktopProtocol ( RDP ) und genau das kann man auch mit Linux nutzen. RDP ist in der Lage die Verbindung mit TLS zu verschlüsseln, was einen großen Vorteil hat, wenn man das quer durchs Internet benutzt. Es ist allerdings eine schlechte Idee, den RDP Port frei ins Netz zu stellen. Die Windows RDP Serverversion ist in der Vergangenheit mehrfach erfolgreich Ziel von Angreifern geworden, daher empfehle ich für Linux ohnehin, daß man den Port über SSH tunnelt.

Das geht ganz leicht:

ssh -C -L 127.0.0.1:3389:RDPSERVERIP:3389 username@sshgateway

Der Linux Client – XFreeRDP

Die Verbindung zu einem RDP Server aufzubauen ist ganz leicht, wenn man XFreeRDP benutzt. Analog zu dem SSH Tunnel oben, hier die dafür nötige Syntax:

xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1020

Die erste Frage wird jetzt wohl sein, wieso 1920×1020. Das ist leicht, weil das als Fensterversion genau in einen FullHD Monitor mit Cinnamon paßt 😉 Wer aber die volle Erfahrung haben will, der kann auch einen Parameter für Fullscreen angeben:

xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1080 /f

Wer darüber Videos ansehen und/oder Skypen will, der muß zwei Dinge haben: einen Server der das anbietet und folgende Parameter:

xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1080 /f  /microphone:sys:alsa /sound:sys:alsa /compression-level:2

Aber erwartet da jetzt nicht zu viel. Bei Tests gab es da leichte Bandbreitenprobleme über DSL.

Die nächste Frage dürfte sein, wieso man das in die Konsole hacken soll. Sagen wir es mal so, die meisten getesteten DesktopUIs waren nicht wirklich brauchbar. Ich empfehle Euch ohnehin für eine zügige Verbindung ein Desktopfile pro Verbindung:

[Desktop Entry]
Version=1.0
Name=Arbeitsplatz2
GenericName=RemoteTool
Comment=FreeRPD Client
Exec=xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1080 /f  /microphone:sys:alsa /sound:sys:alsa /compression-level:2
Icon=/home/username/.local/share/icons/freerdp.svg
Terminal=false
Type=Application
StartupNotify=false
Categories=Network;
Keywords=Arbeitsplatz;rdp;freerdp;internet;
X-Desktop-File-Install-Version=0.21
Name[de_DE]=Arbeitsplatz2

Wenn es noch ein automatischer Tunnel sein soll, müßt Ihr ein Shellscript schreiben und das aufrufen. Ab hier könnt Ihr auf einen beliebigen Windows oder Linux RDP Server zugreifen.

XRDP – Der RDP Server

Kommen wir zum schwierigen Teil der Aktion: Der eigene Server.

Eigentlich es ziemlich einfach, nur die Details sind ein Problem. XRDP ist glücklicherweise bei Fedora dabei. Installiert bekommt man es also einfach mit :

sudo dnf install xrdp

zum Starten ist auch nicht viel nötig:

sudo systemctl start xrdp

Aber Ton versucht man vergebens zu aktivieren, denn die nötigen Pulseaudiomodule liegen dem Programm bei Fedora seit einiger Zeit nicht mehr bei. Ich habe versucht die für Fedora 30 zu kompilieren, keine Chance.

Bei Fedora 31 sieht die Sache ein klein bisschen anders aus. Hier ist bereits PulseAudio 13 im Einsatz, wo Fedora 30 noch 12 benutzt. Der F30 Build von PulseAudio 13 wurde aus einem unerklärlichen Grund in die Mülltonne verschoben, ich tippe mal darauf, daß nicht alle anderen Pakete mitziehen wollten oder konnten.

Da es auch Für PulseAudio 13 keine Fedora Module für XRDP gibt, müssen wir hier kreativ werden 🙂 Wir leihen es uns bei einer anderen Distribution aus:

wget http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/pulseaudio-module-xrdp-0.4-alt1.x86_64.rpm
rpm -i ./pulseaudio-module-xrdp-0.4-alt1.x86_64.rpm

Jetzt kann Euer Fedora 31 auch den Sound liefern.

Die richtige Desktopwahl

So, Ihr habt Euren Server laufen und jetzt verbindet Ihr Euch mit XFreeRDP dahin. Ihr werdet jetzt abhängig von dem Desktopspin den Ihr installiert habt, entweder einen Erfolg vermelden können (GNOME) oder einen schwarzen Bildschirm sehen und nicht mehr ausloggen können (Cinnamon). Die anderen Desktops habe ich nicht ausprobiert, aber Gerüchten zufolge, sollen die durchweg „gehen“.

Um sicher zugehen, daß Ihr eine Umgebung bekommt, die auch läuft, legt Ihr im HOME vom Benutzer den Ihr einloggen wollt eine Datei namens .Xclients an, die „gnome-session“ als Inhalt und u+x als Dateiattribute hat:

echo „gnome-session“ > ~/.Xclients
chmod u+x ~/.Xclients

Voraussetzung ist, daß Gnome auch installiert ist. Falls das nicht der Fall ist, könnte das helfen:

dnf install gnome-desktop3

Da sollte der ganze Rattenschwanz an Abhängigkeiten kommen. Alternativ schreibt Ihr Euren Desktop in die Datei rein. Eine Liste mit passenden Anweisungen finden Ihr im Netz.

Wieso empfehle ich dann Gnome?

Weil das nicht über die fehlende Hardwarebeschleunigung meckert, wie andere Desktops das tun ( und dann nicht richtig funktionieren ). Außerdem ist die schlichte Deko des Desktops sehr hilfreich um Bandbreite einzusparen, was die Sache reaktiver macht. Im eigenen LAN ist das natürlich komplett egal.

Ich rate bei DSL Verbindungen dazu die Animationen des Desktops zu deaktivieren. Man kann das auch im XFreeRDP als Schalter mitteilen, aber direkt im Gnome ist es vermutlich „nachvollziehbarer“ für den Desktop.

Jetzt könnt Ihr loslegen.

Ein kleiner Sicherheitshinweis noch: Paßt bitte auf, daß Ihr nicht aus Versehen den Server runterfahrt, statt die Usersession zu beenden, daß kann sehr schmerzhaft werden 🙂 Gerade bei Gnome liegen die Funktionen dicht beisammen und aus Gewohnheit verklickt man sich da schnell. Also Obacht!

Android

Oh ja, es gibt auch eine Android XFreeRDP Clienten Version und je nach Eurem Android, kann die ggf. nur gebrochene Krypto. Wenn das der Fall ist, laßt es lieber, weil Eurer Tablet dann auch leistungsmäßig nicht ausreicht um das brauchbar zu benutzen. Falls Ihr diese lieb gemeinte Warnung ignorieren wollt, xrdp.ini ist Eure Anlaufstelle:

/etc/xrdp/xrdp.ini :

ssl_protocols=TLSv1, TLSv1.1, TLSv1.2, TLSv1.3v; set TLS cipher suites

Es dürfte klar sein, daß das im != Privaten Umfeld nicht eingesetzt werden darf, da Artikel 32 DSGVO das verbietet.

Dann wünsche ich jetzt allen Karnevalsfreunden unter Euch, die morgen zum Shoduvel nach Braunschweig kommen: Alles Gute in der Regenschlacht und verabschiede mich für heute 🙂

Linux: Mehr Tester für Fedora!

Das Wort zum Sonntag

„Moin, Moin liebes Fedoravolk,

Schämt Euch! Ja…schämt Euch in Grund und Boden!
Ihr wollt alles immer für lau, aber so läuft das nicht!
Eure Taten sollen für Euch die Rechnung bezahlen,
deswegen TESTET! TESTET! TESTET! “
(Zitat: von Manager Bodhi, 20-20 )

So, oder so ähnlich, hätte das wohl geklungen, wenn Linux eine Religion wäre und der örtliche Glaubensvertreter Euch in den Allerwertesten treten wollte. Glück für Euch, Linux ist keine Religion. Nichts desto trotz, könntet Ihr ruhig mehr für Euch selbst tun und öfters mal zumindest bei sicherheitskritischen Sachen neue Updates testen!

Das Firefox 73.0-2 Update für Fedora 30 hing bis heute morgen 9.35 Uhr immer noch im Testbereich rum, wohingegen das gleiche Paket für F31 schon nach Minuten genug Testergebnisse zusammen hatte und bereits ins Stable gerutscht ist.

Koji and Bodhi in a Nutshell

Damit sich mehr Benutzer finden, die Tests mit Auswirkungen machen, sei am Beispiel von Firefox erklärt, wie man da als normaler Benutzer helfen kann:

Das ist der Testfall für Firefox 73.0-2 für Fedora 30 im BODHI System:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-4e1ba1a692

Wenn man die Seite aufruft, sieht man als erstes die Installationsanleitung:

Man sieht eine Testfallliste im Bodhi interfaceDie spannende Frage ist jetzt natürlich, wie kommt man überhaupt an den Links zu den Updates ran?

Dazu ruft man die Webseite ohne irgendetwas auf, z.b. so:

https://bodhi.fedoraproject.org/updates/

Ihr findet eine Suchmaske rechts oben:

Man sieht eine Liste mit Updates, welche genau, ist für das Thema komplett egal.Einfach „Firefox“ eingeben oder durch die Liste scrollen(aber das dauert etwas).

Updates sind intern eingeteilt in normale Programme und welche, die zum CritPath, also den kritischen Programmen, zählen. Firefox als „der“ Browser ist ein CritPath Programm, das Genologie Programm dagegen, ist nicht kritisch für den täglichen Betrieb beim Enduser, also ein normales Programm.

Testfälle

Entsprechend gibt es diverse Testfälle, die für solche Updates neben dem obligatorischen „Es startet überhaupt“ gibt. Für Firefox wären das diese drei:

Amn sieht einen ordentlich gemachten Test eines Testers von FirefoxEs gibt bei anderen Programmen auch welche mit deutlich mehr Testfällen. Der Maintainer kann auch spezielle Testfälle hinzufügen, wenn bestimmte Neuerungen das erfordern sollten um die Kompatibilität mit dem bisherigen Datenbestand zu sichern.

Die drei Fälle hier sind also „Addons: funktioniert die Addonseite, sind alle Addons da, kann man welche installieren“, „Browser: Kann man damit Webseiten aufrufen, gibts Probleme bei der Darstellung usw.“ und „Media: kann man Filme, Musik, Bilder ansehen und anhören.“

Wie man oben sehen kann, hat der Tester für alle drei grünes Licht gegeben, aber einiges anzumerken gehabt. Offensichtlich hat er den Test ernster genommen als Andere, die diese Testfälle nicht geprüft haben. Wenn man hier Tests macht, sollte man auf keinen Fall Testergebnisse fälschen, das bringt rein gar nichts, für niemanden.

Insgesamt sind min. 3 positive „Karma+1“ Wertungen nötig um ein Update als lauffähig zu markieren. Schauen wir uns mal an, wie die anderen Tester gewertet haben:

Das "Testergebnis" anderen Menschen, leider nicht ganz so penibel wie im vorherigen Fall. Nur einer der zwei Anderen hat den Browsertest gemacht und gewertet, daß er funktioniert ( der Firefox ). Die anderen Tests haben sich die zwei einfach erspart. Rechts oben auf dem Bild seht Ihr noch die automatisch durchgeführten Funktionstests und da hat das Update 3 nicht bestanden. Jetzt darf der Maintainer entscheiden, ob das missionskritische Fehler sind oder nur formale Fehler, und diese dann überstimmen.

Die Auswertung

Wenn keine automatischen Fehlerergebnisse vorliegen und das Karma +3 erreicht hat, wird dem Maintainer geraten und erlaubt, das Update ins Stable zu schieben. Das kann in Notfällen auch überstimmt werden durch den Maintainer, wenn z.b. die Hütte schon brennt, sollte man das Feuerwehrauto vielleicht nicht erst noch testen, sondern nur zusehen, daß Wasser im Tank ist. Das Äquivalent bei Software ist ein Remote-Exploit, der in der Wildnis (Internet) bereits zu der Lücke kursiert und PCs infiziert. Da ist es natürlich besser, wenn das aktualisierte Programm gar nicht mehr geht, statt die Leute weiter der Gefahr auszusetzen gehackt zu werden.

Ihr könnt mir glauben, wenn ich Euch sage, daß sich da keiner eine leichte Entscheidung macht. Desöfteren brauchte es massives Schubsen, daß Updates ins Stable gepusht wurden, um schlimmeres zu verhindern.

Karma +3

Ihr habt jetzt gelernt, daß es nur 3 positiver Tests bedarf um ein Update an die User raus zuschicken ( Umschreibung für „ins Stable schieben“ ).

Es hat bei FF73 für F30 satte 2 Tage gebraucht, bis 3 Leute einen Test gemacht hatten. Wenn man bedenkt, daß es sich um ein kritisches Sicherheitsproblem in Firefox gehandelt hat, ist das eher armseelig(für die Menschheit). 3 Menschen von 8.000.000.000 oder auch 0,000000037% der Menschheit.

Dafür das Fedora in den Jahren 2016-2018 4 Millionen Abrufe von Updates pro Monat hatte, Spiegelserver bei Unis nicht miteinbezogen, sollte man doch annehmen, daß es ein paar mehr Benutzer gibt, die da mal 3 Minuten für einen Test übrig haben, besonders, wenn es um Ihre persönliche Sicherheit geht, oder?

Wie wird man jetzt überhaupt Tester?

Jetzt der Teil, der für Mensch Nr. 4 aufwärts gedacht ist, die Antwort auf die Frage, wie man denn Tester werden kann. Ihr braucht: das passende OS für Euren Test ( Fedora 30/31 ) und ein Emailprogramm.

Die Emailaddresse braucht es zum Anmelden bei Fedora, denn Tester bekommen auch Emails mit Updates zu dem, was sie da testen ins Haus. Das ist schon daher wichtig, weil man so sieht, ob man etwas vergessen hat zu testen. Sollte einem da ein Fehler unterlaufen sein, kann man sein Testergebnis auch nachbessern, selbst wenn das Update dann zurückgezogen wird:  Karma < -2 .

Wenn man sich hier angemeldet hat:

Die Loginmaske vom FAS System zu Anmelden, nichts spannendes, wenn man es nicht sehen kann.kann man schon loslegen. „Sign up now“ ist der Knopf für Euch, wenn Ihr noch keinen Login zum Fedora Authentication System „FAS“ habt. Mit so einem FAS Login kann man auch bei ASKFEDORA mitmachen, also der Plattform, die Fragen von Benutzern an Benutzer unterstützt. Und das wars schon. Mehr Aufwand ist nicht nötig um zu helfen.

Und was ist jetzt Koji?

Das ist i.d.R. meine Quelle, wenn ich wissen will, ob da schon eine Testversion unterwegs ist, oder nicht. Selbst wenn die Testversion den Test nicht bestanden hat oder aus anderen Gründen zurückgestellt wurde, kann man dort alle bekannten Versionen finden und downloaden.

Koji findet Ihr unter dieser Adresse: https://koji.fedoraproject.org/

Für Firefox sieht das derzeit so aus:

Eine Liste mit Updates von Fedora zu Firefox in verschiedenen Stadien und Versionen. Wer die Seite mit einem Screenreader aufsucht, kann am Namen der Updates genau erkennen um welche Version es sich handelt.Wie man leicht erkennen kann, kommt das selbst bei renommierten Programmen vor, das man die nicht gebaut bekommt ( rot ). Jeden der Builds oben könnt Ihr dort passend für Euren PC ( OS+Architektur) runterladen.

Da kann man z.b. auch so Sachen machen, wie „mit FF 69 liefs noch, aber ich habe meine Daten nicht exportiert vor dem Update“ schon zieht man sich die alte Version, installiert diese, macht noch alle nötigen Anpassungen an seinen Daten zum Export und updated dann wieder auf die aktuelle Version hoch.

Auf welchem anderen OS kann man das schon machen? 😉

„Liebes Aldi, Deine Kunden können Dich kaum noch erreichen“

Folgenden Kundenbrief habe ich an Aldi geschickt, weil die Trampelpfade vom Ringgleis aus von einem Gartenbauunternehmen abgesperrt wurden, da nun dort bepflanzt wir. Verständlich, daß da keiner durchlaufen soll, aber wie hatte sich Aldi  bitte vorgestellt, daß man dann noch hinkommt?

„Liebes Aldi, Deine Kunden können Dich kaum noch erreichen“

Die Masse der Einkäufer kommt aus dem Wohngebiet, daß jetzt von der Baustelle abgeschnitten ist. Ohne einen riesigen Umweg, kommt man da nicht mehr hin. Das Aldi nicht viel von den örtlichen Gegebenheiten weiß, wurde jüngst deutlich, als eine Werbeagantur Hinweisschildern mit wegtechnisch unmöglichen Strecken durch bordsteinhohe Straßenbahnbegrenzungen (und querenden Straßenbahnen 😉 ) vom alten zum neuen Standort aufgehängt hat. Wozu gibts eigentlich Google Maps? 😀

Hier mein Brief, natürlich extra wehleidig, für die ältere Bevölkerung.

„Filiale: Hamburgerstraße ehemals Mittelweg, in Braunschweig

Seite 2 Tagen kann man aus dem Wohngebiet Mittwelweg nicht mehr zu Aldi gelangen, ohne eine Outdoorkletterausrüstung zu benutzen. Der Aldimarkt befindet sich vom Wohngebiet aus hinter einer Baustelle. Bis vor zwei Tagen war ein Zugang über den Ringgleisradweg und ein bisschen Trampfelpfad möglich. Dies wurde nun durch Baumaßnahmen unterbunden.

Auch die zweite Möglichkeit, durch eine Baustraße zu Aldi zugelangen, schlägt jetzt mit unter fehl, weil der Weg nur noch einem See gleicht bzw. das Tor zu der Straße geschlossen wurde.

Einen direkten Weg zu dem Markt gibt es für die Anwohner, die den Mark bislang genutzt haben, nicht mehr, ohne um das gesamte Baugelände zu fahren und dort mit dem Auto einzukaufen.

Fangfrage: Hätte man das nicht VOR dem Umzug mal klären müssen, wie denn die Kunden in den Markt kommen sollen, OHNE zur Umweltsau zu werden? Man wird jetzt also bestraft, weil man zu Fuß einkaufen geht. Wie Sie auf einer Karte der Gegend leicht erkennen können, verdoppelt/dreifacht sich der Fußweg, wenn man vom Mittelweg kommt,. was die Masse der bisherigen Kunden ausmachen dürfte.

Daher bemühen Sie Sich doch mal bitte um eine sinnvolle Lösung z.b. teeren der Baustraße (nebst Nivellierung wegen des Sees).“

Das hier ist das Bild, daß ich von dem See aufnehmen konnte. Es ist der derzeit einzige Weg und da muß man dann schon Stiefel mitbringen:

Wem die Begrünungsmaßnahmen egal sind, der trampelt halt die Böschungen hoch. Sowas wäre mit etwas Nachdenken aller Beteiligten dann leicht vermeidbar gewesen.

 

 

Kleines „Ups“ beim Fedorateam

Aus der Schmunzelecke: „Ups, Fedora 32 ist ja schon da“

„Federa 32 ist da“

Einigen Usern von Fedora wurden heute morgen Upgradehinweise auf Fedora 32 eingeblendet. Wer sich jetzt wundert, daß der Releasezeitpunkt noch gar nicht erreicht ist, der liegt richtig 🙂 Das Team um A. Williamson hatte die Ursache zwar schon nach 45min behoben, aber aufgrund diversen Cachings auf dem Weg zum Endnutzer, wurde der Hinweis auf die erst im Sommer erscheinende Fedora Version 32 stundenlang angezeigt.

Da ich auch einige weniger eingeweihte Menschen mit Linux betreue, bin ich froh, daß es für uns in der Nacht ablief und die Meldung folglich keiner bemerkt hat. Wenn das Upgrade auf 32 in dem Zustand erstmal gestartet worden wäre, wäre dem PC-System vermutlich nicht mehr zu helfen gewesen. Schwein gehabt 😀

 

 

Firefox 73.0 für FC30 und FC31 verfügbar

Es ist mal wieder soweit, eine Sicherheitslücke in Firefox und Thunderbird ( da nicht dramatisch mangels Scripting ) zwingt Euch zu einem Update. Ja, „Euch“, weil ich habe schon 😉

Firefox <73.0 mit Sicherheitslücken

Memory Corruption, Sicherheitslücke, wenn Firefox PDF Reader spielt(ARGS!) und eine RCE Schwachstelle, bei der ein Angreifer Code in Firefox ausführen kann ( und nicht nur in der Webseite im Firefox 😉 ) sind nur einige der Löcher die damit gestopft werden. Kleine Liste:

Mozilla Foundation Security Advisory 2020-05
Security Vulnerabilities fixed in Firefox 73

Announced February 11, 2020
Impact high
Products Firefox
Fixed in Firefox 73

#CVE-2020-6796: Missing bounds check on shared memory read in the parent process

A content process could have modified shared memory relating to crash reporting information, crash itself, and cause an out-of-bound write. This could have caused memory corruption and a potentially exploitable crash.
References

#CVE-2020-6797: Extensions granted downloads.open permission could open arbitrary applications on Mac OSX

By downloading a file with the .fileloc extension, a semi-privileged extension could launch an arbitrary application on the user’s computer. The attacker is restricted as they are unable to download non-quarantined files or supply command line arguments to the application, limiting the impact.
Note: this issue only occurs on Mac OSX. Other operating systems are unaffected.
References

#CVE-2020-6798: Incorrect parsing of template tag could result in JavaScript injection

If a <template> tag was used in a <select%gt; tag, the parser could be confused and allow JavaScript parsing and execution when it should not be allowed. A site that relied on the browser behaving correctly could suffer a cross-site scripting vulnerability as a result.
References

#CVE-2020-6799: Arbitrary code execution when opening pdf links from other applications, when Firefox is configured as default pdf reader

Command line arguments could have been injected during Firefox invocation as a shell handler for certain unsupported file types. This required Firefox to be configured as the default handler for a given file type and for a file downloaded to be opened in a third party application that insufficiently sanitized URL data. In that situation, clicking a link in the third party application could have been used to retrieve and execute files whose location was supplied through command line arguments.
Note: This issue only affects Windows operating systems and when Firefox is configured as the default handler for non-default filetypes. Other operating systems are unaffected.
References

#CVE-2020-6800: Memory safety bugs fixed in Firefox 73 and Firefox ESR 68.5

Mozilla developers and community members Raul Gurzau, Tyson Smith, Bob Clary, Liz Henry, and Christian Holler reported memory safety bugs present in Firefox 72 and Firefox ESR 68.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.
References

# Memory safety bugs fixed in Firefox 73 and Firefox ESR 68.5

Wenn Ihr Euch die Update holen wollt, bevor die automatisch kommen, hier kann man Sie passend runterladen:

FC30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1459513

FC31: https://koji.fedoraproject.org/koji/buildinfo?buildID=1459512