4 ms·

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 desi

by 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

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.