Beiträge von m_ueberall

  • Das längste Thema

    Zitat von terence

    GhostBSD scheint ja eher Desktop-orientiert zu sein. Daher vielleicht mal einen Blick auf OpenBSD werfen?

    terence : Danke für den Tip; OpenBSD ist tatsächlich auch auf der Evaluationsliste, allerdings unterhalb von FreeBSD/GhostBSD. Bislang habe ich nach kurzer Durchsicht einiger Quellen (u. a. YouTube-Videos) im Hinterkopf, dass GhostBSD insbesondere bei der Hardwareunterstützung punkten soll (sowohl bezogen auf die existierenden SBC/Laptops als auch die Architekturen AMD64/ARM64/RISCV), und momentan steht hier auch die Überlegung im Raum, mittelfristig primär Desktops damit zu bestücken. In der Vergangenheit hatte ich *BSD primär "via FreeBSD" kennengelernt.

    Es ist nicht auszuschließen, dass BSD später auch für reine Serveranwendungen zum Einsatz kommt. Als erster Schritt ist hier zunächst allerdings sowieso ein Test im Kontext von signal-cli (und ZFS) eingeplant, wofür Installationen sowohl von FreeBSD, GhostBSD als auch OpenBSD via VM unter Incus anstehen. Das Ganze wird … eine gewisse Zeit in Anspruch nehmen (denn die Zeit verfliegt, wenn man sich amüsiert).

  • Das längste Thema

    FYI: Pünktlich zum verlängerten(?) Wochenende gibt es eine neue Kernel-Lücke: "VUL-0: CVE-2026-46300: kernel-source: FragNesia attack: another xfrm/esp based local root exploit"; diese ist insofern "Dirty Frag" sehr ähnlich, als sie auf denselben Kernelmodulen basiert wie CVE-2026-43284, weswegen auch derselbe Workaround von vor ein paar Tagen greift, wenn er bereits/noch aktiv ist (lies: Deaktivierung der extern nachgeladenen Kernelmodule esp4, esp6, rxrpc). AlmaLinux hat einen recht informativen Blog-Eintrag hierzu.

  • Das längste Thema

    Zitat von fvbor

    Und dann pro Tool einen Thread oder wie stellst du es dir vor?

    Das wäre ein Ansatz, ja.

    Vielleicht bekommen wir es (ohne weitere Unterforen) hin, dass wir etwa auch für Kernel-Exploits systematisch Diskussionsfäden für "Kernel-Exploits (alle Distributionen|generisch)", "Kernel-Exploits (Debian/Ubuntu)", "Kernel-Exploits (Fedora)", "Kernel-Exploits (*BSD)", … eröffnen, so dass Nutzer sich nicht totsuchen müssen.

    Also letztlich ein Namensschema "<STACK|MODUL|KOMPONENTE> (<BETROFFENE_UMGEBUNG>)" für individuelle Diskussionsfäden.

    Wenn das zu unübersichtlich wird, kann man ggf. auch neue Unterforen einrichten; dann wäre ein (besserer) Startpunkt vielleicht "Systemabsicherung > Allgemein", gefolgt von "Systemabsicherung > Kernel", "Systemabsicherung > …"

    (Leider scheint es noch nicht möglich zu sein, nutzerseitig zusätzlich Tags zu einem Post hinzuzufügen, was ggf. die Suche vereinfachen würde.)

    [ CC Moderatoren ]

  • Das längste Thema

    Moderatoren : Könnten wir unter Sonstiges ein Unterforum "Systemabsicherung" bekommen, in welchem die Themen rund um Exploits zentral gesammelt werden können? Ansonsten dürften die "etwas untergehen", insbesondere, wenn Nutzer nicht regelmäßig eine große Zahl an Themen hier verfolgen …

  • Das längste Thema

    Da will man am Morgen einen neuen Post bzgl. dringend selbst abzusichernder Linux-Kernel hier einstellen, schon läuft wieder ein größerer Lieferkettenangriff ("Mini Shai-Hulud", zielt auf npm und PyPI). Naja, ist ja bald Freitag (und für manche quasi ein verlängertes Wochenende wg. Brückentag und so), also warte ich mit dem Post noch ein paar Tage … :evil:

    An dieser Stelle nochmal der Tip, keine Module zu installieren, welche kein vorgegebenes/erzwungenes Mindestalter von n Tagen aufweisen. Und wo ich das hier gerade schreibe, darf ich gleich einmal sehen, ob das eigene Build-Script für eine bestimmte Java-Anwendung auf Basis einer anderen bestimmten Rust-Bibliothek diesen Grundsatz auch konsistent einhält (vgl. cargo-cooldown-PoC). Gut, dass wir bald ein verlängertes Wochende haben … :|

    EDIT: Wir könnten das zum Anlass nehmen, und einmal für obige Stacks ein paar eigene Lösungsansätze zusammenzutragen (vgl. diese Kurzübersicht), wie wär's?

  • Das längste Thema

    Zitat von fvbor

    Und ich nutze es gerade so gut wie nicht mehr, weil Ubuntu 26.04 LTS auf sudo-rs umgestellt hat und ansible noch sudo erwartet. become für sudo geht leider immer noch nicht :(

    Ich nutze zwar noch 24.04 LTS, habe aber u. a. in einer Build-Umgebung dafür aktuelle Versionen von sudo und coreutils von Debian "nachgebaut" und installiert; zumindest für sudo allein ist das recht schmerzfrei, wenn man das Paket installiert und via apt-mark hold vor einer späteren automatischen Ersetzung schützt. Natürlich bedeutet das, dass man selbst für Updates für dieses Paket sorgen muss, aber den relativ überschaubaren Mehraufwand ist es IMHO für die eigenen Umgebungen wirklich wert.

  • Das längste Thema

    FYI: Es ist Freitag und somit Zeit für den nächsten Linux-Sicherheitslücken-GAU: Dirty Frag: Universal Linux LPE (betrifft alle Linux-Distros!)

    (Embargo-Bruch "von dritter Seite" führte dazu, dass es bislang für keine der Distributionen eine Korrektur gibt; es gibt aus Zeitgründen noch nicht einmal eine CVE-Kennung!!! die inzwischen vergebene CVE-Kennung lautet CVE-2026-43284.)

    Zitat

    Dirty Frag is a case that extends the bug class to which Dirty Pipe and Copy Fail belong. Because it is a deterministic logic bug that does not depend on a timing window, no race condition is required, the kernel does not panic when the exploit fails, and the success rate is very high.

    Workaround: Auf die Nutzung der betroffenen Module verzichten und ihre Aktivierung blockieren, sofern sie nicht in den Kernel einkompiliert wurden:

    Code
    for MODULE in esp4 esp6 rxrpc; do grep -qE "^${MODULE} " /proc/modules && echo "Affected module ${MODULE} is loaded" || echo "Affected module ${MODULE} is NOT loaded"; done
KERNEL="$(uname -r)"; for MODULE in esp4 esp6 rxrpc; do grep -qw "${MODULE}" "/lib/modules/${KERNEL}/modules.builtin" && echo "Module ${MODULE} is built directly into kernel ${KERNEL}!"; done

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

    Mögliche Seiteneffekte der Deaktivierung:

    Zitat

    esp4 / esp6 are the kernel-side ESP transforms used by IPsec. Disabling them breaks IPsec tunnels that rely on the kernel data path on the affected machine. Do not apply this mitigation to hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels.

    rxrpc is the AF_RXRPC transport used almost exclusively by AFS clients and is not present on typical web-hosting servers.

    Wer den obigen Exploit ausprobiert hat und/oder sichergehen will, dass das laufende System nicht kompromittiert ist, sollte analog zu der Vorgehensweise bei Copy_Fail die entsprechende Rechnerinstanz danach entweder neu booten oder die von Olivetti hier erwähnte Methode zum Löschen der Caches verwenden:

    Code
    tee /proc/sys/vm/drop_caches <<<'echo 3'


    (Evaluation von GhostBSD für den Einsatz auf zumindest einigen Systemen ist auf der eigenen TODO-Liste gerade wieder weiter nach oben gerutscht. :pinch:)

  • Das längste Thema

    Zitat von cstv

    Hallo, ich bin ein ARM-VPS-Nutzer in Manassas und bin damit zufrieden, aber ich frage mich, ob ich dedizierte ARM-Instanzen erwerben kann. Entschuldigung, falls das seltsam klingt – ich kann kein Deutsch und verwende eine Übersetzungssoftware.

    You are not alone in this wish; unfortunately, Netcup don't currently offer dedicated "RS" instances. (The translation software works perfectly, by the way. ;))

  • Das längste Thema

    Auf GitHub werden derzeit Testergebnisse zusammengetragen, und die sind doch sehr … durchwachsen. Die "copy.fail-Thematik" ist offenbar komplexer/von mehreren Vorbedingungen abhängig und damit weniger generisch, als es die Exploit-Beschreibung glauben macht.

    Aber solange sich kein lokaler Dienst auf den Hosts lautstark beschwert, dass er "so nicht arbeiten könne", bleibt die obige Lösung hier permanent installiert und kommt in die eigene Standardinstallationsschablone (und auch in alle Rescue-Abbilder!) …