3 ms·

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. Ther

by 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 chubot 3y ago

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.