Linux am Dienstag – Programm für den 31.8.2021

Sprechen wir doch mal über Sicherheitslücken, davon gibt es ja derzeit einige.

Linux am Dienstag – Programm für den 31.8.2021

Bei Linux am Dienstag am 31.8. 2021 geht es ab 19 Uhr u.a. um folgende Themen:

Linux wird 30!
OpenSSH – VPN mit SSH
OpenSSL – Buffer Overflow im SM2 Modul gefixt.
Security – Was ist eine XSS Schwachstelle?
Security – Was ist eine SQL Injection?

Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Kleine Anmerkung: Die bisherigen Vorträge findet man jetzt unter https://linux-am-dienstag.de/archiv/ .

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Im Gegensatz zum letzten Lokalbeitrag über Lebensmittel bei Aldi Nord, kommt heute ein weniger ekliges Thema dran … Woher weiß man, daß man mit dem Mailserver der Stadt Braunschweig spricht?

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Liebe IT-Verantworlichen der Stadt Braunschweig,

wie wir Euch 2018 schon einmal mitgeteilt haben, sind Eure SSL-Zertifikate im Mailserver nichts wert. Glauben Sie nicht? Bitte schön:

$ openssl s_client --connect mailin02.braunschweig.de:25 -starttls smtp -verify_hostname mailin02.braunschweig.de
CONNECTED(00000003)
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify return:1
---
Certificate chain
0 s:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
i:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = BSSUBCA02
---

Was bedeutet die Ausgabe?

Das jemand ein Zertifikat auf „mailin02.braunschweig.de“ ausgestellt hat und anstatt dies von einer anerkannten Autorität (CA) beglaubigen zu lassen, es mit einem anderen selbst gebauten Zertifikat und dessen Schlüssel unterschrieben hat. Das macht natürlich aus dem ersten Zertifikat mailin02.braunschweig.de auch kein anerkanntes Zertifikat, sondern nur ein weiteres Zert, dem man nicht vertrauen kann.

Das Emails bei der Stadt Braunschweig trotzdem eingehen, liegt einfach daran, daß derartige Fehler sooft vorkommen, daß wer ernsthaft die Autorität eines empfangenden Mailserver prüft, kaum noch Emails rausbekommt. Besser macht die Erkenntnis den Fall natürlich auch nicht, es bleibt ein Setupfehler.

Anders läge der Fall, wenn das Zert mit dem Kürzel BSSUBCA02 selbst von einer bekannten CA verifiziert und beglaubigt wäre. Das kann man aber nicht prüfen, weil das dafür nötige Zert nicht mitgeliefert wird. Pech.

Es bliebt also dabei, diesem Server kann man nicht glauben, daß er wirklich die Stadt Braunschweig repräsentiert.

Weiß hier A nicht, was B tut?

Wer sich mal die Webseite unter Braunschweig.de näher ansieht, findet dort ein Zert für „*.braunschweig.de“, ein sogenanntes Wildcard-Zertifikat. Dies ist für alle beliebigen Domainnamen gültig, auch für „mailin02.braunschweig.de„. Wieso man das dann nicht für den Mailserver nimmt, kann ich nicht beurteilen. Das Wildcard Zert ist nicht eingeschränkt auf das Web ( was gehen würde ), es kann also überall eingesetzt werden.

Basierend auf der Erfahrung mit der Stadt Wolfenbüttel ( gleich hier um die Ecke ), würde ich mich jetzt aus dem Fenster lehnen und behaupten, daß das IT-Managementsystem auf Windowsbasis, daß die Stadt einsetzen wird um deren Firewall und Mailserver zu verwalten, den Admins nur die Innenseite des Netzes anzeigt, aber nicht, was außen wirklich los ist. Ich vermute, intern wird schon seit einiger Zeit ein korrektes Zert angezeigt und das uns gezeigte Mailserverzert ist bloß ein Fragment eines Testsetups von früher.

Das „Root CA 2“ Zert der Stadt Braunschweig, ist scheinbar von 2016 und das „mailin02.braunschweig.de“ von 2017, aber mit einer Gültigkeit von 10 Jahren. Dies ist ein typisches Testsetup, denn normale Zertifikate werden nach 1-2 Jahren getauscht.

Firefox: Sicherheitsloch „Memory-Dump“

Im Zuge eines Bugreports für Jitsi Meet kam raus, daß die Speicherfunktion im Firefox Modul „about:memory“ nicht nur den eigenen Speicherinhalt, sondern wohl auch den von anderen Prozessen abspeichern kann. So oder so, muß man aufpassen, was man heraus gibt.

Firefox: Sicherheitsloch „Memory-Dump“

Eine aktuelle Instanz von Jitsi Meet führt zusammen mit der „Hintergrund Blur“ Funktion der Videokonferenzsoftware zu einem massiven Speicherverbrauch von Firefox, der das System nach einiger Zeit zum Swap-of-Death treiben kann. Ob und wann das passiert, hängt natürlich stark von Eurem PC-Setup ab. Bei mir waren es 16 GB Hauptspeicher, die Firefox in knapp 3 Stunden mit 8+ GB eigenem Speicher gefüllt hatte, der Rest war vom System und OBS belegt, als das Problem aus heiterem Himmel auftrat. Da es sich um das LPD Live-Streaming handelte, hatte ich zum Glück noch eine zweite OBS Instanz in der Hinterhand, die das Streaming dann direkt übernommen hat.

Im Zuge des Bugreports an Mozilla wurde ein Speicherdump angefordert, der allerdings (aller Wahrscheinlichkeit nach) auch Daten des laufenden Matrixclientens enthielt, sowie sensible Zugangsdaten, die Firefox gerade in Benutzung hatte. Die teilweise 190 MB großen Textfiles von Hand nach sensiblen Informationen zu durchsuchen würde viel zu lange dauern. Insgesamt sprechen wir hier über eine etwas weniger als 1 GB große Textfilesammlung.

URLs, Userids und Matrixdaten

In den Files habe ich besuchte URLs mit GET Parametern, UserIDs für Jitsi und sämtliche Nutzernamen von dem Clienten bekannten Matrixbenutzern gefunden. Da Firefox nur mit einem Testbenutzer in Kontakt kam, kann es fast unmöglich Firefox gewesen sein, dessen Speicher die Benutzerkennungen von anderen Matrixaccounts enthielt.

Ich kann Euch nur raten, diese Textfiles vor dem Übersenden an den Support von Mozilla in Augenschein zu nehmen, damit Euch nicht sensible Daten abhanden kommen. Wenn der Bugreport im Tracker nicht als „Security“ Report markiert ist, kann jeder diese Datenfiles runterladen und darin nach Herzenslust rumstöbern.

Am Wochenende hatte erst von Golem den neuen Firefox-Absturzreport als „positiv für andere Software-Projekte“ bezeichnet. Nachdem was in meinem Dump ( nicht vom Absturztool erzeugt ) drin war, glaube ich das sofort, nur bin ich da anderer Ansicht. Ein Browser ist heute ein sehr sensibles Stück Datenhalde, da kann man nicht mehr einfach alles zum Hersteller schicken und schon gar nicht von an dem Problem unbeteiligten Prozessen.

Kleiner Lacher am Rande: Das angeforderte „Mozilla-Regressiontool“ 4.0.17 muß wohl auch erst einmal gefixt werden, es crasht nämlich beim Start hart und schmeißt einen Coredump 😉


Fontconfig warning: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: unknown element „its:translateRule“
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ‚translate‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 5: invalid attribute ’selector‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚xmlns:its‘
Fontconfig error: „/etc/fonts/conf.d/90-synthetic.conf“, line 6: invalid attribute ‚version‘
Fontconfig error: Cannot load config file from /etc/fonts/fonts.conf
Fontconfig warning: FcPattern object weight does not accept value [0 205)
Speicherzugriffsfehler (Speicherabzug geschrieben)

Da ist wohl „einiges“ im Argen bei Mozilla 😉

Quelle: https://github.com/mozilla/mozregression/releases