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.
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.
Which is unambiguously not the case, they merely slow it down by a small margin.
When you are using shared libaries, it is fairly trivial to hook into the library calls and replace them with whatever you want. When you are using static libraries, the linker and optimizer could for example inline the machine code directly in the application code. What tools do you have to do similar tricks with statically compiled binaries?
That pointless remark misses the whole point. Even though ideally an attack vector would be eliminated, it's already good enough if it becomes unexploitable by the vast majority of potential attackers. That's why there is a whole field called "app hardening" as in a sliding scale instead of "perfect app protection".
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.
I'm very interested in your assertion that my impression is implausible though. What evidence do you have?
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 :)
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.
I had to deal with the same problem a few years ago, and used the exact same solution.