Systemd 241 Being Prepared With "System Down" Security Fixes

[phoronix]

Phoronix: Systemd 241 Being Prepared With "System Down" Security Fixes

While systemd 240 was released right before Christmas, it looks like systemd 241 will soon be released in order to address the recent "System Down" security vulnerabilities...

http://www.phoronix.com/scan.php?page=news_item&px=Systemd-241-Prep-System-Down

[R41N3R]

Probably Arch Linux doesn't use GCC's stack clash protection, so good to know that there will be the 241 release soon!

[garegin]

Would Rust have prevented this?

[caligula]

Would Rust have prevented this?

I suppose so if you use bounds checked arrays.

The main reason why C does allow out of bounds access is that storing the array length was horribly expensive when computers had only 1 to 32 kB of RAM. Now they have 32 GB, but C programmers will still argue that billion dollar bugs every now and then are way better than wasting 4 bytes worth of space for every array.

[jpg44]

in the meantime "/etc/systemd/system/systemd-journald.service.d/security.conf" restricts a potential root exploit so that nobody can place authorized ssh keys and directly write into OS files while i wonder why this settings are not default given that despite to all the haters systemd normally restricts all it#s processes as tight as possible with all the cgroup and namespace features the linux kernel provides

for recent systemd versions



and for CentOS7

Is there a reason it needs to be run as root at all, why not a normal user, with an apparmor profile by default?

[Guest]

Could it just be that systemd's code is a mess that relies on

alloca()

, a security nightmare? Of course it makes it easier to write C, but the cost for that is way too high. It should be forgotten and never used again, just like VLAs. I'd say that if they put in the necessary effort to remove all uses of it from the code base, they'd make it much more secure (especially because they'd be able to notice plenty of mistakes around these parts of the code base as they're rewriting it).

[Guest]

I suppose so if you use bounds checked arrays.

The main reason why C does allow out of bounds access is that storing the array length was horribly expensive when computers had only 1 to 32 kB of RAM. Now they have 32 GB, but C programmers will still argue that billion dollar bugs every now and then are way better than wasting 4 bytes worth of space for every array.

Hypothetically speaking, how would one store a length property in a C array anyway? An extra 4 bytes at the end for the size at the end of the bytes sequence?

[Weasel]

Hypothetically speaking, how would one store a length property in a C array anyway? An extra 4 bytes at the end for the size at the end of the bytes sequence?

Length gives you size of array, so place it at the end which requires knowing the size of the array? Real smart.

How about, idk, maybe before the array? Fixed byte offset of -sizeof(length)?

The main reason why C does allow out of bounds access is that storing the array length was horribly expensive when computers had only 1 to 32 kB of RAM. Now they have 32 GB, but C programmers will still argue that billion dollar bugs every now and then are way better than wasting 4 bytes worth of space for every array.

1 byte is always = 1 byte. Doesn't matter your amount of RAM (or more importantly, CPU cache).

Automatic bounds checks are garbage because they apply everywhere, even in places where they are not needed, which is disgusting (not just the bytes, lol, also execution, wasting an entry in the branch predictor, and cache pollution).

Useless bounds checks also make you more vulnerable to Spectre. The irony.

[birdie]

most likely because it needs to access /dev/kmsg to collect kernel messages which is not possible on proper configured systems (kernel.dmesg_restrict = 1, kernel.kptr_restrict = 2, kernel.yama.ptrace_scope = 2) and apparmor is not used by that much distributions at all

[harry@srv-rhsoft:~]$ dmesg
dmesg: read kernel buffer failed: Operation not permitted

Perfectly works here on Fedora 29.

[birdie@localhost ~]$ cat /dev/kmsg | head
5,0,0,-;Linux version 4.18.16-300.fc29.x86_64 ([email protected]) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018
6,1,0,-;Command line: BOOT_IMAGE=/vmlinuz-4.18.16-300.fc29.x86_64 root=UUID=XXX ro quiet LANG=en_US.UTF-8
6,2,0,-;x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
6,3,0,-;x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
6,4,0,-;x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'

[birdie@localhost ~]$ ls -Zl /dev/kmsg
crw-r--r--. 1 root root system_u:object_r:kmsg_device_t:s0 1, 11 Jan 13 11:04 /dev/kmsg

[lucrus]

Now they have 32 GB, but C programmers will still argue that billion dollar bugs every now and then are way better than wasting 4 bytes worth of space for every array.

As Guest already pointed out, there's no way to store that information in a C array, without completely breaking compatibility with almost all existing C code. We could imagine to invent a optional compiler switch that automatically adds code to:

1. store the array size somewhere else, maybe a portion of the heap memory, but not into the array itself, when the array is created or the pointer is referenced. That alone would hit performance to a level that would render C useless.
2. enable automatic checks on every array access (square brackets) and pointer dereference, by looking up bounds stored in point 1. That would render any C code execution slower than ancient Scheme on a 80286 machine.
3. garbage collect all the sheer amount of array and pointer sizes information stored in 1.

If you really want that all, then I have good news for you: that compiler switch already exists. You can switch to javac...