[Cryptography] Are dynamic libs compatible with security? was: Apple and OpenSSL
bear at sonic.net
Sat Apr 19 19:50:21 EDT 2014
I have to say the OpenSSL guys really and truly had a point when they
pointed out that dynamic linking is not fully or easily compatible
with the goal of security libraries.
Inconvenient as it was for Apple (and inconvenient as it is for others)
we really shouldn't be relying on dynamic linking to load security
modules. Remember, in security we're in the business of guaranteeing
that things we haven't quite planned for do *NOT* happen. Dynamic
linking is a great way to get things to happen even though you haven't
quite planned for them. In fact that's its main selling point; dynamic
linking means you automatically link to versions of the libraries other
than the ones you had available when you shipped, even if they contain
code you don't quite know about and haven't quite planned for. We
assume this new code is better in the usual case; but in trying to
secure systems against attacks, we should be regarding that new code
as an attack vector and assuming that it is written by Shaitan.
The other mindset, where we're busily trying to get good things
we haven't quite planned for to happen, values the hell out of
dynamically linking to new bug fixes. But in security we have to look
at it from the POV of professionals in the art of being certain that
bad things (like dynamically linking to new bugs!) do NOT happen,
and I simply do not see that as being compatible with dynamically
linking to, and therefore trusting, newly updated code sight unseen.
The other thing about dynamic linking is that from the POV of the
people who are updating the code that you're linking to, YOUR software
is at least possibly an unknown quantity. They probably haven't tested
with it unless yours is one of the four or five best-known applications
that uses their stuff. Even if the update isn't part of an attack and
isn't written by Shaitan, it's a bit much to trust that your usage
pattern which worked with the previous release absolutely is guaranteed
not to expose a flaw in the current release. Hard linking guarantees
that *somebody* tests the library together with the product before the
new behavior created by their combination is unleashed on the public.
Is this something that Apple can explain to its users? I don't know.
Apple has a history of cultivating a user culture that puts a negative
value on complex technical explanations, and makes a point of not
requiring them to sit through those, so it really was sort of between
a rock and a hard place there. To some extent though, everybody with
a modern user community that expects everything to work the same way
faces the same problem.
More information about the cryptography