Bin zufällig auf das Thema hier gestoßen. Beim Lesen der Diskussion ist mir ein Feature eingefallen, das wirklich hilfreich sein könnte in einer Paketverwaltung:
Gerade angesichts der AUR-Katastrophe wäre es hilfreich, wenn im Paketmanager auch die Sicherheitsseite von Arch abgefragt würde und dort vorhandene Warnungen für diverse Pakete mit angezeigt werden. Da kann man sich gut vorher überlegen, ob man Risiken eingehen will.
Im AUR-Forum wird derzeit auch heftig diskutiert, mit welchen Verbesserungen und Änderungen man künftigen Sicherheitsproblemen vorbeugen will. Zwei gute Ideen fand ich dort:
1.) Pakete von Entwicklern kennzeichnen, die schon mindestens nn Jahre Pakete anbieten und diese auch regelmäßig pflegen / updaten
2.) Besonders oft installierte Pakete durch einen Prüf-Prozess (evtl. AI) laufen lassen und nach Bestehen als „geprüft“ kennzeichnen.
Diese Kennzeichnungen müssten dann im Paketmanager mit angezeigt werden. Die Anzeigen müsste es auch für alle bereits installierten Pakete geben. So kann man sein System immer gut kontrollieren.
Aktuell gibt es zwei Prüfmöglichkeiten:
arch-audit | grep High\ risk
und
pkg-audit
Das erstgenannte liefert mir auf meinen Desktop auf Anhieb:
djvulibre is affected by arbitrary code execution. High risk!
grub is affected by multiple issues. High risk!
libxml2 is affected by denial of service. High risk!
pam is affected by arbitrary filesystem access. High risk!
djvulibre is affected by arbitrary code execution. High risk!
grub is affected by multiple issues. High risk!
libxml2 is affected by denial of service. High risk!
pam is affected by arbitrary filesystem access. High risk!
Geil. Das sind ja alles systemrelevante Pakete. Warum sind diese Fehler in Manjaro nicht behoben worden? Oder zumindest noch nicht?
Ich habe jetzt zwar nicht nachgesehen, aber sind die Pakete von Arch wirklich aktueller und haben diese Hochrisikofehler behoben? Ist mir schon klar das hier wahrscheinlich niemand diese Frage beantworten kann, war auch eher rhetorische Frage.
Da habe ich aber mindestens zwei Einwände
* wie aktuell ist diese Liste? → bei mir eine einzige CVE von 2026
* und warum fehlt in der Ausgabe die CVE? Das ist doch das wichtigste, um überhaupt etwas genaueres aussagen zu können. Laut Beschreibung auf der git-Seite sollte es doch z.B. eigentlich so aussehen:
$ arch-audit bzip2 is affected by CVE-2016-3189. Medium risk! curl is affected by CVE-2016-9594, CVE-2016-9586. Update to 7.52.1-1! gst-plugins-bad is affected by CVE-2016-9447, CVE-2016-9446, CVE-2016-9445. High risk!
damit lässt sich doch viel mehr anfangen als mit einem lapidaren
das ist so viel oder besser so wenig aussagekräftig wie eine Meldung a la „Linux ist angreifbar“
da ich kein Manjaro habe, fehlt da ein Parameter für arch-audit?
Ich nutze auch kein Manjaro sondern EOS, Ich habe ne Menge Treffer:
arch-audit
libxml2 is affected by denial of service. High risk!
linux-lts is affected by multiple issues, information disclosure. High risk!
pam is affected by arbitrary filesystem access. High risk!
coreutils is affected by information disclosure. Medium risk!
cpio is affected by arbitrary command execution. Medium risk!
giflib is affected by information disclosure. Medium risk!
lib32-libsndfile is affected by arbitrary code execution. Medium risk!
libheif is affected by information disclosure. Medium risk!
libtiff is affected by unknown, denial of service. Medium risk!
linux is affected by multiple issues, insufficient validation. Medium risk!
openjpeg2 is affected by arbitrary code execution. Medium risk!
openssl is affected by arbitrary command execution, certificate verification bypass. Medium risk!
openvpn is affected by information disclosure. Medium risk!
perl is affected by signature forgery, directory traversal, unknown. Medium risk!
systemd is affected by information disclosure. Medium risk!
wget is affected by information disclosure. Medium risk!
xdg-utils is affected by information disclosure. Medium risk!
lua52 is affected by denial of service. Low risk!
Die Ersten drei Treffer sind systemrelevant und High risk … also löschen kann ich die nicht. Die Medium risk Kndidaten habe ich noch nicht überprüft.
Ich habe mal nachgesehen. Also wenn ihr euch schon arch-audit antut, dann benutzt bitte die Option -c arch-audit -c
das gibt die CVE-Nummer mit aus, so kann man dann wenigstens genaueres nachschlagen.
Als Beispiel habe ich mal die Warnungen für libxml2 durchsucht und bin auf CVE 2026-6653 gestossen
könnte passen.
Dort erfährt man dann auch, dass die libxml2-Versionen 2.9.11 bis 2.11.0 betroffen sind und wie ein Angriff erfolgen könnte. Ist doch viel informativer als ein stumpfes
oder gar ein
ach nee, Linux-lts (auf welche Version zielt das?) ist von mehreren Problemen betroffen? Wäre ich jetzt nie drauf gekommen
Da ich mir aufgrund mangelnder Kenntnisse bisher nicht zutraue, PKBLD zu prüfen, habe ich mal kurz LEO-KI befragt. Und die brauchbaren Ergebnisse haben mich doch erstaunt, weshalb ich sie weiter unten mal einfüge.
Wichtig scheinen mir die von der KI genannten Prüf-Tools zu sein, die es ja wohl doch gibt. Und die könntest du @Daemon evtl. in deine Paketverwaltung mit integrieren, sodass Pakete zunächst herunter geladen, dann geprüft und erst wenn OK, auch installiert werden.
Hier die KI-Antwort:
Um ein PKGBUILD-Skript im AUR auf Schadcode zu prüfen, sollten Sie eine Kombination aus manueller Inspektion und automatisierten Tools verwenden. Da PKGBUILDs im Grunde Bash-Skripte sind, können sie beliebige Befehle ausführen.
1. Manuelles Auditing (Die „5-Punkte-Checkliste“)
Laden Sie das Paket zunächst nur herunter, ohne es zu installieren (z. B. mit yay -G <paketname> oder paru -G <paketname>), und öffnen Sie die Datei PKGBUILD sowie eventuelle .install-Dateien in einem Texteditor.
Achten Sie auf folgende kritische Punkte:
Verdächtige Befehle: Suchen Sie nach Befehlen wie curl ... | sh, wget ... | bash, eval(), rm -rf / (oder Pfade außerhalb von $pkgdir), chmod 777 oder base64. Diese deuten oft auf das Herunterladen und Ausführen von fremdem Code oder die Verschleierung von Befehlen hin.
Netzwerkzugriffe im Build-Prozess: Ein PKGBUILD sollte idealerweise nur die in der source=-Liste definierten Dateien herunterladen. Unerwartete Netzwerkaufrufe in den Funktionen prepare(), build() oder package() sind ein Warnsignal.
Schreibzugriffe auf das System: Die Funktion package() darf nur Dateien in das temporäre Verzeichnis $pkgdir kopieren. Jeglicher Versuch, direkt in /etc, /usr oder andere Systemverzeichnisse zu schreiben, ist kritisch.
Quellen und Checksummen: Prüfen Sie, ob die source=-URLs auf offizielle Upstream-Projekte (z. B. GitHub-Releases des Entwicklers) verweisen. Sind die sha256sums oder validpgpkeys korrekt gesetzt? Ein Wert von 'SKIP' ist bei Git-Quellen mit Signaturprüfung akzeptabel, bei normalen Downloads jedoch verdächtig.
Abhängigkeiten: Achten Sie auf unnötige oder verdächtige Abhängigkeiten (z. B. Node.js-Pakete wie npm, bun oder yarn bei Software, die diese eigentlich nicht benötigt), da diese oft als Vektor für Malware dienen.
2. Automatisierte Sicherheits-Tools
Da eine manuelle Prüfung fehleranfällig ist, empfehlen sich spezialisierte Scanner, die nach bekannten Mustern suchen:
aur-scanner: Ein modernes Tool (geschrieben in Rust), das PKGBUILDs und .install-Skripte auf über 110 bekannte bösartige Muster prüft. Es kann in AUR-Helper wie yay oder paru integriert werden, um jedes Paket vor der Installation automatisch zu scannen.
Nutzung:aur-scan check <paketname>
aur-sleuth: Ein Tool, das KI (LLMs) nutzt, um eine tiefergehende semantische Analyse des Codes durchzuführen und verdächtige Logik zu erkennen, die einfache Pattern-Matcher übersehen könnten.
pkgbuild-check: Ein Python-Skript, das als Linter fungiert und vor schwachen Checksummen (MD5/SHA1), unsicheren HTTP-Quellen oder gefährlichen Berechtigungen warnt.
3. Wichtige Warnsignale (Red Flags)
Zusammenfassend sollten Sie bei folgenden Mustern im Code sofort stutzig werden:
Pipes zu Shells:curl http://... | bash
Verschleierung: Nutzung von base64 -d gefolgt von eval.
Persistenz: Versuche, systemd-Dienste zu erstellen, Cron-Jobs anzulegen oder SSH-Schlüssel zu manipulieren.
Pfad-Manipulation: Zugriffe auf /tmp zur Ausführung von Code oder Änderungen an /etc/passwd bzw. /etc/shadow.
Die sicherste Methode bleibt die Kombination: Nutzen Sie Tools wie aur-scanner für den ersten Filter und werfen Sie bei jedem Update oder bei unbekannten Paketen einen kurzen manuellen Blick auf die geänderten Zeilen im PKGBUILD.
