Wednesday, March 02, 2016

Moving goalposts with openssl

The most recent openssl release fixed a number of security issues.

In order to mitigate against DROWN, SSLv2 was disabled by default. OK, that's a reasonable thing to do. The mere presence of the code is harmful, and improving security is a good thing. Right?

Well, maybe. Unfortunately, this breaks binary compatibility by default. Suddenly, a number of functions that used to be present in libssl.so have disappeared. In particular:

SSLv2_client_method
SSLv2_method
SSLv2_server_method

and the problem is that if you have an application that references those symbols, the linker can't find them, and your application won't even run.

This hit pkg(5) on OmniOS, which is pretty nasty.

So I had a look around on Tribblix to see what would break. It's largely what you would expect:

  • curl, specifically libcurl
  • wget
  • neon
  • the python ssl module
  • the ruby ssl module
  • apache
  • mysql
 And, of course, by the magic of dependency hell that spreads to affect a large number of applications.

In many cases the SSLv2 code is only present if it detects the corresponding calls being present in libssl. Which leads you into a chicken and egg situation - you have to install the newer openssl, thus breaking your system, in order to rebuild the applications that are broken.

And even if a distributor rebuilds what the distro ships, there's still any 3rd-party or locally built binaries which could be broken.

For Tribblix, I'm rebuilding what I can in any case, explicitly disabling SSLv2 (because the automatic detection is wrong). I'll temporarily ship openssl with SSLv2 enabled, until I've finally nailed everything.

But this is a game changer in terms of expectations. The argument before was that you should link dynamically in order to take advantage of updates to critical libraries rather than have to rebuild everything individually. Now, you have to assume that any security fix to a library you use could break compatibility.

For critical applications, another reason to build your own stack.

2 comments:

Josef "Jeff" Sipek said...

To me it sounds like openssl is just not doing the right thing when they disable SSLv2. There are at least two ways to disable some functionality in a library:

(1) remove the functions via #ifdefs
(2) stub out the functions so that they exist but return an error

For something like this, I really think that openssl should have used the second approach.

Just my two cents...

Peter Tribble said...

Indeed, I think I would have preferred the second approach of providing stubs as the default. They're gone completely in 1.1, but that's absolutely fine because it's a different version and you're allowed breaking changes there.

More worrying is the behaviour of consumers that default to automatically enabling SSLv2 if openssl supports it. It would have made a lot of sense for consumers to have been disabling SSLv2 by default for years, which makes killing it off much easier.