OpenSSL version is not dependable

[Michael Truog]

Greetings!

Is there any reason why Ubuntu 14.04 LTS openssl version is still 1.0.1f?

From https://www.openssl.org/news/openssl-1.0.1-notes.html there have been a lot of patches since that version. In fact this critical patch https://www.openssl.org/news/vulnerabilities.html#2016-6304 is only available in latest version OpenSSL 1.0.1u [22 Sep 2016].

I run the below:
sudo apt-get update
sudo apt-get install openssl libssl-dev
openssl version -a

And I got:
$ openssl version -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Fri Sep 23 12:19:57 UTC 2016
platform: debian-amd64
options: bn(64,64) rc4(8x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Does this mean that 4 hours and 10 minutes ago 1.0.1f was rebuilt?

Best,
- Nestor

[Michael Truog (mjtruog-gmail)]

This problem needs to be handled as a bug due to its effect on OpenSSL use. Handling single patches with the Ubuntu OpenSSL package creates this problem, due to the lack of a version update. Instead, Ubuntu should be using mainline OpenSSL to avoid problems like https://en.wikipedia.org/wiki/OpenSSL#Predictable_private_keys_.28Debian-specific.29 . If there are any problems with using mainline OpenSSL, they could always be added there, but it would be strange that there should be any at this point in time, which should make it hard to justify the current Ubuntu practice of only using individual patches.

Switching to using the mainline OpenSSL source code would help to avoid liability that would otherwise fall on Ubuntu, for failure with individual OpenSSL source code changes. My main concern is having a dependable OpenSSL version to check based on the public OpenSSL vulnerabilities that are published. The situation we have now makes the Ubuntu OpenSSL version useless, which prevents any reliable checking and automatically makes the Ubuntu OpenSSL look insecure, or at least untrustworthy, due to the custom effort required to merge patches. With a change to use mainline OpenSSL, usage of OpenSSL can check the version returned to evaluate if usage is secure. This is important due to programming language usage of OpenSSL and the potential for impact on runtime use.

[Seth Arnold (seth-arnold)]

Thanks for your feedback Michael,

We're not going to be updating to mainline OpenSSL in Ubuntu on their release schedule. Every minor point release from OpenSSL invariably includes either ABI changes that would require recompiling all software that links against OpenSSL or other regressions that break existing users.

Over the years we have had far more reliable results backporting specific security fixes as they are prepared.

Many other vendors feel the same:

https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions
https://www.debian.org/security/faq#version
https://wiki.centos.org/FAQ/General#head-3dad8cb98ac535185e58e882a23ca4b096cbff2f
https://access.redhat.com/security/updates/backporting

Thanks

[Seth Arnold (seth-arnold)]

Oy, I forgot the most important part: we fixed CVE-2016-6304 via https://www.ubuntu.com/usn/usn-3087-1/

Thanks

[Michael Truog (mjtruog-gmail)]

With OpenSSL 1.0.1, as long as you update to the most recent 1.0.1 release, there would be no ABI changes, right? Otherwise, your argument is just that other people do separate patches, so Ubuntu will continue to do that too, right?

[Seth Arnold (seth-arnold)]

> there would be no ABI changes, right?

That'd would be ideal, yes. :) But it's sadly not the case.

Every six months when we prepare a new release, we incorporate newer OpenSSL packages, and it's astonishing how often things are broken, either ABI breaks or regressions introduced in newer versions. OpenSSL upstream's QA process is perhaps not as tuned to discovering this as our processes are. (This makes sense -- they maintain one package that uses OpenSSL. We maintain hundreds that use OpenSSL.)

We see enough breaks that we're in no hurry to ship OpenSSL's upstream releases on their schedule. We'll continue to backport security fixes as they are prepared and after they pass our QA process.

Thanks

[Michael Truog (mjtruog-gmail)]

Ok, thanks for explaining this!