Dev1 Galaxy Forum / It's not just Wondows: apparently we have a problem

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

dummy@example.com (steve_v) — Fri, 23 Jul 2021 07:12:37 +0000

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.

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

dummy@example.com (zapper) — Fri, 23 Jul 2021 03:08:34 +0000

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.

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

dummy@example.com (steve_v) — Thu, 22 Jul 2021 04:47:46 +0000

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.

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

dummy@example.com (Altoid) — Wed, 21 Jul 2021 19:20:28 +0000

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,

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

dummy@example.com (Dutch_Master) — Wed, 21 Jul 2021 18:55:07 +0000

Altoid wrote:

Maybe they should weigh the risk again?

They should, including using systemd as default init system

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

dummy@example.com (Altoid) — Wed, 21 Jul 2021 18:50:28 +0000

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,

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

dummy@example.com (Head_on_a_Stick) — Wed, 21 Jul 2021 17:04:28 +0000

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

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

dummy@example.com (andyprough) — Wed, 21 Jul 2021 13:33:42 +0000

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

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

dummy@example.com (Altoid) — Wed, 21 Jul 2021 12:04:23 +0000

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,