[Cryptography] Are dynamic libs compatible with security? was: Apple and OpenSSL

Jerry Leichter leichter at lrw.com
Sat Apr 19 23:36:14 EDT 2014


On Apr 19, 2014, at 7:50 PM, Bear <bear at sonic.net> wrote:
> 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....
Actually, it depends on how you set up your dynamic linking.  The usual Unix convention - which Mac OS sticks with - is that libfoo.dylib is a softlink to the libfoo2.3.1.dylib (for example), where 2.3.1 is the most recent version of the foo library.  But the older libfoo.2.1 library is often still on the system.    Programs that want the "official latest supported version" link against libfoo; but instead they link directly to libfoo.2.1.dylib ... that's what you get.

To take a specific example from my Mavericks laptop:

1864 -rwxr-xr-x  1 root  wheel  2072560 Oct 31 02:43 /usr/lib/libcrypto.0.9.7.dylib
2272 -rwxr-xr-x  1 root  wheel  2590960 Oct 31 02:43 /usr/lib/libcrypto.0.9.8.dylib
   8 lrwxr-xr-x  1 root  wheel       21 Oct 31 02:44 /usr/lib/libcrypto.dylib -> libcrypto.0.9.8.dylib

> 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.  
The situation for MacOS is particularly interesting because MacOS provides an easy mechanism for an application to carry along inside of itself all the dynamically loaded material it needs.  What you see as an "application" Foo will correspond to a Foo.app file.  (The .app is hidden by default.)  You appear to run Foo[.app] by double-clicking on it - but it's not executable code.  In fact, it's a directory, a fact that is also hidden by default, though you can navigate into it if you like.  Hidden inside of that directory is space for all the dynamically linked libraries and other kinds of material - like translatable string constants - the actual program (which is in there under a specific path) will need.  When starting the program, MacOS will arrange for the embedded collection of libraries and other dynamic material to be searched *first*, before any system-provided libraries.

So for MacOS-style applications, the static vs. dynamic issue is as much or as little of an issue as you choose to make it.  Any libraries placed in the appropriate directories under the Foo.app directory are "morally statically linked":  The program will always choose them first, ahead of anything else on the system.  System libraries aren't normally carried along with applications, but nothing (as far as I know) says they can't be.

So all this concern is related to programs built and run the old-fashioned way, as simple executable files that dynamically load from the system library path.  Applications built as .app files can easily carry along as little or as much of their environment as appropriate.  For code that relies on OpenSSL, carrying along a private copy that you code was built against seems like a fine idea.  But you do have to package it all up in MacOS style - something your typical OSS projects, supporting multiple platforms, are unlikely to want to bother with.

                                                        -- Jerry
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140419/4fd5f88a/attachment.html>


More information about the cryptography mailing list