xz Backdoor (war:Wichtig! System dringend updaten!)
Eine ganz üble Sache. Ich hätte mir auch gerne im Commit für die gefixte Version einen Hinweis auf den Fix erhofft.
- Bearbeitet
Im Security-Tracker gibt es dazu auch noch eine Zusammenfassung.
https://security.archlinux.org/ASA-202403-1
Edit: und ’ne News haben wir dazu nun auch.
https://www.archlinux.de/news/35174-Backdoor-in-xz-vor-Version-5-6-1-2
Spannend! (im nicht sonderlich positiven Sinn)
Zum Glück waren wir auf Arch ja doch nicht betroffen, aber für mich persönlich kann ich sagen, dass ich die letzten Monate Zeit investiert habe, mein System weiter abzusichern (motiviert durch meinen Umstieg auf GrapheneOS auf dem Smartphone) und bin nun hierdurch darin bestärkt, mich damit weiter zu beschäftigen. Natürlich hilft alles nichts bei Hintertürchen, aber ggf. kann man den potenziellen Schaden durch so etwas wie Apparmor eingrenzen? Gibt jedenfalls noch viel zu lernen!
- Bearbeitet
sekret Zum Glück waren wir auf Arch ja doch nicht betroffen
Zumindest nicht über den Vektor Paketbau wie u.a. Debian, ebenso nicht sshd.
Für die richtige Analyse habe ich auch zuwenig Wissen, außerdem ist es wohl auch z.Zt. schwer "Fakten" von "Panik" zu unterscheiden.
Wie "ausgeklügelt" das aber IMHO angelegt war/ist, würde es mich nicht überraschen wenn der/die Attacker sich nur auf einen Vektor festgelegt hätten. Da müssen wohl an den ganzen Code/Repo die Experten ran...
Was mir fast am meisten zum Nachdenken gab, war ein Post von Head_on_a_Stick im englischen Forum:
https://bbs.archlinux.org/viewtopic.php?pid=2160839#p2160839
Should Arch now consider building packages from git directly rather than using tarballs? That would have prevented this problem entirely.
Da ist wohl was Wahres dran. Früher waren tar-Archive mit die einzige, bevorzugteste Variante zur Distribution von Sourecode. Heutzutage (mit zig etablierten VCS Systemen) wohl auch die gefährlichste.
- Bearbeitet
GerBra
Zustimmung bzgl dem Kommentar über die VCS. Ich bin ja echt nur Laie, aber hab mir vor Langem mal genau diese Gedanken tatsächlich gemacht: Wie kann man garantieren, dass im Tarball genau das landet, was man gemeinsam z.B. auf Github entwickelt hat. Kann man das zumindest für die Tarballs auf Github garantieren? Also werden die automatisch generiert oder macht das der Maintainer eigenhändig?
- Bearbeitet
sekret Also werden die automatisch generiert oder macht das der Maintainer eigenhändig?
Das kann ich nicht mit Sicherheit beantworten, ich habe keinen githup Account.
Ich habe mir nur mal ein paar Githup-Projekte kurz angeschaut, zumindest über das Web-Frontend werden von GitHup wohl nur Dateien im Repo als zip/tar/etc. generiert zum Download.
Bei xz war die source-URL im PKGBUILD ja:
source = https://github.com/tukaani-project/xz/releases/download/v5.6.0/xz-5.6.0.tar.gz
source = https://github.com/tukaani-project/xz/releases/download/v5.6.0/xz-5.6.0.tar.gz.sig
Es gibt nun wohl bei Githup für jedes(?) Projekt zumindest:
<projektname>/releases
als Path, aber bei:
<projektname>/releases/download
habe ich stichprobenartig immer ein 404 bekommen.
Es ist halt jetzt die Frage:
Stellt githup einen Mechanismus zum Download über ./releases/download/ per Default/Option bereit?
Oder kann der Projektinhaber selbst Pfade im Repo (//Edit: bzw. genauer: der Githup Repo-Struktur) erstellen (./download) und dieses z.B. prominent propagieren (und reinpacken was ihm gefällt)?
Würde mich auch interessieren, evtl. kann jemand die Frage beantworten.
Anstatt Archive als Source-URL wäre es halt IMHO sicherer im PKGBUILD direkt per git (oder whatever VCS) das gewünschte Branch/Release/Tag zu klonen.
GerBra Das kann ich nicht mit Sicherheit beantworten, ich habe keinen githup Account.
Ich habe Accounts bei GitHub und GitLab, und bei beiden habe ich noch nie manuell eine Archivdatei anlegen müssen. Ich vermute, dass sie zur Echtzeit erzeugt werden, wenn jemand sie anfordert, denn Änderungen am Code befinden sich auch sofort in der Archivdatei.
GerBra Bei xz war die source-URL im PKGBUILD ja:
Die hat sich zwischenzeitlich geändert, ist aber aktuell auch nicht mehr erreichbar.
GerBra habe ich stichprobenartig immer ein 404 bekommen.
Weil die Accounts der xz-Mitwirkenden und die Projektseite zur Zeit gesperrt sind.
- Bearbeitet
//Edit: hat sich geklärt, sorry für die Verwirrung (s.u)
Martin-MS Weil die Accounts der xz-Mitwirkenden und die Projektseite zur Zeit gesperrt sind.
Da hast du mich falsch verstanden:
Ich habe versucht rauszukriegen ob <projekt>/releases/download ein von der Githup-Infrastruktur bereitgestelltes Verzeichnis ist (was ich durch Stichproben von anderen Projekten als xz nicht verifizieren konnte, 404) oder ob ein Projektinhaber solch einen Pfad selbst anlegen kann, also dort z.B. einen tarball bereitstellen kann der eben nicht das Githup-Repo widerspiegelt bzw. von Gitpup automatisch erstellt wird, sondern (wie im xz-Fall ja scheinbar passiert) auch andere Inhalte haben kann.
@GerBra deine Schachtelsätze sind ja manchmal grauenhaft <g>
Was ich meine:
Nehmen wir z.B.
https://github.com/vim-test/vim-test
wget https://github.com/vim-test/vim-test/releases
den Sub-Pfad /releases gibt es scheinbar für jedes Githup-Projekt. Hingegen /releases/download/:
wget https://github.com/vim-test/vim-test/releases/download
zeigt 404 (und eben auch bei anderen getesteten Projekten)
Die xz URL für source hatte ja nun explizit:
releases/download/*.tar.gz
Wie kann diese URL zustandekommen? Bzw. ist das ein Teil der Githup-Infrastruktur? (die ggf. nur per githup-Account erreichbar ist?)
//Edit:
releases/download ist wohl ein von der Infrastruktur bereitgestelltes Verzeichnis, ich habe wohl nur bei Projekten ohne Release nachgeschaut. Bei
https://github.com/archlinux/linux/releases/
gibt es ebenfalls download/ z.B.
https://github.com/archlinux/linux/releases/download/v6.8.2-arch2/linux-v6.8.2-arch2.patch.zst
Sorry für die ganze Aufregung, ich habe nicht richtig geprüft.
- Bearbeitet
Ich habe ein kurzes Skript erstellt, welches alle gefundenen liblzma.so Bibliotheken auf die verdächtige Signatur überprüft.
Das Skript nutzt find zum Finden <g>.
Es benötigt einen Start-Pfad (z.B. /)
Es gibt die Option -x (-xdev bei find), welche die Suche auf das aktuell gemountete Dateisystem beschränkt um z.B. keine gemounteten Netzwerk-Dateisysteme zu durchsuchen.
Der wesentliche Teil des Scannens beruht auf dem Skript von cyclone:
https://github.com/cyclone-github/scripts/blob/main/xz_cve-2024-3094-detect.sh
#/usr/bin/bash
# by: GerBra, archlinux.de forum
# 2024-04-01
#
# ./find_and_proof_lzma.sh <startpath> [-x]
# startpath : where to start searching
# -x : use find with -xdef option, so stay in current mounted filesystem
# and don't descend into other mounted filesystems.
# If ex. /home is a seperated mounted partition you may need
# running the script dedicated for this or other mounts.
#
# For permission issues you may run the script with root privileges.
if [[ -z $1 ]]; then
echo "Please specify a path to start searching, ex. /"
exit 1
fi
[[ "x$2" == "x-x" ]] && xdef=true
found=0
vulnerable=0
if [[ $xdef == true ]]; then
echo "Searching for liblzma in: $1 (staying in THIS filesystem)"
LANG=C find "$1" -xdev -name liblzma.so* -type f -print > "./liblzma.places"
else
echo "Searching for liblzma in: $1 (descending into ALL underlying filesystems)"
LANG=C find "$1" -name liblzma.so* -type f -print > "./liblzma.places"
fi
while read -r LINE; do
echo "-------- Checking ----------------------------------------------"
echo "$LINE"
found=$((found+=1))
# https://github.com/cyclone-github/scripts/blob/main/xz_cve-2024-3094-detect.sh
# Thanks to cyclone for the script
if hexdump -ve '1/1 "%.2x"' "$LINE" | grep -q 'f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410'; then
echo "Function signature in liblzma: VULNERABLE"
vulnerable=$((vulnerable+=1))
else
echo "Function signature in liblzma: OK"
fi
done < "./liblzma.places"
printf "\nliblzma places found: %d, vulnerable: %d\n" $found $vulnerable
rm "./liblzma.places"
Um auf alle Verzeichnisse/Dateien zugreifen zu dürfen sollte das Skript mit Root-Privilegien gestartet werden.
//Edit:
Ein Lauf als User für /usr sieht z.B. so aus:
$ sh find_and_proof_lzma.sh /usr/
Searching for liblzma in: /usr/ (descending into ALL underlying filesystems)
find: '/usr/share/factory/etc/audit/plugins.d': Permission denied
find: '/usr/local/tank/lost+found': Permission denied
-------- Checking ----------------------------------------------
/usr/lib32/liblzma.so.5.6.1
Function signature in liblzma: OK
-------- Checking ----------------------------------------------
/usr/lib/liblzma.so.5.6.1
Function signature in liblzma: OK
liblzma places found: 2, vulnerable: 0