You are not logged in.
Hello:
From this morning's edition of ElReg:
https://www.theregister.com/2021/07/21/ … scalation/
It's not just Windows: a security hole has been discovered in Linux kernels since version 3.16 that can be exploited by rogue users and malware already on a system to gain root-level privileges. The vulnerability has been assigned the ID CVE-2021-33909.
Dubbed Sequoia by the Qualys team that found and responsibly reported the flaw, we're told the bug is present in "default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, and Fedora 34 Workstation. Other Linux distributions are likely vulnerable and probably exploitable." Thus, check for updates and install them as soon as you can as patches should be available by now now or shortly for your distro.
Technical details of the file-system-code-level programming blunder are here. Qualys' proof-of-concept exploit required 5GB of RAM and a million inodes to succeed.
Qualys also found another security weakness in Linux systems, CVE-2021-33910, a denial-of-service kernel panic via systemd. Patches are also available so grab those updates, too.
I don't know how high the possibilities of this being executed are, but I thought I'd point to it for those who know more about these things.
Best,
A.
Offline
Moral of the story - don't give rogue users direct access to your system. That is a "bad" thing.
Offline
It's a local vulnerability so unlikely to trouble most desktop users. But it is exploitable in Debian 11 (and hence Devuan chimaera) because user namespaces have been enabled by default:
https://www.debian.org/releases/bullsey … namespaces
Bad decision...
EDIT:
https://security-tracker.debian.org/tra … 2021-33909
Last edited by Head_on_a_Stick (2021-07-21 17:08:52)
Brianna Ghey — Rest In Power
Offline
Hello:
... local vulnerability so unlikely to trouble most desktop users.
Good to know.
... exploitable in Debian 11 ...
... user namespaces have been enabled by default:
Bad decision...
Yes, I agree.
... Debian default was to restrict this feature to processes running as root, because it exposed more security issues in the kernel.
... confident that the risk of enabling it is outweighed by the security benefits ...
https://security-tracker.debian.org/tra … 2021-33909
Maybe they should weigh the risk again?
Thank for your input.
Best,
A.
Offline
Maybe they should weigh the risk again?
They should, including using systemd as default init system
Offline
Hello:
... including using systemd as default init system
Indeed.
I was being facetious, I seriously doubt they will backpedal on this.
Best,
A.
Offline
Moral of the story - don't give rogue users direct access to your system.
...And if you must give untrusted users a shell, at least put sane limits on the system resources they can consume. There aren't many legitimate reasons an untrusted user process needs 5GB of RAM and a million inodes.
systemd
Funny you should mention that, as there's an example of the inevitable consequences of running such a large codebase as PID1 linked in that same Reg article.
Remember how us old-school *nix nerds said PID1 should be as simple as possible, since a crash there will bring the whole system down?
In some 20+ years I have never seen nor heard tell of an unprivileged process crashing sysv init, yet here we are again with systemd.
This one was at least patched quickly, but the core design fault isn't going away - on the contrary, systemd is getting fatter with every release and the potential attack surface just keeps on growing.
Last edited by steve_v (2021-07-22 04:48:28)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Online
andyprough wrote:Moral of the story - don't give rogue users direct access to your system.
...And if you must give untrusted users a shell, at least put sane limits on the system resources they can consume. There aren't many legitimate reasons an untrusted user process needs 5GB of RAM and a million inodes.
Dutch_Master wrote:systemd
Funny you should mention that, as there's an example of the inevitable consequences of running such a large codebase as PID1 linked in that same Reg article.
Remember how us old-school *nix nerds said PID1 should be as simple as possible, since a crash there will bring the whole system down?
In some 20+ years I have never seen nor heard tell of an unprivileged process crashing sysv init, yet here we are again with systemd.
This one was at least patched quickly, but the core design fault isn't going away - on the contrary, systemd is getting fatter with every release and the potential attack surface just keeps on growing.
Maybe then at some point, they will actually learn their lesson if a bad enough crash happens...
Although, that would be pretty damn frightening, so I really hope they don't have to go that far down just to learn a simple lesson.
Freedom is never more than one generation away from extinction. Feelings are not facts
If you wish to be humbled, try to exalt yourself long term If you wish to be exalted, try to humble yourself long term
Favourite operating systems: Hyperbola Devuan OpenBSD
Peace Be With us All!
Offline
I really hope they don't have to go that far down just to learn a simple lesson.
TBH I don't think anyone is learning anything, at least as far as systemd development is concerned.
The katamari must roll on after all, how else are the devs going to keep their KPIs up?
I mean, everyone likes shiny new shit (especially shareholders and corporate sponsors), and we can just patch the bugs later, right?
Hell, in this day and age you don't even need a competent sysadmin (or distro maintainer) to test and deploy patches, you just sign up to Kaseya for all your cloud-based update ransomware management goodness...
All of this reminds me of a rather old adage, IIRC it had some wise words regarding eggs and baskets.
Last edited by steve_v (2021-07-23 07:33:19)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Online