When linking to OpenSSL (or other cryptographic libraries) would it be more secure to use a shared library and have address space layout randomization, or to use a static library and not have ASLR?

  • 5
    You will also want to take into account that OpenSSL releases security fixes noticeably regularly. Static linking will need to be repeated, dynamic linking will benefit from simpler OS patch + process restart. – gowenfawr Jul 22 '15 at 15:09

ASLR and such things are ways to try to cope with consequences of a buffer overflow -- they are an hide&seek game so that attackers find it harder to turn a buffer overflow into remote code execution. For proper security, it is better to make it so that buffer overflows don't occur in the first place.

... and for that, dynamic linking is better. The reason is the following: it would be inordinately optimistic to believe that any given piece of code written in C does not have any buffer overflow (especially OpenSSL, which has a rather long history on that subject). Thus, the best that you can do is to be able to promptly fix known security holes by replacing the faulty part. If you use dynamic linking, this is easy: just replace the DLL, and be done with it. If the DLL is provided by the OS (the normal case in Linux systems) then this will be done naturally when you apply security updates from the OS vendor. However, if you use static linking, then the patches won't make it into your application until you recompile (or at least relink) that specific application with the patched OpenSSL.

In practice, static linking means that security fixes on the library will take longer to be applied to the application -- or, more often than not, won't be applied at all. This is bad. Therefore, use dynamic linking.

  • "it would be inordinately optimistic to believe that any given piece of code written in C does not have any buffer overflow" Not if the person writing it is competent and knows how to test things. But in the general case, yes. I suppose that's right. Competence is one thing I've had to learn never to assume... – Parthian Shot Jul 24 '15 at 7:00
  • 1
    There is reputedly only one software without bugs (Metafont, written by Donald Knuth). It is possible to write safe C code by being careful; but, apparently, it is not humanly possible to be sufficiently careful throughout the whole development of any significant piece of software. However, competent programmers can be good at leaving few bugs, and fixing them promptly when detected. Which is enough in practice, as long as the patch installation process is sleek and slight (hence dynamic linking). – Tom Leek Jul 24 '15 at 13:41
  • Why more research money hasn't been put into cloning Donald Knuth I will never understand. – Parthian Shot Jul 24 '15 at 15:07
  • Linux uses shared objects (.so files), not DLLs. – forest Dec 16 '17 at 2:52
  • @TomLeek There are a few examples of software "without bugs". Primarily formally verified (mathematically proven correct) software like miTLS, HTTP.sys, or seL4. The specific classes of bugs which they are proven to be free of differs, for example seL4 does not guarantee freedom from side-channel attacks, though I believe that is being worked on. And of course, changing even a single line of code in a formally verified project can violate the entire proof (which is why HTTP.sys was hit with an RCE involving its then-recently-added non-verified caching layer). – forest Dec 16 '17 at 3:39

I'm late to the party, but I just wanted to throw in some opinions in case anyone else passes by. The accepted answer is accurate in that static linking makes it more difficult to do an in-place upgrade. For example, if you're using OpenSSL with your app, you could just deploy the new libcrypto.dll (assuming it's backward compatible with your app) over the old DLL, and you'll be good.

However, in regard to exploits and other nasty stuff, I would argue static linking is a little more secure. Basically, there's no DLL external to your application that can be swapped with a tainted version of the same DLL or even a shim (DLL proxy and the like...)

Additionally, and this isn't really an argument against either, but if your external library has an exploit neither static or dynamic is going to be safer as it's exploited at run-time when it's already linked in to your application.

I agree with their advice on making it easier to match current OpenSSL versions and for the most part would suggest dynamic linking, but you know your application best, and since the original question asked which is safer (while deployed on a box, I assume), you should also think about tampering.

  • 1
    It's easy to prevent a tainted version of a library from being linked. On Linux at least, the paths where applications search for libraries can only be written to by root. The only way to override that requires setting an environmental variable, and if an attacker controls your environment, you've already lost. Tampering is absolutely not a valid reason to use static linking, and it is useless as an integrity measure. Giving up efficient upgrades and ASLR for snake-oil is a terrible idea. – forest Dec 16 '17 at 2:55
  • 1
    If an application is in an unprivileged directory, then even if it's static, it can be tampered with. Security through obscurity is not security. – forest Dec 17 '17 at 0:53
  • 1
    As for your link, that requires changing either the environment, or an unprivileged path, in which case there are plenty of (easier) ways to compromise an application even if it is statically linked. Can you give me any situation in which someone who is not clever enough to use a freeware packer will be able to exploit a dynamically linked executable but not a statically linked one? Also not to nitpick but I think libcrypt is a libc thing, libcrypto is OpenSSL (even in Windows). – forest Dec 18 '17 at 4:44
  • 1
    You are still relying on security through obscurity, which has no place on Sec.SE. You are giving up several important security benefits (which have deterministic properties) for obscurity which is so easy to bypass that even a script kiddie who doesn't know how to use metasploit or don't care to read the documentation can do it (as packers are far easier to use than metasploit - they can even come with their own flashy GUIs). I mean this is about as beneficial to security as marking your executables hidden or replacing the folder icon with the IE icon (except those don't reduce security). – forest Dec 18 '17 at 7:22
  • 1
    @forest: OpenSSL on Unix is canonically libssl and libcrypto .a/so/sl/dylib/etc often plus versions(s), but on Windows for very hysterical raisins it is ssleay32 and libeay32 .dll/lib (even on Win64!). Which doesn't matter to any vuln(s), of course. – dave_thompson_085 Mar 2 '18 at 4:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.