OpenSSL Versions in Solaris

Those of you have have installed Solaris 11 or have read some of the blogs by my colleagues will have noticed Solaris 11 includes OpenSSL 1.0.0, this is a different version to what we have in Solaris 10.  I hope the following explains why that is and how it fits with the expectations on binary compatibility between Solaris releases.

Solaris 10 was the first release where we included OpenSSL libraries and headers (part of it was actually statically linked into the SSH client/server in Solaris 9).  At time we were building and releasing Solaris 10 the current train of OpenSSL was 0.9.7. 

The OpenSSL libraries at that time were known to not always be completely API and ABI (binary) compatible between releases (some times even in the lettered patch releases) though mostly if you stuck with the documented high level APIs you would be fine.   For this reason OpenSSL was classified as a 'Volatile' interface and in Solaris 10 Volatile interfaces were not part of the default library search path which is why the OpenSSL libraries live in /usr/sfw/lib on Solaris 10.  Okay, but what does Volatile mean ?

Quoting from the attributes(5) man page description of Volatile (which was called External in older taxonomy):

         Volatile interfaces can change at any time and  for  any

         The Volatile interface stability level allows  Sun  pro-
         ducts to quickly track a fluid, rapidly evolving specif-
         ication. In many cases, this is preferred  to  providing
         additional  stability to the interface, as it may better
         meet the expectations of the consumer.

         The most common application of this taxonomy level is to
         interfaces that are controlled by a body other than Sun,
         but unlike specifications controlled by standards bodies
         or Free or Open Source Software (FOSS) communities which
         value interface compatibility, it can  not  be  asserted
         that  an incompatible change to the interface specifica-
         tion would be exceedingly rare. It may also  be  applied
         to  FOSS  controlled  software  where  it is deemed more
         important to track the community  with  minimal  latency
         than to provide stability to our customers.

         It also common  to  apply  the  Volatile  classification
         level  to  interfaces in the process of being defined by
         trusted or  widely  accepted  organization.   These  are
         generically  referred  to  as draft standards.  An "IETF
         Internet draft"  is  a  well  understood  example  of  a
         specification under development.

         Volatile can also be applied to experimental interfaces.

         No assertion is made regarding either source  or  binary
         compatibility  of  Volatile  interfaces  between any two
         releases,  including  patches.  Applications  containing
         these  interfaces might fail to function properly in any
         future release.

Note that last paragraph!  OpenSSL is only one example of the many interfaces in Solaris that are classified as Volatile.  At the other end of the scale we have Committed (Stable in Solaris 10 terminology) interfaces, these include things like the POSIX APIs or Solaris specific APIs that we have no intention of changing in an incompatible way.  There are also Private interfaces and things we declare as Not-an-Interface (eg command output not intended for scripting against only to be read by humans).

Even if we had declared OpenSSL as a Committed/Stable interface in Solaris 10 there are allowed exceptions, again quoting from attributes(5):

         4.   An interface specification which  isn't  controlled
              by  Sun  has been changed incompatibly and the vast
              majority of interface consumers  expect  the  newer

         5.   Not  making  the  incompatible  change   would   be
              incomprehensible  to our customers. 

In our opinion and that of our large and small customers keeping up with the OpenSSL community is important, and certainly both of the above cases apply.

Our policy for dealing with OpenSSL on Solaris 10 was to stay at 0.9.7 and add fixes for security vulnerabilities (the version string includes the CVE numbers of fixed vulnerabilities relevant to that release train).  The last release of OpenSSL 0.9.7 delivered by the upstream community was more than 4 years ago in Feb 2007.

Now lets roll forward to just before the release of Solaris 11 Express in 2010. By that point in time the current OpenSSL release was 0.9.8 with the 1.0.0 release known to be coming soon.  Two significant changes to OpenSSL were made between Solaris 10 and Solaris 11 Express.  First in Solaris 11 Express (and Solaris 11) we removed the requirement that Volatile libraries be placed in /usr/sfw/lib, that means OpenSSL is now in /usr/lib, secondly we upgraded it to the then current version stream of OpenSSL (0.9.8) as was expected by our customers.

In between Solaris 11 Express in 2010 and the release of Solaris 11 in 2011 the OpenSSL community released version 1.0.0.  This was a huge milestone for a long standing and highly respected open source project.  It would have been highly negligent of Solaris not to include OpenSSL 1.0.0e in the Solaris 11 release. It is the latest best supported and best performing version.  


In fact Solaris 11 isn't 'just' OpenSSL 1.0.0 but we have added our SPARC T4 engine and the AES-NI engine to support the on chip crypto acceleration. This gives us 4.3x better AES performance than OpenSSL 0.9.8 running on AIX on an IBM POWER7. We are now working with the OpenSSL community to determine how best to integrate the SPARC T4 changes into the mainline OpenSSL.  The OpenSSL 'pkcs11' engine we delivered in Solaris 10 to support the CA-6000 card and the SPARC T1/T2/T3 hardware is still included in Solaris 11.

When OpenSSL 1.0.1 and 1.1.0 come out we will asses what is best for Solaris customers. It might be upgrade or it might be parallel delivery of more than one version stream.  At this time Solaris 11 still classifies OpenSSL as a Volatile interface, it is our hope that we will be able at some point in a future release to give it a higher interface stability level.

Happy crypting! and thank-you OpenSSL community for all the work you have done that helps Solaris.


Is there an expectation that Solaris 10 will receive an updated version of OpenSSL?

Posted by guest on November 17, 2011 at 11:25 AM GMT #

We have no plans to change the version of OpenSSL in Solaris 10, we will continue to patch it to address security vulnerabilities only.

Posted by Darren Moffat on November 18, 2011 at 06:07 AM GMT #

I'v found this explanation highly significant.
Thank you.

Posted by Carlos Azevedo on January 14, 2012 at 07:17 AM GMT #

Would you do a writeup like this on kerberos.

It seems like kerberos has been stuck on an old version for a very long time, but I just heard that it was synched up with 1.8 for Solaris 10 and CVEs 2012-1012, 1014, and 1015 do not apply. Yet Retina keeps hitting on these CVEs because it does a version check using krb5-config -version. eEYE won't fix their code until there is some kind of public post that states Solaris is not affected by these CVEs. Can you help?

Posted by guest on September 26, 2012 at 08:00 PM BST #


My existing Sun M5000 server as openssl version 0.9.7d and as per the requirement,I try to upgrade to 0.9.8 but it fails
I try to install the package i.e.
1. openssl-0.9.8-sol10-sparc-local
2. openssl-0.9.8

But I can't able to upgrade it

root@03 # isainfo -v
64-bit sparcv9 applications
ima fmaf vis2 vis popc
32-bit sparc applications
ima fmaf vis2 vis popc v8plus div32 mul32
root@03 # uname -a
SunOS 03-S10 5.10 Generic_142900-11 sun4u sparc SUNW,SPARC-Enterprise
root@03 # more /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009
root@03 # /usr/sfw/bin/openssl version
OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2009-0590)
root@03 #

Posted by guest on March 03, 2014 at 05:49 PM GMT #

Dear guest of March 3rd 2014,

There is no OpenSSL 0.9.8 package for Oracle Solaris 10, instead Oracle will patch the OpenSSL 0.9.7 release branch in Solaris 10 with appropriate fixes for security vulnerabilities.

Attemping to replace the supplied 0.9.7 WILL break the OS.

I strongly recommend you upgrade the OS to Solaris 11.1 which includes OpenSSL 1.0.1.

Posted by Darren J Moffat on March 18, 2014 at 06:24 PM GMT #

# uname -a
SunOS skcaeh01 5.10 Generic_150400-04 sun4v sparc sun4v
# cat /etc/release
Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
Assembled 23 August 2011

# /usr/sfw/bin/openssl version
OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 CVE-2012-2131 CVE-2012-2333 CVE-2013-0166 CVE-2013-0169)

I have been asked by our IT security to update the openSSL version on this server due to Heartbleed Vulnerability detected.

Could you please advise whether we can upgrade the version or not?
They suggest to upgrade the OpenSSL to Version 1.0.1g, is this possible?

Posted by hasnan on April 16, 2014 at 07:02 AM BST #

For details on Oracle products that include OpenSSL an which versions may need patches see:

Where it explicitly states:

OpenSSL 0.9.7 branch is NOT vulnerable to CVE-2014-0160

so there is no need to update Solaris 10 systems.

Posted by Darren J Moffat on April 16, 2014 at 01:15 PM BST #

Hello Darren,

Our IT security informed that the Heartbleed Vulnerability detected is for CVE-2013-069.

Below are the instructions i received from the IT Security Engineer:

"I would advise that you update openssl on this system despite the versioning listed. The CVEs for which patches are indicated in the version information may include TLS libraries that are vulnerable. "

"It is CVE-2013-069.
I saw this on another system where the version was not a vulnerable version but there was a library patched to a vulnerable version."

Can you advise what should we do about this? Not sure what issue are they referring about the "library patched to a vulnerable version".

Posted by guest on April 17, 2014 at 02:20 AM BST #

I refer you to the answer I gave on April 16, 2014 at 01:15 PM BST. No shipping version of Solaris has a version of OpenSSL from Oracle that includes the code necessary to be vulnerable to CVE-2013-069.

If a scanner claims your Solaris systems are vulnerable either the scanner is broken or there is a version of OpenSSL on the system that was built locally or from some other 3rd party. On a Solaris 11 system run 'pkg verify openssl' to ensure that the OpenSSL binaries delivered by Oracle haven't been replaced. If that fails then run 'pkg fix openssl'. If it passes then your system may have 3rd party application delivering its own OpenSSL.

Posted by Darren J Moffat on April 17, 2014 at 11:10 AM BST #

Post a Comment:
  • HTML Syntax: NOT allowed

Darren Moffat-Oracle


« July 2016