It's not just Wondows: apparently we have a problem

Altoid · 2021-07-21 12:04:23

Hello:

From this morning's edition of ElReg:

https://www.theregister.com/2021/07/21/ … scalation/

Richard Speed wrote:

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.

andyprough · 2021-07-21 13:33:42

Moral of the story - don't give rogue users direct access to your system. That is a "bad" thing.

Head_on_a_Stick · 2021-07-21 17:04:28

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)

Altoid · 2021-07-21 18:50:28

Hello:

Head_on_a_Stick wrote:

... local vulnerability so unlikely to trouble most desktop users.

Good to know.

Head_on_a_Stick wrote:

... 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.

Dutch_Master · 2021-07-21 18:55:07

Altoid wrote:

Maybe they should weigh the risk again?

They should, including using systemd as default init system

Altoid · 2021-07-21 19:20:28

Hello:

Dutch_Master wrote:

... including using systemd as default init system

Indeed.

I was being facetious, I seriously doubt they will backpedal on this.

Best,

A.

steve_v · 2021-07-22 04:47:46

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.

Last edited by steve_v (2021-07-22 04:48:28)

zapper · 2021-07-23 03:08:34

steve_v wrote:

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.

steve_v · 2021-07-23 07:12:37

zapper wrote:

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)

The officially official Devuan Forum!

#1 2021-07-21 12:04:23

It's not just Wondows: apparently we have a problem

#2 2021-07-21 13:33:42

Re: It's not just Wondows: apparently we have a problem

#3 2021-07-21 17:04:28

Re: It's not just Wondows: apparently we have a problem

#4 2021-07-21 18:50:28

Re: It's not just Wondows: apparently we have a problem

#5 2021-07-21 18:55:07

Re: It's not just Wondows: apparently we have a problem

#6 2021-07-21 19:20:28

Re: It's not just Wondows: apparently we have a problem

#7 2021-07-22 04:47:46

Re: It's not just Wondows: apparently we have a problem

#8 2021-07-23 03:08:34

Re: It's not just Wondows: apparently we have a problem

#9 2021-07-23 07:12:37

Re: It's not just Wondows: apparently we have a problem

Board footer