Hacker News Reader

Comment by pilif | Hacker News Reader

As a programmer who unfortunately is suckered into doing devops at times, the more I get to just update the openssl library instead of the whole OS whenever a security flaw in openssl is announced, the more I'm convinced that dynamic linking was very well worth the trouble.

Funny how perceptions change depending on the angle you're looking at a problem.

View on HN

Oddly enough I was thinking about openssl updates specifically. Did you remember to restart all your long-running clients? (I'm a sysadmin who occasionally gets roped into doing development...)

Dynamic linking makes security more difficult to reason about, which is a Bad Thing. It has many pluses, but also many minuses. And with symbol versioning it gets very problematic to actually figure out what your real code path is to begin with.

And when you update all your clients with static linked OpenSSL, did you also remember to restart every single one of them? These seem like equivalent problems to me.

Not quite, I think. With a .so, I can ask `lsof` which services on the machine require restart: the ones that haven't are linked to a deleted so.

And you wouldn't need to restart the clients with static OpenSSL — you need to recompile them. And with static linking, I'm not sure how you would easily determine the linked version out to say, the minor or the micro. (Perhaps, if this is your OS's thing like nix, the package manager keeps track…)

Tip for Debian/Ubuntu users: checkrestart from the debian-goodies package is a nice wrapper around lsof that lists running binaries that rely on outdated solibs:

http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestar...

https://gehrcke.de/2014/06/good-to-know-checkrestart-from-de...

It not only shows processes that run older solibs, but in the case of services, it will also give you the commands to restart them :).

It also shows programs that are still using the old binary that has been deleted (unlinked from the filesystem) but not refcount 0 freed. This can also be used to uncover some forms of hiding that hack attempts use.

Not quite, but you've identified a key leverage point.

You only need to relink the apps, unless the newly patched library breaks its own ABI. Otherwise, it would be ideal for package distributors and package management systems to ship just a single .o file for an app, and do the final linking at package install time. Then updating a buggy static library doesn't require full recompile of any apps.

I don't think that nix would be able to tell you which version of OpenSSL some binary linked statically, as there would no longer be a reference from that binary to /nix/store/xxx-openssl-1.0/lib/libssl.so.

Nix generally uses dynamic linking, though the links are to absolute paths to a specific library version, so upgrading OpenSSL requires a recompile much like with static linking.

With "normal" dynamic linking, upgrading OpenSSL and restarting some service means you're now running untested code, hoping that the new version of the dynamic lib really doesn't change an interface on which your code depends. But to be fair, this is usually a good assumption.

Should be relatively easy to make a tool that uses `losf` or similar to get a list of all running processes that depend on a shared library.

I personally would like to see a distribution have a mixed policy -- dynamic linking against core libraries that are part of the default / basic OS install, and static linking against low usage libraries. That way, you keep the "update one library package to fix a bunch of programs", yet you also reduce cross dependency issues by limiting the number of library packages a given program is dependant on.

IIRC Snowflake[0] does that (but also has a very experimental per-process view of /usr -- pretty cool stuff, really, but takes some getting used to).

[0]: https://github.com/GregorR/snowflake

You are right. Lack of it will be the next wave of security problems

There are no problems with updates anymore. You don't have to download everything to update a bunch of static binaries. There are things, like bsdiff, that allow you to download and patch only tiny differences related to a security flaw.

There is no need for dynamic linking for updates. Really.

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that?

Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are you doing it without dynamic loading?

Chances are, if you're using those binaries, they have their own versions of whatever libraries they depend on already baked into themselves somehow. So even if they depend on OpenSSL, and you update OpenSSL on your system, they're probably still going to end up using a version from a year ago regardless of what you do.

> What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that?

The proprietary code isn't going to chance using system libs beyond libc, because of portability. So they likely still need to be patched separately.

> What if you have binaries compiled from proprietary code bases…

Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.

So you're admitting that this isn't a solution and you need to change the rules of the game to make it work.

Well, I'm convinced.

'Doctor, it hurts when I stab myself in the eye!'

'Well, don't stab yourself in the eye.'

ESR advocating for something is reason enough to seriously consider the alternative.

I don't see a problem with proprietary code bases.

Reply on news.ycombinator.com