5 ms·

Worth mentioning that statically linked binaries prevent this attack vector. I won't weigh in on dynamic vs static in general but if you're shipping something y

by ghotli 3y ago

Worth mentioning that statically linked binaries prevent this attack vector. I won't weigh in on dynamic vs static in general but if you're shipping something you don't want fiddled with then maybe dynamic linking isn't what you're looking for. My favorite nasty hack along these lines was to inject a new implementation of gethostname via LD_PRELOAD as the simplest path to prevent a CI server from surfacing a hostname in a place it shouldn't be.

klysm 3y ago
I think this is a great entrypoint into the static/dynamic argument and I'd love to argue with some people about it. I believe dynamic used to make sense but no longer does in the vast majority of cases. Static binaries have their costs, but are so much easier to reason about.
- kreetx 3y ago
  If dynamic libraries are compatible to what they did (when you developed the program) then why waste disk and RAM?
  - aidenn0 3y ago
    Because disk and RAM are cheap and that's a huge "If"
    - deleted 3y ago
      [deleted]
    - jonhohle 3y ago
      There’s also other security considerations. As an operator or builder, do you want to patch a library (say OpenSSL) to keep your system up to date or patch every binary. If changing a dependency requires rebuilding all consumers recursively, the there’s not a huge benefit.
      - aidenn0 3y ago
        I think in the specific case of security issues, more bugs have been fixed by upgrading dynamic dependencies than introduced. That's just my gut feeling though, and I'd like to see data.
        rewmie 3y ago
        > I think in the specific case of security issues, more bugs have been fixed by upgrading dynamic dependencies than introduced. That's just your personal assertion, which is entirely baseless and unsubstantiated. It's ok to have beliefs, but instead of pushing them as truths you should at least start by doing some cursory research to see if they are even plausible. And yours isn't.
        klysm 3y ago
        He qualified it saying it was a hunch… I don’t see where he pushed it as a truth
        aidenn0 3y ago
        It's not entirely unsubstantiated, as my experience is that the former is very common. The latter is much harder to observe though, so it's just an impression. I'm very interested in your assertion that my impression is implausible though. What evidence do you have?
    - selfhoster11 3y ago
      Only cheap if you're running on huge servers. End user machines and edge compute are more constrained, so one needs to be more polite with resource use there.
    - kreetx 3y ago
      It seems to me that deploying a static binary is for situations where one doesn't have control over the underlying system, or where shipping dependencies hasn't been solved, i.e, you just want to ship one binary.
      - klysm 3y ago
        Shipping one binary is much easier and I don’t even want to solve the problem of shipping deps as separate artifacts
- o11c 3y ago
  This is a really silly entrypoint into the static/dynamic argument. Static linking does not protect anything here, only makes it harder for developers.
  - semi 3y ago
    They each have tradeoffs even only considering security. Consider a situation in which there is a new vulnerability in openssl. you can treat this as a hypothetical question or just.. remember any of your past experiences of any of the many openssl vulns. How many binaries on your server use the vulnerable version? If all binaries are dynamically linked you can answer this fairly trivially with a shell script to enumerate binaries, pass them to ldd, and a little grepping. If all of your binaries are statically linked what do you do? Ideally pull the build info from your build server that shows you every version of everything that went into the binary.. which is data that just doesn't exist for most people Maybe you scan the binaries to do some kind of signature analysis... but I would not be confident in the results not having false positives and false negatives. Now let's patch it. How quickly can you recompile every static binary on your server? Can you even easily cut new builds of these existing versions but with a small patch increment or will your dev teams just rush a new release of any changes they're working on? or with dynamically libraries, you update the library on your server and be done with it ... or so you thought. you didn't check what processed were running with the old library still open in memory and restart them so you're still vulnerable :)
- rewmie 3y ago
  > I think this is a great entrypoint into the static/dynamic argument and I'd love to argue with some people about it. I don't think it is. You start from an irrational and unsubstantiated belief that ignores any of the basic usecases of shared libraries. > I believe dynamic used to make sense but no longer does in the vast majority of cases. It's your personal belief, and one that's unsubstantiated and os based on ignorance. > Static binaries have their costs, but are so much easier to reason about. That assertion is completely irrelevant, as it fails to address any of the usecases for shared libraries. Being able to run code, and other dubious claims of simplicity, don't even qualify as questioning the purpose of shared libraries.
  - klysm 3y ago
    Static binaries are easier to reason about. You’ve provided no evidence to the contrary.
vhcr 3y ago
If you're shipping something you don't want fiddled with, don't ship it, because it's an impossible task.
- ghotli 3y ago
  Sure. We agree. Cat and mouse. Can you help me understand what value you're adding to the discussion though? Low hanging fruit arguments based on semantics might be best suited elsewhere
  - ed_mercer 3y ago
    He/she is mentioning that an obtained client can always be hacked, no matter what, and the reader of the original comment may not realize that.
    - sosodev 3y ago
      I think the vast majority of HN users would realize that. Is it important for the few that don’t? Perhaps
      - GreymanTheGrey 3y ago
        The original commenter clearly didn't understand it, since they asserted that "statically linked libraries prevent this attack vector". Which is unambiguously not the case, they merely slow it down by a small margin.
        LoganDark 3y ago
        LD_PRELOAD is the specific attack vector that is prevented by static linking. They made no claim that static linking prevents all forms of tampering.
        arp242 3y ago
        It's a true statement; LD_PRELOAD cannot be used with statically linked binaries. You can "fiddle" in other ways, but not by using the LD_PRELOAD attack vector (although personally I wouldn't call it an "attack vector", although in some cases it could be where you can upload a malicious file and control the environment of another program somehow, or something along those lines).
josephcsible 3y ago
This is not an attack vector and not something programs should try to protect against. If attackers have control to the point that they can run a program with LD_PRELOAD, they've already won.
- ghotli 3y ago
  Won on that node, agreed. I suppose I meant the 'investigate programs' part of the title and if that aids in garnering info for attacking something it interacts with. But of course it's all splitting hairs. A sufficiently dedicated / motivated / funded person can investigate even the most hardened static position independent binary. Dynamic linking with LD_PRELOAD is like propping the front door open in comparison.
- yonatan8070 3y ago
  There are cases where developers need to protect software from a local user with root access, like DRM related software, games that want to defend against pirates, etc.
  - ronsor 3y ago
    That's more of a want than a need.
  - josephcsible 3y ago
    Those use cases are inherently evil, and the rest of us should go out of our way to make them impossible, or at least as difficult as possible. A local user with root access should always have full control over everything, regardless of the wishes of any hardware manufacturers or software developers.
  - saagarjha 3y ago
    This would not help with that goal.
userbinator 3y ago
to prevent a CI server from surfacing a hostname in a place it shouldn't be I had to deal with the same problem a few years ago, and used the exact same solution.

by ghotli 3y ago

klysm 3y ago

I think this is a great entrypoint into the static/dynamic argument and I'd love to argue with some people about it. I believe dynamic used to make sense but no longer does in the vast majority of cases. Static binaries have their costs, but are so much easier to reason about.

kreetx 3y ago
If dynamic libraries are compatible to what they did (when you developed the program) then why waste disk and RAM?
- aidenn0 3y ago
  Because disk and RAM are cheap and that's a huge "If"
  - deleted 3y ago
    [deleted]
  - jonhohle 3y ago
    There’s also other security considerations. As an operator or builder, do you want to patch a library (say OpenSSL) to keep your system up to date or patch every binary. If changing a dependency requires rebuilding all consumers recursively, the there’s not a huge benefit.
    - aidenn0 3y ago
      I think in the specific case of security issues, more bugs have been fixed by upgrading dynamic dependencies than introduced. That's just my gut feeling though, and I'd like to see data.
      - rewmie 3y ago
        > I think in the specific case of security issues, more bugs have been fixed by upgrading dynamic dependencies than introduced. That's just your personal assertion, which is entirely baseless and unsubstantiated. It's ok to have beliefs, but instead of pushing them as truths you should at least start by doing some cursory research to see if they are even plausible. And yours isn't.
        klysm 3y ago
        He qualified it saying it was a hunch… I don’t see where he pushed it as a truth
        aidenn0 3y ago
        It's not entirely unsubstantiated, as my experience is that the former is very common. The latter is much harder to observe though, so it's just an impression. I'm very interested in your assertion that my impression is implausible though. What evidence do you have?
  - selfhoster11 3y ago
    Only cheap if you're running on huge servers. End user machines and edge compute are more constrained, so one needs to be more polite with resource use there.
  - kreetx 3y ago
    It seems to me that deploying a static binary is for situations where one doesn't have control over the underlying system, or where shipping dependencies hasn't been solved, i.e, you just want to ship one binary.
    - klysm 3y ago
      Shipping one binary is much easier and I don’t even want to solve the problem of shipping deps as separate artifacts
o11c 3y ago
This is a really silly entrypoint into the static/dynamic argument. Static linking does not protect anything here, only makes it harder for developers.
- semi 3y ago
  They each have tradeoffs even only considering security. Consider a situation in which there is a new vulnerability in openssl. you can treat this as a hypothetical question or just.. remember any of your past experiences of any of the many openssl vulns. How many binaries on your server use the vulnerable version? If all binaries are dynamically linked you can answer this fairly trivially with a shell script to enumerate binaries, pass them to ldd, and a little grepping. If all of your binaries are statically linked what do you do? Ideally pull the build info from your build server that shows you every version of everything that went into the binary.. which is data that just doesn't exist for most people Maybe you scan the binaries to do some kind of signature analysis... but I would not be confident in the results not having false positives and false negatives. Now let's patch it. How quickly can you recompile every static binary on your server? Can you even easily cut new builds of these existing versions but with a small patch increment or will your dev teams just rush a new release of any changes they're working on? or with dynamically libraries, you update the library on your server and be done with it ... or so you thought. you didn't check what processed were running with the old library still open in memory and restart them so you're still vulnerable :)
rewmie 3y ago
> I think this is a great entrypoint into the static/dynamic argument and I'd love to argue with some people about it. I don't think it is. You start from an irrational and unsubstantiated belief that ignores any of the basic usecases of shared libraries. > I believe dynamic used to make sense but no longer does in the vast majority of cases. It's your personal belief, and one that's unsubstantiated and os based on ignorance. > Static binaries have their costs, but are so much easier to reason about. That assertion is completely irrelevant, as it fails to address any of the usecases for shared libraries. Being able to run code, and other dubious claims of simplicity, don't even qualify as questioning the purpose of shared libraries.
- klysm 3y ago
  Static binaries are easier to reason about. You’ve provided no evidence to the contrary.

vhcr 3y ago

If you're shipping something you don't want fiddled with, don't ship it, because it's an impossible task.

ghotli 3y ago
Sure. We agree. Cat and mouse. Can you help me understand what value you're adding to the discussion though? Low hanging fruit arguments based on semantics might be best suited elsewhere
- ed_mercer 3y ago
  He/she is mentioning that an obtained client can always be hacked, no matter what, and the reader of the original comment may not realize that.
  - sosodev 3y ago
    I think the vast majority of HN users would realize that. Is it important for the few that don’t? Perhaps
    - GreymanTheGrey 3y ago
      The original commenter clearly didn't understand it, since they asserted that "statically linked libraries prevent this attack vector". Which is unambiguously not the case, they merely slow it down by a small margin.
      - LoganDark 3y ago
        LD_PRELOAD is the specific attack vector that is prevented by static linking. They made no claim that static linking prevents all forms of tampering.
      - arp242 3y ago
        It's a true statement; LD_PRELOAD cannot be used with statically linked binaries. You can "fiddle" in other ways, but not by using the LD_PRELOAD attack vector (although personally I wouldn't call it an "attack vector", although in some cases it could be where you can upload a malicious file and control the environment of another program somehow, or something along those lines).

josephcsible 3y ago

This is not an attack vector and not something programs should try to protect against. If attackers have control to the point that they can run a program with LD_PRELOAD, they've already won.

ghotli 3y ago
Won on that node, agreed. I suppose I meant the 'investigate programs' part of the title and if that aids in garnering info for attacking something it interacts with. But of course it's all splitting hairs. A sufficiently dedicated / motivated / funded person can investigate even the most hardened static position independent binary. Dynamic linking with LD_PRELOAD is like propping the front door open in comparison.
yonatan8070 3y ago
There are cases where developers need to protect software from a local user with root access, like DRM related software, games that want to defend against pirates, etc.
- ronsor 3y ago
  That's more of a want than a need.
- josephcsible 3y ago
  Those use cases are inherently evil, and the rest of us should go out of our way to make them impossible, or at least as difficult as possible. A local user with root access should always have full control over everything, regardless of the wishes of any hardware manufacturers or software developers.
- saagarjha 3y ago
  This would not help with that goal.

userbinator 3y ago

to prevent a CI server from surfacing a hostname in a place it shouldn't be I had to deal with the same problem a few years ago, and used the exact same solution.