Announcement

Collapse
No announcement yet.

Systemd 241 Being Prepared With "System Down" Security Fixes

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Systemd 241 Being Prepared With "System Down" Security Fixes

    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?pag...ep-System-Down

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

    Comment


    • #3
      Would Rust have prevented this?

      Comment


      • #4
        Originally posted by garegin View Post
        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.
        Last edited by caligula; 01-13-2019, 10:23 AM.

        Comment


        • #5
          Originally posted by hreindl View Post
          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?

          Comment


          • #6
            Could it just be that systemd's code is a mess that relies on
            Code:
            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).

            Comment


            • #7
              Originally posted by caligula View Post

              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?

              Comment


              • #8
                Originally posted by hussam View Post
                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)?

                Originally posted by caligula View Post
                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.

                Comment


                • #9
                  Originally posted by hreindl View Post

                  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

                  [[email protected]:~]$ dmesg
                  dmesg: read kernel buffer failed: Operation not permitted
                  Perfectly works here on Fedora 29.

                  Code:
                  [[email protected] ~]$ 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'
                  
                  [[email protected] ~]$ 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

                  Comment


                  • #10
                    Originally posted by caligula View Post
                    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 hussam 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...
                    Last edited by lucrus; 01-13-2019, 11:30 AM.

                    Comment

                    Working...
                    X