Auf Mastodon ansehen
In den vergangenen Wochen erschien die aktuelle Sicherheitslage bei Linux-Systemen fragil. Alle paar Tage tauchte eine neue Verwundbarkeit auf: CopyFail, DirtyFrag, Fragnesia, ssh-keysign-pwn. Diesen Schwachstellen ist gemeinsam, dass sie angeblich durch den Einsatz von spezialisierten KI-Modellen gefunden wurden (das ist kein Mythos). Nun hat Dirk im Arch-Linux-Blog einen entwarnenden Beitrag geschrieben.
Diesen Beitrag gebe ich hier im Original wieder, weil er die Situation gut zusammenfasst:
Der Artikel von Dirk
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 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 „neue 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 Libraries 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:
- Regelmäßig in kurzen Intervallen auf Updates prüfen und diese Installieren (
pacman -Syu1-2 mal am Tag), dabei darauf achten, einen aktuellen und vertrauenswürdigen Mirror zu verwenden. - Der vor einiger Zeit geschriebene Reminder zu den AUR-Sicherheitshinweisen sollte nach wie vor beachtet werden.
- Keine Scripte aus dem Internet ausführen, ohne sie vorher zu prüfen!
- Keine generierten oder von anderen genannt bekommene Befehle und Codezeilen ausführen, ohne vorher zu verstehen, was diese machen!
- Per Mount-Optionen verhindern, dass Binäres von durch Useraccounts beschreibbaren Partitionen ausgeführt werden dürfen.
- 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 in Bezug auf die für Arch verfügbaren Kernel aus den Repositorys.
Soweit der Artikel von Dirk. Ich wollte herausfinden, in welchen Kernel-Versionen diese Schwachstellen gefixt wurden, konnte aber keine genaue Antwort finden. Vielleicht wissen die Kommentatoren mehr darüber. Wie dem auch sei, wenn ihr eure Linux-Distribution regelmässig aktualisiert, sollte sie auf einem Kernel laufen, in dem CopyFail und Co. gefixt sind.
Titelbild: https://pixabay.com/photos/data-security-security-data-online-9145391/
Quelle: https://www.archlinux.de/news/35780-Aktuelle-Sicherheitslage
"Keine Compiler auf dem System bereitstellen oder diese durch Dateiberechtigungen oder ACLs in der Nutzung einschränken." Wie hilft dies, wenn ich es mir selbst kompilieren kann?
Ohne Compiler kompilieren? Verstehe die Aussage nicht.
Die meisten der genannten Lücken waren Local Privilege Escalations. Da genügt es mir, wenn ich ein Script/Binary zur Ausführung bringen kann (z.B. bei einem Hoster oder via Lücke in einer Anwendung). Meine Frage zielt nun darauf ab, was das Compiler entfernen mitigieren soll.
"Per Mount-Optionen verhindern, dass Binäres von durch Useraccounts beschreibbaren Partitionen ausgeführt werden dürfen. Keine Compiler auf dem System bereitstellen oder diese durch Dateiberechtigungen oder ACLs in der Nutzung einschränken."
Eine genauso blöde Einschränkung, wie unter vielen Windows Systemen. Das bringt uns zurück zum Terminal und weg vom Universalcomputer. Mit diesen Einschränkungen ist der rechner/Account genauso viel wert wie in früheren Zeiten ein Terminal. Nur was irgendein Admin bereitgestellt hat, darf genutzt werden. Wo bleibt da der PERSONAL computer. Eben!
Du musst es ja nicht machen. Sicherheit geht immer auf Kosten der Bequemlichkeit, ein System stellt immer einen Kompromiss aus beidem dar.
Es gibt nur aktuelle kernel die dediziert gefixt sind. Jede Distro reagiert aber meist mit einem schnellen patch auf den aktuellen kernel. Hier das Beispiel CopyFail bei suse: https://www.suse.com/c/suse-responds-to-the-copy-fail-vulnerability/
So ähnlich dürfte es bei den meisten Distros aussehen.
"Keine Compiler auf dem System bereitstellen" Bitte ganz konkret für Otto Normaluser wie mich. Wie schon viele vor mir fragten, verstehe ich das richtig, dass ich z.B. keinen g++, gcc oder rustc (nur als Beispiele für viele andere Compiler) auf meinem PC installiert haben sollte?
> oder diese durch Dateiberechtigungen oder ACLs in der Nutzung einschränken
steht da auch noch
IMO zielt das darauf ab, das binaries die z.B. auf Redhat gebaut wurden nicht zwangsläufig auf Debian laufen (wegen verschiedener libs oder auch nur verschieden benannter libs), und so zu verhindern dass ein für das System passendes Programm kompiliert werden kann. Ob das viel bringt kann ich nicht beurteilen, aber es geht in den Tipps eben darum, möglichst wenig Lücken zu bieten.