Willkommen bei Arch Linux

Das Varnish-Projekt hat sich offiziell in Vinyl Cache umbenannt. Im Anschluss an diese Umbenennung wurde ein neues vinyl-cache-Paket erstellt.
Diese Aktualisierung führt zu wesentlichen Änderungen, und es wird den Nutzern empfohlen, diese Änderungen sorgfältig zu prüfen, bevor die Umstellung durchgeführt wird.
Alle Verweise auf varnish wurden in Binärdateien und Verzeichnissen zu vinyl geändert.

Mindestens müssen folgende Schritte von den Nutzern durchgeführt werden:

• Das Verzeichnis /etc/varnish muss in /etc/vinyl-cache umbenannt werden.
• Das Verzeichnis /var/lib/varnish muss in /var/lib/vinyl-cache umbenannt werden.
• Die Berechtigungen der Dateien innerhalb von /var/lib/varnish müssen angepasst werden.
• Der Benutzer varnish wird in vinyl umbenannt.
• Die Gruppe varnish wird in vinyl umbenannt.
• Der Benutzer varnishlog wird in vinyllog umbenannt.
• Die Gruppe vcache bleibt unverändert.
• Die alten Systemd-Dienste varnish.service und varnishncsa.service müssen deaktiviert werden.
• Die neuen Systemd-Dienste vinyl-cache.service und vinylncsa.service müssen aktiviert werden.

Das varnish-Paket aus dem Repository [extra] entfernt. Es sind derzeit keine Pläne für die Pflege eines neuen varnish-Pakets vorgesehen, da es sich um ein anderes Upstream-Projekt handelt.

Seit einigen Wochen werden in den Onlinemedien und auf Social Media vermehrt Artikel veröffentlicht, die – teilweise dramatisierend – auf Schwachstellen im Linux-Kernel eingehen, die es ermöglichen, erweiterte Berechtigungen zu erhalten oder eigentlich nicht zugängliche Dateien auszugeben.

Solche Schwachstellen gab es im Kernel schon immer, und schon immer wurden sie bei bekanntwerden zeitnah behoben oder umgangen. Der Unterschied ist, dass bei den zuletzt bekannt gewordenen Schwachstellen das Prinzip der Responsible Disclosure ignoriert wurde, und die technischen Informationen der Schwachstellen veröffentlicht wurden, ohne dass diese zuvor behoben werden konnten.

Das brechen des sogenannten „Embargos“ einer Responsible Disclosure wird unter IT-Sicherheitsexperten allgemein als unprofessionell und bewusst schädigend angesehen. Das bewusste brechen des Embargos kann hier zudem als „Werbung“ für KI-gestützte Programme zur Schwachstellenforschung gesehen werden, da sowohl „CopyFail“, „DirtyFrag“, „Fragnesia“, und auch „ssh-keysign-pwn“ mithilfe von spezialisierten KI-gestützten Systemen gefunden wurden.

Es handelt sich zusammengefasst also nicht um eine „neu Welle an Exploits“, sondern um solche, die bewusst unter Ignorierung der üblichen Praxis direkt veröffentlicht wurden.

Angriffssvektor

Alle bisher in diesem Kontext bekannten Angriffe auf ein System bedingen, dass ein Angreifer Zugriff auf das System hat, und mit einem Useraccount eingeloggt ist der eine „normale Shell“ starten kann. Angriffe über das Netzwerk oder bei Verwendung von „Spezialaccounts“ sind nicht möglich.

Auf Systemen mit einem beschriebenen Account ist es für die Nutzer möglich, die Schwachstellen auszunutzen, wenn sie …

• … Dateien herunterladen oder Anlegen und mit Inhalt füllen können
• … einen Compiler zum Erzeugen von Binarys verwenden dürfen
• … die für die Expoits nötigen Librarys auf dem System installiert sind
• … in den von ihnen beschreibbaren Bereichen im Dateisystem Anwendungen starten können

Das gleiche gilt natürlich für schädliche Programme, die die nötigen Schritte automatisch im Kontext eines beschriebenen Useraccounts ausführen.

Maßnahmen

Die Maßnahmen hängen vom betrachteten System ab. Auf einem System, das nur von einem Anwender benutzt wird, gelten die allgemeinen Sicherheitsregeln unverändert auch weiterhin.

Zusätzlich:

1. Regelmäßig in kurzen Intervallen auf Updates prüfen und diese Installieren (pacman -Syu 1-2 mal am Tag), dabei darauf achten, einen aktuellen und vertrauenswürdigen Mirror zu verwenden.
2. Der vor einige Zeit geschriebene Reminder zu den AUR-Sicherheitshinweisen sollte nach wie vor beachtet werden.
3. Keine Scripte aus dem Internet ausführen, ohne sie vorher zu prüfen!
4. Keine generierten oder von anderen genannt bekommene Befehle und Codezeilen ausführen, ohne vorher zu verstehen, was diese machen!
5. Per Mountoptionen verhindern, dass Binarys von durch Useraccounts beschreibbaren Partitionen ausgeführt werden dürfen.
6. Keine Compiler auf dem System bereitstellen oder diese durch Dateiberechtigungen oder ACLs in der Nutzung einschränken.

Zusätzlich beobachtet der Arch-User GerBra in den Threads zu „ssh-keysign-pwn“ und zu „DirtyFrag“ und „Fragnesia“ die aktuelle Situation und updatet den Status im Bezug auf die für Arch verfügbaren Kernel aus den Repositorys.

Das Paket kea hat alle Dienste so umgestellt, dass sie unter einem dedizierten Benutzerkonto namens kea (anstatt root) ausgeführt werden, um die Sicherheit zu verbessern. Diese Änderung erfordert Aktualisierungen der Berechtigungen für die Laufzeitdateien, die von den kea-Diensten erstellt werden.

Nutzer, die von einer bestehenden kea-Installation aktualisieren, sollten daher nach dem Upgrade die folgenden Befehle ausführen:

chown kea: /var/lib/kea/* /var/log/kea/* /run/lock/kea/logger_lockfile
systemctl try-restart kea-ctrl-agent.service kea-dhcp{4,6,-ddns}.service

Benutzerkonten, die mit den Dateien der kea-Dienste interagieren müssen (z.B. Lease-Dateien unter /var/lib/kea, Logdateien unter /var/log/kea oder Konfigurationsdateien unter /etc/kea), sollten der Gruppe kea hinzugefügt werden.

Der alte Paketname iptables-nft wurde durch iptables ersetzt, und das Legacy-Backend ist unter dem Namen iptables-legacy verfügbar.

Beim Wechsel zwischen den Paketen (zwischen iptables-nft, iptables und iptables-legacy) sollte in den Verzeichnissen /etc/iptables/ nach .pacsave-Dateien gesucht und die dort gespeicherten Regeln gegebenenfalls wiederhergestellt werden:

• /etc/iptables/iptables.rules.pacsave
• /etc/iptables/ip6tables.rules.pacsave

Die meisten Konfigurationen sollten ohne Änderungen funktionieren. Nutzer, die auf ungewöhnliche xtables-Erweiterungen oder Legacy-Funktionen angewiesen sind, sollten jedoch sorgfältig testen und gegebenenfalls iptables-legacy verwenden.

Mit der Version 590 der offiziellen Nvidia-Treiber wird seitens Nvidia der Support der „Pascal“-GPUs eingestellt. Dieser Treiber funktioniert dann nicht mehr für Karten dieser Serie. Darunter fallen alle GTX-10xx-Modelle, sowie alle älteren Modelle dieser GPU-Serie.

Arch wird mit dieser Treiberversion zudem die installierten proprietären Treiberpakete ersetzen, um die offiziellen offenen Kernelmodule zu verwenden:

• nvidia wird mit nvidia-open ersetzt
• nvidia-dkms wird mit nvidia-open-dkms ersetzt
• nvidia-lts wird mit nvidia-open-lts ersetzt

Auswirkungen: Wenn das Treiberupdate auf Systemen durchgeführt wird, die eine „Pascal“-GPU (oder älter) benutzen, wird das Laden des Treibers fehlschlagen und das grafische System nicht mehr richtig funktionieren.

Nutzer mit „Pascal“-GPUs müssen in den Updateprozess eingreifen: Wenn eine Nvidia-Grafikkarte mit „Pascal“-GPU im System steckt, muss zur weiteren Verwendung auf die Legacy-Version des proprietären offiziellen Treibers zurückgegriffen werden:

1. Die Pakete nvidia, nvidia-lts, oder nvidia-dkms deinstallieren
2. Das Paket nvidia-580xx-dkms aus dem AUR installieren

Systeme die GPUs aus der „Turing“-Serie (20xx und die GTX1650-Serie) oder neuer benutzen, werden automatisch auf die offiziellen offenen Kernelmodule umgestellt. Die User müssen hier nicht in den Updateprozess eingreifen.

Wir möchten ein Update zu den jüngsten Server-Ausfällen geben, die unsere Infrastruktur betreffen. Das Arch Linux Projekt erlebt derzeit einen anhaltenden Denial-of-Service-Angriff, der hauptsächlich unsere Hauptwebseite, das Arch User Repository (AUR) und die englischen Foren beeinträchtigt.

Wir sind uns der Probleme bewusst, die dies für unsere Endnutzer schafft. Dies betrifft insbesondere die Dienste von archlinux.org. Wir werden weiterhin aktiv mit unserem Hosting-Anbieter zusammenarbeiten, um den Angriff abzuschwächen. Zudem evaluieren wir Anbieter für DDoS-Schutz und berücksichtigen dabei sorgfältig Faktoren wie Kosten, Sicherheit und ethische Standards.

Um die Kommunikation zu diesem Thema zu verbessern, werden wir zukünftig regelmäßige Updates auf unserer Dienststatusseite bereitstellen.

Als ehrenamtlich geführtes Projekt wissen wir die Geduld der Community zu schätzen, während unser DevOps-Team daran arbeitet, diese Probleme zu lösen. Bitte habt Geduld mit uns und vielen Dank für die bisher gezeigte Unterstützung.

Workarounds während Dienstunterbrechungen

• Im Falle eines Ausfalls von archlinux.org:
  • Spiegelserver: Eine Liste aller Spiegelserver findet ihr unter Mirror-Status. Da der Endpunkt der Spiegelserverliste, der in Tools wie reflector verwendet wird, auf archlinux.org gehostet wird, verwendet bitte während eines Ausfalls standardmäßig die im Paket pacman-mirrorlist aufgeführten Spiegelserver.
  • ISO: Installationsmedien findet ihr unter Arch Linux Downloads.
• Im Falle eines Ausfalls von aur.archlinux.org:
  • Pakete: Wir pflegen einen Spiegel der AUR-Pakete auf GitHub. Ihr könnt ein Paket abrufen mit:
    $ git clone --branch <package_name> --single-branch https://github.com/archlinux/aur.git <package_name>

Zusätzliche Anmerkungen

• Unsere Dienste können aufgrund der vom Hosting-Anbieter durchgeführten TCP-SYN-Authentifizierung eine anfängliche Verbindungsrücksetzung senden, aber nachfolgende Anfragen sollten wie erwartet funktionieren.

• Wir halten technische Details über den Angriff, seinen Ursprung und unsere Abwehrmaßnahmen intern, solange der Angriff noch andauert.