Sicherheitslücke in RPM: alte Keys werden nicht ungültig

Wie ZDNET gerade berichtet, haben RPM / DNF System wie Fedora, CentOS , RHEL und andere ein kleines Problem mit einer möglichen Supply-Chain-Attack.

Sicherheitslücke in RPM: alte Keys werden nicht ungültig

RPM Pakete aus Distro Repos werden i.d.R. signiert mit dem Key der jeweiligen Distro. RPM / DNF prüfen nach dem Download die Signatur des Pakets und nur wenn die gültig ist, wird das Paket installiert oder aktualisiert.

Die Prüfung ist leider nicht vollständig, weil alte Schlüssel nicht ungültig werden, da keine Revocationliste gefragt wird, ob der Key nicht zurückgezogen oder abgelaufen ist.

Das führt zu einer Supply-Chain-Attacke die uns allen dumm auf die Füsse fallen kann, wenn jemand die Repo Mirrors knacken sollte um dort geänderte Pakete mit alten Keysignaturen zu versehen. Damit wäre die Sicherheit der ganzen Installation gefährdet. Erschweredn kommt hinzu das immer noch unsignierte Pakete akzeptiert werden, auch wenn die GPG Signaturenprüfung aktiviert ist, meinen jedenfalls die Finder der Lücke.

Zwei Workarounds sind denkbar:

  1. Mirrorliste der Repos abschalten und nur noch die Hauptserver von Fedora /CentOs/ RHEL benutzen. Temporär wäre das eine Maßnahme, aber es belastet die Hauptserver kräftig.
  2. Die alten Keys vom System entfernen, dann sind die Signaturen nicht prüfbar => Problem erst einmal gelöst, außer es lassen sich wirklich unsignierte Pakete installieren, das wäre fatal.

Quelle: https://www.zdnet.com/article/major-linux-rpm-problem-uncovered/

Fedora: wie man mit RPM sein System auf Integrität prüft.

Heute geht es um Dateiintegrität und wie man das mit RPM prüft und ggf. behebt. Grund ist das Pinephone.

Fedora: wie man mit RPM sein System auf Integrität prüft.

Wenn man sein Pinephone zum ersten mal bootet, startet es mit dem Image auf der internen Storage mmcblk2. Will man etwas anderes Booten, so steckt man eine SD Karte rein, auf dem das Bootimage drauf ist. Das ist gerade am Anfang, wenn man viel Testet eine normale Sache, weil man die MicroSD Karte leicht wieder mit einem SD-Kartenreader am PC neu bespielen kann.

Wenn man aber zu an einen Punkt gekommen ist, wo das System gut genug funktioniert, möchte man es auf die interne Speicherkarte kopieren. Das könnt Ihr via rsync machen, oder Ihr kopiert die SD-Karte mit dem Tool dd rüber. Das hat aber einen Haken: Von dem System habt Ihr gerade gebootet und das läuft noch. Da man die Karte im laufenden Betrieb nicht wechseln sollte, steht Ihr vor einem Problem. Rsync umgeht das, aber Systemfiles lassen sich nicht so einfach syncen. Würde man so z.b. ein Fedora 33 auf ein anderes Fedora 33 syncen, würde es vermutlich laufen, aber (wie hier) ein Fedora auf Manjaro Syncen, geht sehr wahrscheinlich voll in die Hose.

Wenn wir also dd benutzen steigt zwar die Erfolgschance, aber ein Datenverlust steht im RAM, weil die Programme auf der Partition rumwerkeln und die sich beim Kopieren ändern. Also am besten ALLES was geht beenden: Desktop, Services, alles bis auf SSHd und das Netzwerk.

Schritt 1 – Ermitteln was drauf ist

Dazu führt Ihr „rpm -qa > rpms“ aus. Nicht vergessen das File nachher wieder zu löschen.

Schritt 2 – jedes Paket prüfen

Dazu brauchen wir awk und ein klein wenig Bashmagie:

awk < rpms ‚{print „rpm -V –nolinkto –nomtime –nomode –nouser –nogroup –nordev –nodeps „$1;}‘ | bash > log

Das liest die Liste der RPMs Zeile-für-Zeile ein und prüft das Paket, ob die Checksummen mit den Dateien übereinstimmen. Einige Tests sind absichtlich abgeschaltet worden, weil für den Test, ob eine Datei beschädigt ist oder nicht, nicht nötig. Ob ich da mal dran war und die absichtlich verändert habe, war nicht die Aufgabe, kann man so aber auch machen, wenn man die –no Flags weglässt. „–nodeps“ sollte man aber drin lassen, weil sonst jedes Paket immer mit allen Abhängigkeiten geprüft wird und wir prüfen eh alle einzeln 😉

Schritt 3 – Defekte Dateien finden

Da wir in Schritt 2 eine Log-Datei angelegt haben, werten wir die aus und lassen uns gleich die Paketnamen der defekten Dateien geben. Das „sort -u“ wirft doppelte raus:

grep „\.5\.\.“ log | grep -v “ c “ | grep -v “ d „| grep -v ^S | awk ‚{print „rpm -qf „$2;}‘ | bash | sort -u

.5… ist die Ausgabe, wenn die Datei beschädigt ist und z.b. keine Configdatei ist. Configs können sich natürlich jederzeit ändern, deswegen sind die nicht gleich defekt.

Ein paar Beispiele was die Ausgaben so meinen:

S.5…… c /etc/ssh/sshd_config  Datei hat andere Checksumme, ist aber eine Configdatei
fehlend d /usr/share/man/fr/man1/manconv.1.gz Datei ist eine Dokumentation, nicht tragisch, wenn die nicht da ist.
fehlend /boot/efi/overlays/adau1977-adc.dtbo Datei fehlt und sollte aber da sein.
..5…… /usr/bin/mokutil Datei ist defekt und sollte ersetzt werden.

Schritt 4 – Reparieren

Nun haben wir eine Liste mit Paketnamen und müssen die nur noch reparieren. In meinem Fall waren es vier defekte Pakete:

dnf reinstall dcraw efibootmgr f2fs-tools mokutil -y

Das muß natürlich bei Euch so nicht passen, es könnte auch gut gehen oder andere Dateien betreffen!

Vom efibootmgr wissen wir jetzt, daß er gar nicht nötig ist auf einem Pinephone, weil das U-Boot benutzt und so gesehen kein EFI Bios vorhanden ist.

Ein Wort noch zum Pinephone:

Kopiert das System ruhig auf die interne Karte, weil das dann ca. 5x schneller ist: beim Booten, beim Runterfahren, Apps starten und updaten. Es lohnt sich wirklich.

Systemd: Aus den Wirren des Paketmanagements

„Aus den Wirren der Paketabhängigkeiten im Dschungel von Systemd“ man könnte einen Roman damit betiteln 🙂  Gestern abend, es war mal wieder Serverupdatezeit, flutschte eine Anzeige eines Fedora-Paketes, daß keinen Sinn machte, über den Bildschirm: qrencode-libs

QR Codes auf einem Server?

Ja, wenn man eine Webseite hat, die z.b. QR Codes ausgibt, weil eine HandyApp einen Bestätigungscode haben will, warum nicht. Dummerweise hatte dieser Server genau einen Job und der hatte nichts mit QR Codes zu tun. „Naja,ok, das wird jemand mal irgendwann für was ausprobiert haben… kann weg!“ denkste Dir so.. und dann kommt das Erwachen: „Wieso will dnf jetzt systemd löschen?“

$ sudo dnf erase qrencode-libs
[sudo] Passwort für  ….. :
Fehler:
Problem: The operation would result in removing the following protected packages: systemd

Das kommt so …

Der Systemd hat eine harte Abhängigkeit auf die lib von dem qrencoder :

$ rpm -q -R systemd | grep qrenc
libqrencode.so.3()(64bit)

ganz genau genommen ist es journalctl:

$ ldd /usr/bin/journalctl |grep qrenc
libqrencode.so.3 => /lib64/libqrencode.so.3 (0x00007fef36540000)

„Kann mir bitte einer erklären, wieso journalctl QR CODES bauen können müßte ?????“

Kann ja wohl nur ein Fehler sein 😉   Der Maintainer bei Redhat war da jetzt anderer Meinung:

What do you mean "wrongfully"? It's "rightfullly" linking against qrencode-libs because that functionality is used by journalctl.
While somewhat unfortunate, it's correct.

Steht aber allein da, denn auch bei Manjaro Linux ist das schon mal jemandem vor mir aufgefallen und siehe:

https://forum.manjaro.org/t/systemd-238-51-1-has-picked-up-a-dependency-on-qrencode/43070

Could this be due to a dirty chroot?

$ ldd `which journalctl`
	linux-vdso.so.1 (0x00007fff47fc9000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f55fd82e000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f55fd477000)
	libsystemd-shared-238.so => /usr/lib/systemd/libsystemd-shared-238.so (0x00007f55fd027000)
	libqrencode.so.4 => not found

I’m pretty certain journalctl doesn’t need qrencode?

Das sehe ich auch so, trotzdem habe ich mal etwas geforscht und die Ursache gefunden:

journalctl .c

#if HAVE_QRENCODE
/* If this is not an UTF-8 system don’t print any QR codes */
if (is_locale_utf8()) {
fputs(„\nTo transfer the verification key to your phone please scan the QR code below:\n\n“, stderr);
print_qr_code(stderr, seed, seed_size, n, arg_interval, hn, machine);
}
#endif

Jetzt wirds spannend:

Wozu wird das benutzt?

Um, wenn es ein UTF8-System ist UND der Code mit dem QR Support kompiliert wurde, einen Verifikations Schlüssel als QR CODE fürs Handy auszugeben, um mit dem Versiegelungs-Schlüssel abgesicherte Journaleinträge zu prüfen.

Das Verfahren heißt bei Systemd Forward Secure Sealing (FSS).  Keine Ahnung wer das Feature von Journald nutzt. Es klingt jedenfalls nach einer brauchbaren Idee, falls ein Hacker die Einträge manipuliert. Ich bezweifle aber stark, daß der Key dabei per QR Code an ein Handy übermittelt werden muß, statt per SCP an einen anderen Server.

Für diese eine Zeile Code da oben, die kaum jemand jemals einsetzen wird (Bitte Zahlen liefern, wer welche hat), immer noch diese Lib mit sich rumschleppen… was solls, GB sind billig  😉