5 ms·

I don't think these questions are that interesting. SSHD shared an address space with xz-utils because xz utils provides a shared library, and that's how dynami

by duped 3y ago

I don't think these questions are that interesting. SSHD shared an address space with xz-utils because xz utils provides a shared library, and that's how dynamic linking works. sshd uses libsystemd on platforms with systemd because systemd is the tool that manages daemons and services like sshd, and libsystemd is the bespoke way for daemons to talk to it (and more importantly, it is already there in the distro - so you're not "adding a million line dependency" so much as linking against a system library from the OS developers that you need). Linking against libsystemd on Debian is about as suspicious as linking against libsystem on MacOS. It's a userspace library that you can hypothetically avoid, but you shouldn't. As for why systemd links against xz, I don't know, and it's a bit surprising that an init system needs compression utils but not particularly surprising given the kitchen sink architecture of systemd.

cesarb 3y ago
> As for why systemd links against xz, I don't know, and it's a bit surprising that an init system needs compression utils It's for the journal. It can be optionally compressed with zlib, lzma, or zstd. That library had not only the sd_notify function which sshd needed, but also several functions to manipulate the journal.
chubot 3y ago
and that's how dynamic linking works -- really ignorant comment Read the lobste.rs thread for some quotes on process separation and the Unix philosophy. There are mechanisms other than dynamic linking -- this is precisely the question. Also, Unix supported remote logins BEFORE dynamic linking existed. --- What about sshd didn't work prior to 2015? Was the dependency worth it? not particularly surprising given the kitchen sink architecture of systemd That's exactly the point -- does systemd need a kitchen sink architecture? --- The questions are interesting because they likely lead to simple and effective mitigations. They are interesting because critical dependencies on poorly maintained projects may cause nation states to attack single maintainers with social engineering. Solutions like "let's create a Big tech funded consortium for security" already exist (Linux foundation threw some money at bash in 2014 after ShellShock). That can be part of the solution, but I doubt it's the most effective one.
- duped 3y ago
  I don't think it's acceptable to create a subprocess for what's effectively a library function call because it comes from a dependency. The problem is the design of rtld and the dynamic linking model, where one shared library can detect and hijack the function calls of another by using the auditing features of rtld. Hardened environments already forbid LD_PRELOAD for injection attacks like this, but miss audit hooks. My point is that just saying we should use the Unix process model as the defense for supply chain attacks is like using a hammer to fix a problem that needs a scalpel. > What about sshd didn't work prior to 2015? systemd notifications, from what it sounds like.
  - chubot 3y ago
    I don't agree -- process isolation is a simple, effective, and traditional mechanism. It has downsides (e.g. parsing and serializing), but they don't apply here. Many mitigations work at the process level, like ASLR, cgroups, and more. There's a reason that Chrome doesn't allow parsing and rendering in the same process: https://www.chromium.org/developers/design-documents/multi-process-architecture/ https://www.chromium.org/developers/design-documents/multi-p... Something like the rule of 2 should apply to the sshd -> xzutils dependency -- it's inherently dangerous. https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs... Note that Firefox spent years of engineering effort to catch up with Chrome, retrofitting a multiprocess architecture. Multiprocess architecture is demonstrably more secure, e.g. if you look at all the actual exploits from https://en.wikipedia.org/wiki/Pwn2Own https://en.wikipedia.org/wiki/Pwn2Own
    - duped 3y ago
      The fundamental difference is that processes are used to sandbox sections of the program that run untrusted code. A subroutine from a library isn't untrusted code. Having written multi-process programs used for this purpose, I disagree that it's simple or traditional for the purposes of hardening against supply chain attacks in shared libraries. Only at the most naive level is it appropriate. And on top of that, it would not have prevented the backdoor. It would only have changed the mechanism used to invoke it.

by duped 3y ago

cesarb 3y ago

> As for why systemd links against xz, I don't know, and it's a bit surprising that an init system needs compression utils It's for the journal. It can be optionally compressed with zlib, lzma, or zstd. That library had not only the sd_notify function which sshd needed, but also several functions to manipulate the journal.

chubot 3y ago

and that's how dynamic linking works -- really ignorant comment Read the lobste.rs thread for some quotes on process separation and the Unix philosophy. There are mechanisms other than dynamic linking -- this is precisely the question. Also, Unix supported remote logins BEFORE dynamic linking existed. --- What about sshd didn't work prior to 2015? Was the dependency worth it? not particularly surprising given the kitchen sink architecture of systemd That's exactly the point -- does systemd need a kitchen sink architecture? --- The questions are interesting because they likely lead to simple and effective mitigations. They are interesting because critical dependencies on poorly maintained projects may cause nation states to attack single maintainers with social engineering. Solutions like "let's create a Big tech funded consortium for security" already exist (Linux foundation threw some money at bash in 2014 after ShellShock). That can be part of the solution, but I doubt it's the most effective one.

duped 3y ago
I don't think it's acceptable to create a subprocess for what's effectively a library function call because it comes from a dependency. The problem is the design of rtld and the dynamic linking model, where one shared library can detect and hijack the function calls of another by using the auditing features of rtld. Hardened environments already forbid LD_PRELOAD for injection attacks like this, but miss audit hooks. My point is that just saying we should use the Unix process model as the defense for supply chain attacks is like using a hammer to fix a problem that needs a scalpel. > What about sshd didn't work prior to 2015? systemd notifications, from what it sounds like.
- chubot 3y ago
  I don't agree -- process isolation is a simple, effective, and traditional mechanism. It has downsides (e.g. parsing and serializing), but they don't apply here. Many mitigations work at the process level, like ASLR, cgroups, and more. There's a reason that Chrome doesn't allow parsing and rendering in the same process: https://www.chromium.org/developers/design-documents/multi-process-architecture/ https://www.chromium.org/developers/design-documents/multi-p... Something like the rule of 2 should apply to the sshd -> xzutils dependency -- it's inherently dangerous. https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md https://chromium.googlesource.com/chromium/src/+/master/docs... Note that Firefox spent years of engineering effort to catch up with Chrome, retrofitting a multiprocess architecture. Multiprocess architecture is demonstrably more secure, e.g. if you look at all the actual exploits from https://en.wikipedia.org/wiki/Pwn2Own https://en.wikipedia.org/wiki/Pwn2Own
  - duped 3y ago
    The fundamental difference is that processes are used to sandbox sections of the program that run untrusted code. A subroutine from a library isn't untrusted code. Having written multi-process programs used for this purpose, I disagree that it's simple or traditional for the purposes of hardening against supply chain attacks in shared libraries. Only at the most naive level is it appropriate. And on top of that, it would not have prevented the backdoor. It would only have changed the mechanism used to invoke it.