Fedora: Wechsel zu Matrix im Gespräch

Eine zum kleinen Teil hitzige Diskussion in der Fedora-Mailingliste, um einen möglichen Wechsel von IRC als Kommunikationskanal hin zu Matrix, hat letzte Nacht zu einem kräftigen „Emailchat“ geführt.

Fedora: Wechsel zu Matrix im Gespräch

Hinweis: Die folgenden Zitate sind stark auf das wesentliche gekürzt, ebenso die Namen. Wer es nativ nachlesen möchte, müßte sich das Archiv der Mailingliste von Fedora ansehen.

Matthew Miller vom Fedora Führungsgremium weitete die Diskussion um die Idee des Fedora Council’s auf die Fedora Mailingliste aus. Dazu lud er zu einer Videokonferenz aller interessierten Personen ein. In dem Meeting soll besprochen werden, daß IRC als Kommunikationskanal abgelöst und zu Matrix als „besserem“ System gewechselt werden sollte. Der an sich gute Vorschlag, über die Idee etwas breiter zu diskutieren, löste sofort Panikreaktionen einiger Listenteilnehmer aus.

„No, please. IRC bridges need to be closed to force users to switch to Matrix.“ V. Z.

Ursprünglich geplant war eine Brücke zwischen Matrix und IRC zu nutzen und so beide Systeme mit ihrem jeweiligen Vorteil zu betreiben. Zwischenzeitlich rutschte aber jemandem der Begriff „Force“ im Sinne von „Zwingen“ raus, was schon nach wenigen Minuten zur Detonation führte 😉

„force“? You may have said the quiet bit aloud … R.

gefolgt von:

„force“? You may have said the quiet bit aloud …

yes, it got my attention too … D.P.

Matthew Miller konnte dann die beruhigen, die schon eine Verschwörung witterten:

„To be clear, V.Z. isn’t an insider to some secret decision here. I think you should just read this as enthusiasm.“ M.M.

Matthew konnte dann auch den Plan etwas näher belegen, da schon einige Untergruppen auf Matrix gewechselt waren und wohl gut Erfahrungen gemacht haben. Selbst Red Hat unterstützt den Wechsel, weil sie dann auch bei sich auf die Erfahrungen von Fedora zurückgreifen können. Fedora ist ja bekanntermaßen der Testballon von Red Hat.

2h20m nach dem Start läutete dann T.H. den ersten kräftigen Downer ein, als er seine Testergebnisse präsentierte:

„More amusingly one of them crashed as soon as I logged in and a second went into a „your window is too small mode“ as soon
as I resized it to match my IRC client.“ T.H

Die Situation beruhigte sich etwas, falls man bei einem „Chat“ über Email da überhaupt von sprechen kann. Man konnte sogar noch etwas über die Fensterbedienshortcuts lernen:

You don’t have to grab by the edge to resize, GNOME has useful features:

– winkey+left mouse button inside the window let you move it (no need to target header bar)
– winkey+middle mouse button inside window let you resize closest edge

M.C. hatte dann die gleiche Idee wie ich, nur mir fiel nicht mehr ein, wo ich das gesehen hatte:

„Enjoy: https://github.com/matrix-org/purple-matrix/“ M.C.

Mir war nämlich auch so, daß es einen Matrixbackend für Pidgin geben würde, wo mit sich die Crashe beim Start von Programmen auf Pidgin beschränken würde. Ich erwähne das nur, weil mein Pidgin auf dem Tablet, auch gern Crashmeldungen sendet 😉 Damit ist es den Matrixclienten mindestens gleichwertig 🙂

Die Diskussion wird dann im Web weitergeführt:

https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussion-for-the-fedora-council/24628

leider mit Discourse, und da hört es dann schon wieder auf. So blöd es klingt, aber die Matrixdiskussion im Discourse, könnte die Discourse Webseite bei Fedora dann überflüssig machen, weil die gleichen Features dann im selbstgehosteten Matrixserver wären, aus denen man Discourse benutzt hat 😀 Da wäre ich dann wieder dafür 😀

IMHO: Die Idee mit dem Matrixserver, zumal selbstgehostet, ist gar nicht blöd. Ich würde dies unterstützen, obwohl auch ich mal ein UUCP/IRC Dino war

 

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Nein, heute geht es nicht um Dichtung, eher um Undichtigkeiten in Betriebssystemen 😉

CVE-2020-15999: Der Kelch, der an Euch vorbei ging

Google’s Projekt Zero hat im Oktober eine Serie von kritischen Bugs offengelegt, mit deren Hilfe iOS, Android, Windows, Macs und Linuxsysteme übernommen werden konnten. Die Lücken sind so groß, daß Apple sogar noch Iphone 5s aktualisiert und die sind seit Jahren im End-of-Live.

Ein Blick auf eine dieser Lücken zeigte, daß diese auch für Linux vorhanden war, aber unter dem Radar bliebt: FreeType < 2.10.4

„Bug #1890210 – CVE-2020-15999 freetype: heap-based buffer overflow via malformed ttf files“

Red Hat hat dazu im Bugreport geschrieben:

„A flaw was found in freetype in the way it processes PNG images embedded into fonts. A crafted TTF file can lead to heap-based buffer overflow due to integer truncation in Load_SBit_Png function.“

Wer in den letzten Tagen die Updates verfolgt hat, weiß, daß es für Chrome, FireFox, Thunderbird eine schere Sicherheitslücke beim Webseitenaufruf gab. Über den Bug im FreeType, einer Font-Rendering-Engine, die auch und gerade in Webbrowsern genutzt wird, konnte mit Hilfe eines manipulierten Fontfiles, und da zählen auch WebFonts zu, das komplette System übernommen werden.

Diese Lücke betraf uns alle, und mit alle meine ich wirklich ALLE auf dem Planeten.

Wie kann eine so simple Sache wie einen Fontrendern, zu einer Systemübernahme führen? Das liegt daran, daß es sich hierbei wohl um den ersten Schritt in einer ganzen Exploitchain handelt. Hat man erstmal den Fuß im Chrome oder Firefox, muß man nur noch dort ausbrechen können und das war bei Chrome über einen Sandbox-Escape möglich. Danach findet sich im Kernel schon eine Schwachstelle, gerade bei Handies.

Von der Tragweite der Lücke mal abgesehen, rankt sich um die Google Veröffentlichung noch einiges andere. In der Szene munkelt man von „Spionagekram“, wozu auch paßt, daß keiner der Beteiligten dazu irgendwas sagen möchte. Nachdem der Exploit verbrannt ist, dürften die früheren Nutzer ziemlich sauer auf Google sein. Das Google uns aber nicht sagen kann, woher die Exploits stammen und wie Sie darauf aufmerksam wurden, spricht dafür, daß es ein „us-heimischer“ Dienst war, sonst wären die Antworten vermutlich anders. Aber, genaueres weiß man nicht, da keiner reden will.

Also feiert, daß ein Angriff weniger auf Euch möglich ist und wer von Euch Software schreibt, denkt bitte daran, wirklich sauber zu arbeiten, weil auch die unbedeutendste Lib einen immensen Schaden anrichten kann!

LUKS2: CVE-2020-14382 – out of bounds write

Zeit für ein Update von CryptSetup: CVE-2020-14382

LUKS2: CVE-2020-14382 – out of bounds write

CryptSetup ist das Tool, daß Luks Container, egal ob als Datei oder Festplatte, einhängt und/oder bearbeitet. Eine Lücke im Speicherhandling von CryptSetup kann von einem Angreifer ausgenutzt werden, indem er einen manipulierten Container einer anfälligen Version von CryptSetup präsentiert, was z.B. durch das Einstecken eines USB Sticks ausgelöst wird.

Die Lücke in CryptSetup sorgt dafür, daß weniger Speicher allokiert wird, als tatsächlich angegeben ist, aber von dem manipulierten Inhalt des Containers aufgrund mangelnder Grenzprüfungen, überschrieben werden kann. Damit gelangt ggf. Code an eine Stelle, die von einem anderen Prozess genutzt wird. Die Lücke CVE-2020-14382 kann also ggf. zu Arbitrary-Code-Execution führen, wenn es im System dumm läuft.

Daher empfehle ich Euch kurz mal nach dem Zustand Eures CryptSetup Befehls zu schauen und ggf. zu Updaten, denn auch wenn Ihr selbst keine Festplattenverschlüsslung benutzt, es reicht, daß das Paket auf dem System installiert ist und jemand einen USB Stick einsteckt.

Kleine Anmerkung zur Lage

Falls Ihr die Red Hat Securityliste lest, ist Euch auch aufgefallen, daß da heute ein ganzes Rudel (70+) Sicherheitsadvisories gekommen sind und die Bugs größtenteils Nummern aus 2018 und 2019 tragen? Ich glaube, da ist etwas arg schief gelaufen bei Red Hat.