🧠 Warum man Pakete prüfen sollte

(Und wie du dich vor manipulierten Updates schützt)

Wenn du Linux nutzt – egal ob Debian, Ubuntu, postmarketOS, Fedora oder andere Distributionen – installierst du Software immer als sogenannte Pakete:

.deb (Debian / Ubuntu)

.apk (postmarketOS / Alpine Linux)

.rpm (Fedora, Red Hat)

.tar.xz (Quellpakete, Releases auf GitHub usw.)

Damit du sicher sein kannst, dass diese Pakete echt sind, werden sie vom Entwickler oder vom Maintainer kryptografisch signiert – meistens mit GPG / OpenPGP.

Diese Signaturen stellen sicher, dass:

✔ das Paket vom richtigen Entwickler stammt
✔ es nicht manipuliert wurde (z. B. durch Malware)
✔ die Übertragung nicht abgefangen wurde

Das Prüfen von Signaturen gehört zu den wichtigsten Sicherheitsmechanismen im Linux-Universum.

🔍 Wie man die Echtheit prüft

(Beispiele für Debian, Ubuntu & postmarketOS)

Jede Linux-Distribution hat eigene Werkzeuge – aber die Prinzipien sind überall gleich.

🔹 1. Paketlisten aktualisieren (und Warnungen ernst nehmen)

Wenn du bei Debian/Ubuntu eingibst: sudo apt update

und du bekommst eine Warnung wie: W: GPG error: … The following signatures couldn’t be verified
dann heißt das:

❌ Die Signatur konnte nicht überprüft werden
❌ Das Paket ist möglicherweise unsicher
❌ Du solltest KEINE Updates installieren, bevor der Fehler behoben ist

Diese Warnungen NIE ignorieren – sie schützen dich vor manipulierten Repositories.

🔹 2. Vertrauenswürdige Schlüssel anzeigen

APT (Debian/Ubuntu) speichert alle Signaturen der Paketquellen hier: ls /etc/apt/trusted.gpg.d/

Jede Datei dort steht für einen Schlüssel, der für Updates vertraut wird.

Wenn hier ein Schlüssel fehlt → kann APT Updates nicht verifizieren.

🔹 3. Signatur manuell prüfen (z. B. bei Downloads von GitHub)

Wenn du ein .tar.xz oder .iso herunterlädst, findest du oft daneben:

eine Datei .asc (Signatur)

eine Datei .sha256 (Checksummen)

Du kannst damit prüfen:

🔸 Hash prüfen
sha256sum DATEI.iso

→ ergibt eine lange Zeichenkette
→ muss mit der Hersteller-SHA256 übereinstimmen

🔸 Signatur prüfen

gpg –verify DATEI.asc DATEI Wenn alles korrekt ist, erscheint:

✔ Good signature from “NAME DES ENTWICKLERS”

🔹 4. postmarketOS / Alpine Linux (apk-tools)

postmarketOS nutzt apk, nicht apt.

Du prüfst die Repository-Signaturen so:

Repository-Schlüssel anzeigen sudo apk policy
oder:
ls /etc/apk/keys/
Dort liegen die öffentlichen Schlüssel der Maintainer.

Wenn apk update bei dir sofort abbricht, kommt das meistens durch:

fehlende Schlüssel

beschädigte Schlüssel

falsche Zeitzone

falsches Datum des Systems

defekte Repository-Server

Das könnte gefixt werden, sobald du so weit bist.
Doch das würde in einem separaten Blogbeitrag erörtert werden.

🛡️ Warum das Prüfen so wichtig ist

In der Linux-Welt ist das Paket-System eines der sichersten der Welt.
Aber es hängt von dir ab, Warnungen ernst zu nehmen.

Wenn die Signatur nicht stimmt:

🚫 Kein Update installieren
🚫 Kein Paket anfassen
🚫 Repository überprüfen
🚫 Schlüssel aktualisieren

Nur so bleibt dein System wirklich sicher.

Und vor allem:

✔ Dein Server bei Hetzner oder sonstigen Hostern
✔ Dein Laptop
✔ Dein postmarketOS-Smartphone

sind dadurch besser geschützt als jedes Windows-System.

💡 Fazit
Das Prüfen von Paketen ist kein kompliziertes Hacker-Werkzeug, sondern ein eingebauter Schutzmechanismus in jeder Linux-Distribution.
Du brauchst nur:

die Warnungen zu verstehen

und angewöhnen, auf Signaturen zu achten

Dann kann dir fast nichts passieren.

Sicherheitswarnung für Fedora Linux 40: Wichtige Informationen zur xz-Bibliothek

**Sicherheitswarnung für Fedora Linux 40: Wichtige Informationen zur xz-Bibliothek**

**Schlagworte: Gemeinschaft, Infrastruktur, Plattform, Sicherheit**

**Aktualisiert am 30. März 2024**: Wir haben festgestellt, dass die Fedora Linux 40 Beta-Version zwei betroffene Versionen der xz-Bibliotheken enthält – xz-libs-5.6.0-1.fc40.x86_64.rpm und xz-libs-5.6.0-2.fc40.x86_64.rpm. Derzeit scheint Fedora 40 Linux nicht von dem tatsächlichen Malware-Exploit betroffen zu sein, dennoch raten wir allen Nutzern der Fedora 40 Linux Beta-Version, auf die 5.4.x-Versionen zurückzugehen.

**Hinweis der Redaktion**: Dieser Beitrag wurde aktualisiert, um die betroffenen Fedora Linux-Versionen klarer zu benennen und zusätzliche Minderungsmaßnahmen hinzuzufügen.

Gestern haben das Information Risk and Security Team sowie das Product Security Team von Red Hat erfahren, dass die neuesten Versionen der „xz“ Tools und Bibliotheken schädlichen Code enthalten, der offenbar darauf ausgelegt ist, unbefugten Zugriff zu ermöglichen. Insbesondere ist dieser Code in den Versionen 5.6.0 und 5.6.1 der Bibliotheken vorhanden. Fedora Linux 40-Nutzer könnten je nach Zeitpunkt der Systemaktualisierung Version 5.6.0 erhalten haben. Nutzer von Fedora Rawhide könnten Version 5.6.0 oder 5.6.1 erhalten haben. Diese Schwachstelle wurde als CVE-2024-3094 eingestuft.

**BITTE STELLEN SIE UMGEHEND DIE NUTZUNG ALLER INSTANZEN VON FEDORA RAWHIDE für Arbeit oder persönliche Aktivitäten EIN.** Fedora Rawhide wird in Kürze auf xz-5.4.x zurückgesetzt, und danach können Fedora Rawhide-Instanzen sicher neu eingesetzt werden. Beachten Sie, dass Fedora Rawhide die Entwicklungsverteilung von Fedora Linux ist und als Basis für zukünftige Fedora Linux Builds dient (in diesem Fall für das noch nicht veröffentlichte Fedora Linux 41).

Derzeit wurde nicht festgestellt, dass die Fedora Linux 40 Builds kompromittiert wurden. Wir glauben, dass die schädliche Codeeinspritzung in diesen Builds nicht wirksam wurde. Dennoch sollten Fedora Linux 40-Nutzer sicherheitshalber auf einen 5.4 Build herabstufen. Ein Update, das xz auf 5.4.x zurücksetzt, wurde kürzlich veröffentlicht und wird Fedora Linux 40-Nutzern über das normale Update-System zur Verfügung gestellt. Besorgte Nutzer können das Update durch die Anweisungen unter [Fedora Update Portal](https://bodhi.fedoraproject.org/updates/FEDORA-2024-d02c7bb266) erzwingen.

**Was ist xz?**

xz ist ein Datenkompressionsformat für allgemeine Zwecke, das in nahezu jeder Linux-Distribution vorhanden ist, sowohl in Community-Projekten als auch in kommerziellen Produktverteilungen. Im Wesentlichen hilft es, große Dateiformate zu komprimieren (und dann zu dekomprimieren), um sie in kleineren, handlicheren Größen für die gemeinsame Nutzung via Dateiübertragungen bereitzustellen.

**Was ist der schädliche Code?**

Die schädliche Injektion, die in den xz-Versionen 5.6.0 und 5.6.1 vorhanden ist, ist verschleiert und nur vollständig im Download-Paket enthalten – die Git-Verteilung fehlt das M4-Makro, das den Bau des schädlichen Codes auslöst. Die Artefakte der zweiten Stufe sind im Git-Repository für die Injektion während der Bauzeit vorhanden, falls das schädliche M4-Makro vorhanden ist.

Das resultierende schädliche Build stört die Authentifizierung in sshd über systemd. SSH ist ein häufig verwendetes Protokoll zum Fernverbinden mit Systemen, und sshd ist der Dienst, der Zugang ermöglicht. Unter den richtigen Umständen könnte diese Störung es einem böswilligen Akteur potenziell ermöglichen, die sshd-Authentifizierung zu brechen und unbefugten Zugriff auf das gesamte System aus der Ferne zu erlangen.

**Welche Distributionen sind von diesem schädlichen Code betroffen?**

Aktuelle Untersuchungen deuten darauf hin, dass die Pakete nur in Fedora 40 und Fedora Rawhide innerhalb des Red Hat Community-Ökosystems vorhanden sind.

Keine Versionen von Red Hat Enterprise Linux (RHEL) sind betroffen.

Wir haben Berichte und Beweise für erfolgreiche Einspritzungen in xz 5.6.x-Versionen, die für Debian Unstable (Sid) gebaut wurden. Andere Distributionen könnten ebenfalls betroffen sein. Nutzer anderer Distributionen sollten sich an ihre Distributoren wenden, um Anweisungen zu erhalten.

**Was sollte ich tun, wenn ich eine betroffene Distribution verwende?**

Für persönliche und geschäftliche Aktivitäten sollten Sie die Verwendung von Fedora 40 oder Fedora Rawhide umgehend einstellen, bis Sie Ihre xz-Version herabstufen können. Wenn Sie eine betroffene Distribution in einem geschäftlichen Umfeld verwenden, empfehlen wir Ihnen, sich an Ihr Informationssicherheitsteam für die nächsten Schritte zu wenden.

Zusätzlich haben diejenigen, die openSUSE-Distributionen betreiben, von SUSE ein Downgrade-Verfahren veröffentlicht, das unter [SUSE Build Service](https://build.opensuse.org/request/show/1163302) eingesehen werden kann. Community, Infrastructure, Platform, Security