4 ms·

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

by yuriks 12y ago

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.

deathanatos 12y ago
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…)
- danieldk 12y ago
  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=checkrestart http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestar... https://gehrcke.de/2014/06/good-to-know-checkrestart-from-debian-goodies/ 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 :).
  - tankenmate 12y ago
    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.
- pmahoney 12y ago
  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.
- hyc_symas 12y ago
  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.

by yuriks 12y ago

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.

deathanatos 12y ago

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…)

danieldk 12y ago
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=checkrestart http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestar... https://gehrcke.de/2014/06/good-to-know-checkrestart-from-debian-goodies/ 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 :).
- tankenmate 12y ago
  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.
pmahoney 12y ago
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.
hyc_symas 12y ago
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.