It was over five years ago that I ranted about the bundling of libraries and what that means for vulnerabilities found in those libraries. The world has, since, not really listened. RubyGems still keep insisting that “vendoring” gems is good, Go explicitly didn’t implement a concept of shared libraries, and let’s not even talk about Docker or OSv and their absolutism in static linking and bundling of the whole operating system, essentially.
It should have been obvious how this can be a problem when Heartbleed came out, bundled copies of OpenSSL would have needed separate updates from the system libraries. I guess lots of enterprise users of such software were saved only by the fact that most of the bundlers ended up using older versions of OpenSSL where heartbeat was not implemented at all.
Now that we’re talking about replacing the OpenSSL libraries with those coming from a different project, we’re going to be hit by both edges of the proprietary software sword: bundling and ABI compatibility, which will make things really interesting for everybody.
If you’ve seen my (short, incomplete) list of RAND_egd() users which I posted yesterday. While the tinderbox from which I took this is out of date and needs cleaning, it is a good starting point to figure out the trends, and as somebody already picked up, the bundling is actually strong.
Software that bundled Curl, or even Python, but then relied on the system copy of OpenSSL, will now be looking for RAND_egd() and thus fail. You could be unbundling these libraries, and then use a proper, patched copy of Curl from the system, where the usage of RAND_egd() has been removed, but then again, this is what I’ve been advocating forever or so. With caveats, in the case of Curl.
But now if the use of RAND_egd() is actually coming from the proprietary bits themselves, you’re stuck and you can’t use the new library: you either need to keep around an old copy of OpenSSL (which may be buggy and expose even more vulnerability) or you need a shim library that only provides ABI compatibility against the new LibreSSL-provided library — I’m still not sure why this particular trick is not employed more often, when the changes to a library are only at the interface level but still implements the same functionality.
Now the good news is that from the list that I produced, at least the egd functions never seemed to be popular among proprietary developers. This is expected as egd was vastly a way to implement the /dev/random semantics for non-Linux systems, while the proprietary software that we deal with, at least in the Linux world, can just accept the existence of the devices themselves. So the only problems have to do with unbundling (or replacing) Curl and possibly the Python SSL module. Doing so is not obvious though, as I see from the list that there are at least two copies of libcurl.so.3 which is the older ABI for Curl — although admittedly one is from the scratchbox SDKs which could just as easily be replaced with something less hacky.
Anyway, my current task is to clean up the tinderbox so that it’s in a working state, after which I plan to do a full build of all the reverse dependencies on OpenSSL, it’s very possible that there are more entries that should be in the list, since it was built with USE=gnutls globally to test for GnuTLS 3.0 when it came out.
Have you ever used npm? It’s epic.
You’re assuming that you can drop in a LibreSSL shared library, and use it with a proprietary application that was previously compiled and linked to use OpenSSL without recompiling it.We are striving to keep API compatibility but *NOT* ABI compatibility. While you may get something to link and run this way, as the size of structures have changed you are probably going to cause yourself security problems. You should not do this.If you want to use an application with LibreSSL, it needs to be recompiled and relinked with LibreSSL. If your application was compiled and linked with OpenSSL, it should continue to use the (same version) of OpenSSL, until yourecompile it. Doing anything else is dangerous, and if you do so, and get burned, please don’t say you weren’t warned 😉
I’m not, please re-read my post. I actually said it explicitly that ABI not being maintained means that you cannot just drop-in replace LibreSSL. And you definitely don’t know me at all, if you think I don’t have a clear distinction about API and ABI, given that I could literally write the book on the topic.But **nothing** I’m saying in this post is talking about the use of LibreSSL directly by proprietary software. This is about what effect it *has* on the proprietary software: since we let them bundle Curl, their copy of Curl will still use OpenSSL even if the system Curl would not. Technically, if they are not importing `libssl` themselves, they should just take `libcurl` as granted, and we could be using LibreSSL for it; but this is **not** the case because we have too much bundling.As I say in the post, for proprietary software you either need a shim that provides a near-100% compatible ABI (assuming the structures you’re changing are opaque to the software, which needs to be proven!), or an old copy of OpenSSL to keep around. Which is probably going to be much more expensive given how quickly you wanted to veer away from its code.
Aha! I see you are proposing a shim library to attempt ABI compat, well, if someone wants to make it I suppose, but at this point you may as well keep your old OpenSSL libs around. (just as you keep old LibC’s around for things linked with them..).My apologies for the confusion – I have had several people already who I have warned away from trying to “drop in” LibreSSL shared libs overtop of OpenSSL ones..