4 ms·

> And for almost all systems I’d say “yes, absolutely”. Do you even understand that you are advocating in favour of perpetually vulnerable systems? Let's not

> And for almost all systems I’d say “yes, absolutely”. Do you even understand that you are advocating in favour of perpetually vulnerable systems? Let's not touch the fact that there are vague and fantastic claims about shared libraries being this never ending sources of problems (which no one actually experiences) that when asked to elaborate the best answer is wand waving and hypotheticals and non-sequiturs. With this fact out if the way, what is your plan to update all downstream dependencies when a vulnerability is identified?

csande17 4y ago
Before you decry statically linked systems as "perpetually vulnerable", I'd advise you take a look at the number of privilege escalation vulnerabilities caused by LD_PRELOAD alone.
- hedora 4y ago
  That's like claiming that a leaky sump pump sank the titanic. Linux has never been anywhere close to resistant to privilege escalation bugs.
- arinlen 4y ago
  > Before you decry statically linked systems as "perpetually vulnerable" But statically linked systems are perpetually vulnerable by design, aren't they? I mean, what's your plan to fix a vulnerable dependency once a patch is available? Are you tracking each and every dependency that directly or indirectly consumes the vulnerable library? Are you hoping to have access to their source code, regardless of where they came from, and rebuild all libraries and applications? Because with shared libraries, all it takes to patch a vulnerable library is to update just the one lib, and all downstream consumers are safe. What's your solution for this problem? Do you have any at all?
  - csande17 4y ago
    What's your plan if fixing a vulnerability requires changing the size of a struct?
    - arinlen 4y ago
      > What's your plan if fixing a vulnerability requires changing the size of a struct? Do you actually have an answer any of the points I presented you, or are you going to continue desperately trying to put up strawmen? If any of your magical static lib promises had at bearing in the real world, you wouldn't have such a hard time trying to come up with any technical justification for them.
      - csande17 4y ago
        The argument that you seem to be making is that under dynamic linking, there is never any reason to need to recompile an application, and thus the fact that static linking forces you to recompile applications makes it non-viable from a security perspective. Unfortunately, this is very far from being true in the real world. And even if all libraries did maintain 100% ABI compatibility forever, and even if there were never any compiler or processor bugs that needed to be mitigated by recompiling applications, dynamic linking would still add runtime complexity and thus surface area for security vulnerabilities. > Are you tracking each and every dependency that directly or indirectly consumes the vulnerable library? Are you hoping to have access to their source code, regardless of where they came from, and rebuild all libraries and applications? Yes? I mean, are you just throwing random untrusted binaries onto your servers, not keeping track of what their dependencies are, and hoping to God that you will never ever need to recompile them? (And if your explanation for that is "I use proprietary software from vendors who refuse to share source code", have you chosen incompetent vendors who cannot respond to security vulnerabilities in a timely fashion?)
        AlphaCenturion 4y ago
        What is your plan?
        csande17 4y ago
        Four-part plan is this: 1. For each application and library in the system, maintain a copy of the source code and the scripts necessary to rebuild it. 2. Keep track of the dependency tree of each application and library in the system. 3. If there's a problem with a dependency, update it and rebuild all dependent applications. 4. If I'm using binaries from a vendor (whether that's a Linux distribution or a proprietary software company), the vendor needs to be responsible for (1) to (3). In practice, your package manager will generally implement almost all of (1) to (3) for you. (Newfangled systems like NPM or Cargo usually do it using lockfiles and automated tools like Dependabot.) If you're using dynamic linking, guess what? You still have to do these four things, because even with dynamic linking, there are still problems that can only be solved by recompiling your software. Even if you think reasons like ABI incompatibility or processor bugs aren't compelling, there might be, y'know, bugs in the applications themselves that you've gotta patch.

csande17 4y ago

Before you decry statically linked systems as "perpetually vulnerable", I'd advise you take a look at the number of privilege escalation vulnerabilities caused by LD_PRELOAD alone.

hedora 4y ago
That's like claiming that a leaky sump pump sank the titanic. Linux has never been anywhere close to resistant to privilege escalation bugs.
arinlen 4y ago
> Before you decry statically linked systems as "perpetually vulnerable" But statically linked systems are perpetually vulnerable by design, aren't they? I mean, what's your plan to fix a vulnerable dependency once a patch is available? Are you tracking each and every dependency that directly or indirectly consumes the vulnerable library? Are you hoping to have access to their source code, regardless of where they came from, and rebuild all libraries and applications? Because with shared libraries, all it takes to patch a vulnerable library is to update just the one lib, and all downstream consumers are safe. What's your solution for this problem? Do you have any at all?
- csande17 4y ago
  What's your plan if fixing a vulnerability requires changing the size of a struct?
  - arinlen 4y ago
    > What's your plan if fixing a vulnerability requires changing the size of a struct? Do you actually have an answer any of the points I presented you, or are you going to continue desperately trying to put up strawmen? If any of your magical static lib promises had at bearing in the real world, you wouldn't have such a hard time trying to come up with any technical justification for them.
    - csande17 4y ago
      The argument that you seem to be making is that under dynamic linking, there is never any reason to need to recompile an application, and thus the fact that static linking forces you to recompile applications makes it non-viable from a security perspective. Unfortunately, this is very far from being true in the real world. And even if all libraries did maintain 100% ABI compatibility forever, and even if there were never any compiler or processor bugs that needed to be mitigated by recompiling applications, dynamic linking would still add runtime complexity and thus surface area for security vulnerabilities. > Are you tracking each and every dependency that directly or indirectly consumes the vulnerable library? Are you hoping to have access to their source code, regardless of where they came from, and rebuild all libraries and applications? Yes? I mean, are you just throwing random untrusted binaries onto your servers, not keeping track of what their dependencies are, and hoping to God that you will never ever need to recompile them? (And if your explanation for that is "I use proprietary software from vendors who refuse to share source code", have you chosen incompetent vendors who cannot respond to security vulnerabilities in a timely fashion?)
      - AlphaCenturion 4y ago
        What is your plan?
        csande17 4y ago
        Four-part plan is this: 1. For each application and library in the system, maintain a copy of the source code and the scripts necessary to rebuild it. 2. Keep track of the dependency tree of each application and library in the system. 3. If there's a problem with a dependency, update it and rebuild all dependent applications. 4. If I'm using binaries from a vendor (whether that's a Linux distribution or a proprietary software company), the vendor needs to be responsible for (1) to (3). In practice, your package manager will generally implement almost all of (1) to (3) for you. (Newfangled systems like NPM or Cargo usually do it using lockfiles and automated tools like Dependabot.) If you're using dynamic linking, guess what? You still have to do these four things, because even with dynamic linking, there are still problems that can only be solved by recompiling your software. Even if you think reasons like ABI incompatibility or processor bugs aren't compelling, there might be, y'know, bugs in the applications themselves that you've gotta patch.