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.
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
# pkg search :CVE-2014-7187:
INDEX ACTION VALUE PACKAGE
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:/firstname.lastname@example.org
info.cve set CVE-2002-2443 pkg:/email@example.com
info.cve set CVE-2003-0001 pkg:/firstname.lastname@example.org
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.
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:/email@example.com
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.