3 ms·

libsystemd is too juicy of a target, especially with the code reuse that does not appear to take into account these attack vectors. Perhaps any reuse of librar

libsystemd is too juicy of a target, especially with the code reuse that does not appear to take into account these attack vectors. Perhaps any reuse of libraries in sensitive areas like libsystemd should require a separate copy and more rigorous review? This would allow things like libxv to be 'reused', but the 'safe' versions would require a separate codebase that gets audited updates from the mainline.

kuschku 3y ago
libsystemd had already removed the lzma dependencies last week, before the backdoor became public, to reduce external dependencies.
- xorcist 3y ago
  No they did not. The dependency is still there, it's just being lazy loaded. This would be prevented this particular exploit, which would have needed to take another approach, but at the price of making dependencies invisible and hard to debug. You could no longer have found vulnerable systems by way of ldd. The only solution for the attack surface of systemd is to make the individual components more loosely coupled. There is no reason the same library is responsible for readiness reporting and reading logs. One could even argue that none of those functions have anything to do with the job of init. Readiness can break in a number of ways, robustness is built on health checks.
  - kuschku 3y ago
    Even if it hadn't been loaded by libsystemd, liblzma is also loaded by SELinux, which would have allowed the same vulnerability via a different vector. Personally I think projects like fedora silverblue/kinoite and other container-based OSes are going in the right direction. We need a base OS that's as small as possible so it can be audited, and everything else then needs to live in a container so it doesn't have to be audited but is still secured properly.
    - xorcist 3y ago
      Well, not the same vulnerability, as libselinux isn't loaded by sshd. Any such request would probably have a low probability of acceptance among the openssh maintainers. If anything, I think this shows that real world security is hard and must happen at every level. This library is likely to be included in any base OS no matter how small, and rebuilding the container world just to patch is inefficient. This attack may have been found by luck alone, even if that luck involved having talented developers on our side, but it really showed how well the open source community responds to such attacks. Within a day of it being public, we had well mapped out what the problem was and how to best respond to it. A day that was also a holiday in large parts of the world.
- deleted 3y ago
  [deleted]

kuschku 3y ago

libsystemd had already removed the lzma dependencies last week, before the backdoor became public, to reduce external dependencies.

xorcist 3y ago
No they did not. The dependency is still there, it's just being lazy loaded. This would be prevented this particular exploit, which would have needed to take another approach, but at the price of making dependencies invisible and hard to debug. You could no longer have found vulnerable systems by way of ldd. The only solution for the attack surface of systemd is to make the individual components more loosely coupled. There is no reason the same library is responsible for readiness reporting and reading logs. One could even argue that none of those functions have anything to do with the job of init. Readiness can break in a number of ways, robustness is built on health checks.
- kuschku 3y ago
  Even if it hadn't been loaded by libsystemd, liblzma is also loaded by SELinux, which would have allowed the same vulnerability via a different vector. Personally I think projects like fedora silverblue/kinoite and other container-based OSes are going in the right direction. We need a base OS that's as small as possible so it can be audited, and everything else then needs to live in a container so it doesn't have to be audited but is still secured properly.
  - xorcist 3y ago
    Well, not the same vulnerability, as libselinux isn't loaded by sshd. Any such request would probably have a low probability of acceptance among the openssh maintainers. If anything, I think this shows that real world security is hard and must happen at every level. This library is likely to be included in any base OS no matter how small, and rebuilding the container world just to patch is inefficient. This attack may have been found by luck alone, even if that luck involved having talented developers on our side, but it really showed how well the open source community responds to such attacks. Within a day of it being public, we had well mapped out what the problem was and how to best respond to it. A day that was also a holiday in large parts of the world.
deleted 3y ago
[deleted]