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 )