Tag Archives: Leak

Linux am Dienstag: Nachlese 27.4.2021

Posted on by

Liebe „Linux am Dienstag“ – Teilnehmer: DANKE!

Linux am Dienstag: Nachlese 27.4.2021

Wir haben gestern Abend den bisherigen Besucherrekord überschritten, wir waren kurzfristig fünfreihig, dafür Danke 🙂

Wir sprachen über…

Unzulänglichkeiten im Deutschen Justizwesen in Fragen von IT-Angriffen
die Hausgabe von Bandit Level 7
die „Post Voting Society“ und „Post Choice Society“ (beides Blödsinn den sich ein Bundesinstitut ausgedacht hat )
die neuen Spamwelle durch den 3.2 Milliarden Passwörter und 2.18 Milliarden Emailadressen Leak
Firefox 88
„Die Uni Minnosata und der Versuch die Linuxgemeinde zu exploiten“
Sicherheitslücken im ach so sicheren RUST und das man jetzt alle Rustapps neu kompilieren muß
( Security fixes for CVE-2020-36323, CVE-2021-28876, CVE-2021-28878,CVE-2021-28879, and CVE-2021-31162. )
Sicherheitslücken im Kernel <= 5.11.15
(5.11.16: CVE-2021-29155 kernel: protection for sequences of pointer arithmetic operations against speculatively out-of-bounds loads can be bypassed to leak content of kernel memory)

Die beiden Hauptvorträge:

„Warum das Markieren von Spam Mist ist, und was man sonst tun könnte.“
„LPD 2021 Preview:  VeraCrypt und das Cloudlaufwerk – Daten sicher in der Cloud speichern“

können wir leider nicht verlinken, weil die nur mündlich gehalten, bzw. erst am 15.5. zusehen seien sollen 😉
Wer den Spamvortrag nochmal hören möchte, nächsten Dienstag am Star Wars Day kommt ein Rerun, diesmal mit Folien, für das bessere Verständnis.

Zum Tod von Dan Kaminsky

Leider mußte ich gestern hören, daß Dan Kaminsky an einer Komplikation seines Diabetes viel zu früh verstorben ist. Er wurde gerade einmal 42.

Dan, wir alle werden Dich vermissen!

Dan war einer der ganz großen Unterhalter auf den CCC Veranstaltungen, die ich besucht habe. Ich hatte auch das Vergnügen ihn bei einer Proftpd-Sicherheitslücke konsultieren zu können, die ich später als Vortrag beim CCC eingereicht habe. Seine DNS Spielereien werde ich auch nie vergessen.

Daher wird es nächste Woche einen Gedenkevent zum Thema „Was kann man mit DNS eigentlich nicht machen????!!?!!?“ geben.

 

Ein Hinweis in eigener Sache

Wir nehmen wissentlich keine Treffen auf Video auf, es sind keine PODCasts die dort ablaufen. Ihr müsst leider Live dabei sein, oder verpasst es. Vorträge, auch die auf Video vom kommenden LPD, werden dann auf der Linux am Dienstagseite verfügbar sein.

PHP.net Userdatenbank geleakt?

Posted on by

Vor 2 Wochen ging die Meldung rum, daß in den PHP-Code zwei Hintertüren eingebaut wurden. Dazu gibt es jetzt ein Update.

PHP.net Userdatenbank geleakt?

PHP Maintainer Nikita Popov hat in einem Update zu dem Einfügen von Hintertüren in den Code von PHP ein kleines Update gepostet. Seiner Meinung nach hatten die Angreifer Zugriff auf die Userdatenbank des Projekts bekommen und dann einen vergessenen Zugang zum Repository genutzt, um an allen sonstigen Buildeinrichtungen vorbei, den Code direkt ins Repository zu bekommen: „git-http-backend behind Apache2 Digest authentication against the master.php.net user database“

Ein sinngemäßes Zitat: „Ich wußte gar nicht, daß das geht.“ . Tja 🙂

Als „unverdächtige“ Benutzer hatten sich die Angreifer ausgerechnet die Accounts vom Erfinder von PHP Rasmus Lerdorf und Nikita Popov selbst ausgesucht. Ich vermute ja mal, daß war eine Ansage und kein Versuch die Sache gut zu verschleiern. Zur Zeit meint man bei PHP, daß deren hauseigenes Gitolite System an sich nicht kompromittiert wurde. Um ganz sicher zu sein, wird trotzdem alle neu aufgesetzt.

Auch als Konsequenz wurden die Passwörter erst einmal auf BCrypt umgestellt, was nach einem weiteren Leak den Login ziemlich erschweren dürfte. Die richtigen Fragen scheint man sich jedenfalls zustellen, z.B. wieso HTTP-Passwortauths überhaupt zugelassen waren, da diese als eher leicht zu knacken angesehen werden, wohingegen Public-Key Authentifizierung deutlich sicherer ist.

https://www.theregister.com/2021/04/07/update_on_php_source_code/

Nemo: kleines Datenspurenproblem

Posted on by

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.