NEWS
sudo sicherheitslücke und nachfolgende forschung
-
Für diejenigen die Debian einsetzen können, so wie ich es interpretiere beruhigt sein.
Hier der folgende Text
[bookworm] - sudo <not-affected> (Vulnerable code introduced later)
[bullseye] - sudo <not-affected> (Vulnerable code introduced later)Von dieser Seite
Synology DS218+ & 2 x Fujitsu Esprimo (VM/Container) + FritzBox7590 + 2 AVM 3000 Repeater & Homematic & HUE & Osram & Xiaomi, NPM 10.9.4, Nodejs 22.21.0 ,JS Controller 7.0.7 ,Admin 7.7.19
-
@haselchen
Gute Ergänzung.
Trixie ist zwar noch testing und sollte noch nicht produktiv eingesetzt werden und wer da schon aktualisiert hat, weiß was er tut ? -
@haselchen
Gute Ergänzung.
Trixie ist zwar noch testing und sollte noch nicht produktiv eingesetzt werden und wer da schon aktualisiert hat, weiß was er tut ?Wie immer gilt halt der Grundsatz: Halt die Kiste immer auf dem aktuellen Stand. Regelmäßig. Und verwende stabile Releases und keine Klamotten, die das End Of Life überschritten haben.
Mein Endeavour OS:
[thomas@roamer ~]$ pacman -Ss sudo core/sudo 1.9.17.p1-1 [Installiert]Trixie ist noch Testing, das hängt natürlich hinterher, weil das momentan im Freeze ist. Wird ja auch nicht produktiv verwendet. Bullseye und Bookworm sind nicht betroffen, weil die Lücke erst in neueren Versionen vorhanden ist. Da ist der Debian-Ansatz, einmal releaste Versionen nicht zu erhöhen der Grund.
Ich mache eigentlich ganz gerne solche Updates selber.
Was ist von solchen Mechanismen zu halten?Wobei sich das mit der Verwendung von Turnkey halt beißt. Das ist ja gerade das 'Versprechen' davon. Musste nix wissen oder machen, wird alles vorgekaut. Dann in der Konsequenz auch Updates.
-
Wie immer gilt halt der Grundsatz: Halt die Kiste immer auf dem aktuellen Stand. Regelmäßig. Und verwende stabile Releases und keine Klamotten, die das End Of Life überschritten haben.
Mein Endeavour OS:
[thomas@roamer ~]$ pacman -Ss sudo core/sudo 1.9.17.p1-1 [Installiert]Trixie ist noch Testing, das hängt natürlich hinterher, weil das momentan im Freeze ist. Wird ja auch nicht produktiv verwendet. Bullseye und Bookworm sind nicht betroffen, weil die Lücke erst in neueren Versionen vorhanden ist. Da ist der Debian-Ansatz, einmal releaste Versionen nicht zu erhöhen der Grund.
Ich mache eigentlich ganz gerne solche Updates selber.
Was ist von solchen Mechanismen zu halten?Wobei sich das mit der Verwendung von Turnkey halt beißt. Das ist ja gerade das 'Versprechen' davon. Musste nix wissen oder machen, wird alles vorgekaut. Dann in der Konsequenz auch Updates.
@thomas-braun sagte in sudo sicherheitslücke und nachfolgende forschung:
Wie immer gilt halt der Grundsatz: Halt die Kiste immer auf dem aktuellen Stand.
Und Debian ist ja auch aktuell bei v1.9.13p3 geblieben.
Man ist gut beraten auf dem aktuellen Debian repository zu reiten.
Proxmox und HA
-
@thomas-braun sagte in sudo sicherheitslücke und nachfolgende forschung:
Wie immer gilt halt der Grundsatz: Halt die Kiste immer auf dem aktuellen Stand.
Und Debian ist ja auch aktuell bei v1.9.13p3 geblieben.
Man ist gut beraten auf dem aktuellen Debian repository zu reiten.
@meister-mopper sagte in sudo sicherheitslücke und nachfolgende forschung:
Und Debian ist ja auch aktuell bei v1.9.13p3 geblieben.
Debian erhöht nie Versionen in einem (mal als stable veröffentlichten) Release. Da wird höchstens was gebackportet.
-
@meister-mopper sagte in sudo sicherheitslücke und nachfolgende forschung:
Und Debian ist ja auch aktuell bei v1.9.13p3 geblieben.
Debian erhöht nie Versionen in einem (mal als stable veröffentlichten) Release. Da wird höchstens was gebackportet.
Egal wie, sicher ist sicher!
-
Dies vorhin beim Nachhausekommen gelesen, und sofort angefangen die Updates der Linux-Systeme durchzuführen:
Interessanterweise lag auf meinen TurnkeyLinux Fileserver im LXC Container schon die aktualisierte sudo-Version
martin@fileserver ~$ tail /var/log/apt/history.log Start-Date: 2025-07-01 07:08:14 Commandline: /usr/bin/apt-get -o quiet=1 dist-upgrade -y -o APT::Get::Show-Upgraded=true -o Dir::Etc::sourcelist=/etc/apt/sources.list.d/security.sources.list -o Dir::Etc::sourceparts=nonexistent -o DPkg::Options::=--force-confdef -o DPkg::Options::=--force-confold Upgrade: sudo:amd64 (1.9.13p3-1+deb12u1, 1.9.13p3-1+deb12u2) End-Date: 2025-07-01 07:08:21 martin@fileserver ~$Zu der Zeit habe ich DEFINITIV nicht an der Konsole gesessen und das Update angestoßen ...
Dann gelesen, dass TurnkeyLinux anscheinend die Updates automatisch per cron Job ausführt ...
martin@fileserver ~$ cat /etc/cron.d/cron-apt # cron job for cron-apt package # randomized time to prevent clients from accessing repo at the same time 40 6 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-aptIch mache eigentlich ganz gerne solche Updates selber.
Was ist von solchen Mechanismen zu halten?@martinp sagte in sudo sicherheitslücke und nachfolgende forschung:
Interessanterweise lag auf meinen TurnkeyLinux Fileserver im LXC Container schon die aktualisierte sudo-Version
Nee, da liegt die 1.9.13p3-1+deb12u2 vom 24 Jun 2025:
https://metadata.ftp-master.debian.org/changelogs//main/s/sudo/sudo_1.9.13p3-1+deb12u2_changelog
Die aber (s. oben) gar nicht betroffen ist.
-
@martinp sagte in sudo sicherheitslücke und nachfolgende forschung:
Interessanterweise lag auf meinen TurnkeyLinux Fileserver im LXC Container schon die aktualisierte sudo-Version
Nee, da liegt die 1.9.13p3-1+deb12u2 vom 24 Jun 2025:
https://metadata.ftp-master.debian.org/changelogs//main/s/sudo/sudo_1.9.13p3-1+deb12u2_changelog
Die aber (s. oben) gar nicht betroffen ist.
@thomas-braun Gab wohl einen zweiten, weniger kritischen Issue.
Mehr sudo-Ungemach
Auch an einer weiteren Stelle in sudo fand der Sicherheitsforscher Rich Mirch eine Sicherheitslücke: Sind Kommandos in der Konfigurationsdatei /etc/sudoers auf bestimmte Hosts eingeschränkt, lässt sich diese Beschränkung durch geschickte Kombination mehrerer Kommandozeilenparameter überlisten. Die Lücke mit der CVE-ID 2025-32462 ist jedoch auf einem frisch installierten System mit Standardeinstellungen nicht ausnutzbar. Sie ist daher nur mit einem CVSS-Punktwert von 2,8 und niedriger Priorität eingestuft. Die Lücke lauerte seit 12 Jahren in sudo und ist nun in Version 1.9.17p1 oder neuer behoben. Übrigens anders als ihr "großer Bruder" auch auf Debian GNU/Linux: Dort behebt sudo 1.9.13p3-1+deb12u2 den Fehler.
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@thomas-braun Gab wohl einen zweiten, weniger kritischen Issue.
Mehr sudo-Ungemach
Auch an einer weiteren Stelle in sudo fand der Sicherheitsforscher Rich Mirch eine Sicherheitslücke: Sind Kommandos in der Konfigurationsdatei /etc/sudoers auf bestimmte Hosts eingeschränkt, lässt sich diese Beschränkung durch geschickte Kombination mehrerer Kommandozeilenparameter überlisten. Die Lücke mit der CVE-ID 2025-32462 ist jedoch auf einem frisch installierten System mit Standardeinstellungen nicht ausnutzbar. Sie ist daher nur mit einem CVSS-Punktwert von 2,8 und niedriger Priorität eingestuft. Die Lücke lauerte seit 12 Jahren in sudo und ist nun in Version 1.9.17p1 oder neuer behoben. Übrigens anders als ihr "großer Bruder" auch auf Debian GNU/Linux: Dort behebt sudo 1.9.13p3-1+deb12u2 den Fehler.
@martinp sagte in sudo sicherheitslücke und nachfolgende forschung:
Gab wohl einen zweiten, weniger kritischen Issue.
Ja, und der ist zurückportiert worden. Sieht man am Suffix
+deb12u2in der Versionierung. Debian ist da sehr transparent was da wann in welche Version eingewoben wurde. -
@martinp sagte in sudo sicherheitslücke und nachfolgende forschung:
Gab wohl einen zweiten, weniger kritischen Issue.
Ja, und der ist zurückportiert worden. Sieht man am Suffix
+deb12u2in der Versionierung. Debian ist da sehr transparent was da wann in welche Version eingewoben wurde.@thomas-braun Wobei gerade Trixie wohl aktuell im Freeze ist, vor den Rollentausch, wenn sid "testing" wird, und trixie "stable".
Sollte nach den Erfahrungswerten eigentlich spätestens in ~6 Wochen passieren... bookworm wird dann oldstable, und bullseye ... tja....
Kein Fix für Trixie verfügbar ...https://security-tracker.debian.org/tracker/CVE-2025-32463
auch der "kleine Issue
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@thomas-braun Wobei gerade Trixie wohl aktuell im Freeze ist, vor den Rollentausch, wenn sid "testing" wird, und trixie "stable".
Sollte nach den Erfahrungswerten eigentlich spätestens in ~6 Wochen passieren... bookworm wird dann oldstable, und bullseye ... tja....
Kein Fix für Trixie verfügbar ...https://security-tracker.debian.org/tracker/CVE-2025-32463
auch der "kleine Issue
@martinp sagte in sudo sicherheitslücke und nachfolgende forschung:
Wobei gerade Trixie wohl aktuell im Freeze ist,
ach was!
@thomas-braun sagte in sudo sicherheitslücke und nachfolgende forschung:
Trixie ist noch Testing, das hängt natürlich hinterher, weil das momentan im Freeze ist.
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@martinp sagte in sudo sicherheitslücke und nachfolgende forschung:
Wobei gerade Trixie wohl aktuell im Freeze ist,
ach was!
@thomas-braun sagte in sudo sicherheitslücke und nachfolgende forschung:
Trixie ist noch Testing, das hängt natürlich hinterher, weil das momentan im Freeze ist.
Support us
734
Online32.6k
Benutzer82.2k
Themen1.3m
Beiträge