By Darren Moffat-Oracle on Nov 27, 2014
I'm pleased to announce that the Solaris 11 /support repository now
contains metadata for tracking security vulnerability fixes by the
assigned CVE number. This was a project that Pete Dennis and I have been
working on for some time now. While we worked together on the design
of the metadata and how it should be presented I'm completely indebted to
Pete for doing the automation of the package generation from the data in
our bug databases - we don't want humans to generate this by hand because it is error prone.
What does this mean for you the Solaris system admin or a compliance auditor ?
intent of this is to make it much easier to determine if your system
has all the known and required security vulnerability fixes. This
should stop you from attempting to derive this information based on
other sources. This is critically important since sometimes in Solaris
we choose to fix a bug in an upstream FOSS component by applying the
code patch rather than consuming a whole new version - this is a
risk/benefit trade off that we take on a case by case basis. While all
this data has been available for sometime in My Oracle Support documents
it wasn't easily available in a scriptable form - since it was intended
to be read by humans.
The implemenation of this is designed to be applied to any other Oracle, or 3rd party, products that are also delivered in IPS form.
For Solaris we have added a new metadata package called: pkg:/support/critical-patch-update/solaris-11-cpu. This new package lives above entire in the dependency hiearchy and contains only metadata that maps the CVE-IDs to the package version that contains the fix. This allows us to retrospectively update the critical-patch-update metadata where an already shipping version contains the fix for a given CVE.
Each time we publish a new critical patch update a new version of the package is published to the /support repository along with all the new versions of the packages that contain the fixes. The versioning for this package is @YYYY.MM.VV where VV is usually going to be '1' but this allows us to respin/republish a given critical patch update with in the same month, note the VV is not DD it is NOT the day in the month.
We can search this data using either the web interface on https://pkg.oracle.com/solaris/support or using the CLI. So lets look at some examples of the CLI searching. Say we want to find out which packages contain the fix for the bash(1) Shellshock vulnerability and we know that one of the CVE-IDs for that is CVE-2014-7187:
# pkg search :CVE-2014-7187:
INDEX ACTION VALUE PACKAGE
CVE-2014-7187 set pkg://email@example.com,5.11-0.175.2.2.0.8.0 pkg:/firstname.lastname@example.org
CVE-2014-7187 set pkg://email@example.com,5.11-0.175.2.3.0.4.0 pkg:/firstname.lastname@example.org
That output tells us which packages and versions contain a fix and which critical patch update it was provided in.
For another example lets find out the whole list of fixes in the October 2014 critical patch update:
pkg search -r info.cve:|grep 2014.10
info.cve set CVE-1999-0103 pkg:/email@example.com
info.cve set CVE-2002-2443 pkg:/firstname.lastname@example.org
info.cve set CVE-2003-0001 pkg:/email@example.com
that the placement of colon (:) is very signficant in IPS and that the
keyname is 'info.cve' and the values have CVE in upper case.
The way that metadata is setup allows for the cases where a given CVE-ID applies to multiple packages and also where a given package version contains fixes for multiple CVE-IDs.
If we simply want to know if the fix for a given CVE-ID is installed the using 'pkg search -l' with the CVE-ID is sufficent eg:
# pkg search -l CVE-2014-7187
INDEX ACTION VALUE PACKAGE
info.cve set CVE-2014-7187 pkg:/firstname.lastname@example.org
If it wasn't installed then we would have gotten no output.
If you want to have a system track only the Critical Patch Updates and not every SRU available in the /support repository then when you do an update instead of doing 'pkg update' or 'pkg update entire@<latest>' do 'pkg update solaris-11-cpu@latest'. Note that initially systems won't have the 'solaris-11-cpu' package installed since as I mentioned previously is is "above" the entire package. When you update to the latest version of the Critical Patch Update package it will install any intermediated SRUs that were released between this version and the prior one you had installed.
For some further examples have a look at MOS Doc ID 1948847. Currently only the Solaris 11.2 critical patch update metadata is present but we intend to very soon backpublish the data for prior Solaris 11 critical patch updates as well.
Hope this helps with your compliance auditing. If you are an auditor no
more arguments with the sys admin teams about whither a fix is
installed. If you are a system admin more time for your "real job"
since you can now easily give the auditor the data they need.
The compliance team is also working on updating the Solaris and PCI-DSS security benchmarks we deliver with the compliance(1M) framework to use this new CVE metadata in determining if the system is upto date, since from a compliance view point we really want to know that all known and available security fixes are installed not that you are running the absolutely latest and greatest version of Solaris.
I have also been working with the OVAL community (part of SCAP) to define a schema for the Solaris IPS system. This is due to be released with a future version of the OVAL standard. That will allow us to use this same framework of metadata to also deliver OVAL xml files that map the CVE-IDs to packages. When that is available we may choose to deliver OVAL xml files as part of the critical-patch-update package as an additional method of querying the same metadata.