Hacker News Reader

Comment by dcsommer | Hacker News Reader

How many systemd CVEs are memory or thread safety related?

I can't tell if this is rhetorical but... it looks like quite a few on the list. (Note: the CVE list is long but it looks inflated / full of not-serious issues.)

* CVE-2022-3821 : off by one error leading to buffer overflow

* CVE-2022-2526 : use after free

* CVE-2021-33910 : "Memory Allocation with an Excessive Size Value" (not sure if this qualifies... not interested enough to read the source)

I'd bet you get more CVEs and actual remote exploit entry points by systemd forcing mdns, bonjour, upnp and other zero conf hacks just because that was the work the systemd team was doing in rh before.

remembered another one. They use the same code for VM and bare metal. Including the easy-login convenience hacks.

So now anyone wanting physical access to your host, just have to intercept plain-text communication with the BIOS (after secureboot did its thing), and reply with a new root password when the OS request bios key 11 or something. evil maids are living the dream.

Is that with systemd logind? Why does logind interact with BIOS?

https://vincent.bernat.ch/en/blog/2021-startx-systemd

it's before logind. it creates arbitrary files in the root filesystem and is intended to write to the user authorized keys. so it works later with sort of login or remote access

Rust would have the same issues since you'd need to use unsafe code to achieve certain things systemd does.

What do memory and thread safety have to do with the project's stated goals? I for one would love to avoid systemd's arbitrary requirements while retaining compatibility with upstream (e.g. PID must be 1).

Reply on news.ycombinator.com