Red Hat CPE definitions

[Mark J Cox-2]

Hi all; I thought I was subscribed to CPE discussion list, but it looks like
I'm not so have missed a lot of the discussion about 2.0.

My team started publishing mappings of our security advisories to CPE names,
although the names we're using are a bit of a cross between old and new CPE.
You can see them here (large file)

http://people.redhat.com/mjc/rhsamapcpe.txt

After a quick read of 2.0 draft I mailed Drew with some comments and he
suggested I mail the list instead:

Drew wrote:
> for a single OS, or a name for a single application.  The CPE Language
> would be used to create more complex names like OS + App

So my confusion is also in the distinction between app and OS; for us Red Hat
Enterprise Linux is a bundle of 2000+ different applications.  So we never
issue an update that fixes the OS, just applications that are part of the OS
(even the linux kernel itself is just one of the included applications).

In my current mapping I use CPE identifiers such as
  cpe://redhat:enterprise_linux:2.1:as/bind

Then we have the layered products, where "Red Hat Application Stack" is just a
set of applications that are additional or replacements for the ones shipped
with the base OS.  Is "Red Hat Application Stack" an application (probably not,
it's just a container for a number of apps)

Example from the mapping:
  cpe://redhat:rhel_application_stack:1/mod_perl

We also have the issue that the apps we ship are ones containing our own
backported patches, so unlike say RealPlayer where anyone shipping RealPlayer
is shipping the official Adobe binaries, our Apache httpd is not the official
:apache_software_foundation:httpd and to use that in a CPE referenced in our
advisory would be incorrect.

Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team

[Thomas R. Jones]

On Wed, 2007-08-01 at 14:05 +0100, Mark J Cox wrote:
Whew! I thought I was the only one. ;)
>
> In my current mapping I use CPE identifiers such as
>   cpe://redhat:enterprise_linux:2.1:as/bind
>
I have been developing the definitions for the distributions released by
Novell. But i have not delinieated the package to a specific
distribution. Simply due to the fact that a cpe identifier may be
equivalent for some other 5+ distributions within Novell. So what I
chose to do is the following:

        cpe:///novell:apparmor:2.0.1

I left the os specification off and focus on the application identifier.
This simply says that the application may be installed on any
distribution.

> Then we have the layered products, where "Red Hat Application Stack" is just a
> set of applications that are additional or replacements for the ones shipped
> with the base OS.  Is "Red Hat Application Stack" an application (probably not,
> it's just a container for a number of apps)
>
> Example from the mapping:
>   cpe://redhat:rhel_application_stack:1/mod_perl
>
hmmm.

> We also have the issue that the apps we ship are ones containing our own
> backported patches, so unlike say RealPlayer where anyone shipping RealPlayer
> is shipping the official Adobe binaries, our Apache httpd is not the official
> :apache_software_foundation:httpd and to use that in a CPE referenced in our
> advisory would be incorrect.
You can review conversation that I brought up in the mailinglist
archives with regards to this issue. I believe whole-heartedly that this
should be handled as though the originating organization is the
authoritative entity for each package:

e.g. cpe:///redhat:httpd

I know that Novell alters much of the code before packaging and
distributes the package with varying degrees of support. The way I see
it, this should be reason enough to use novell as the vendor identifier.
The same would work for redhat and the fedora_project.

Comments?
Thomas
>
> Thanks, Mark
> --
> Mark J Cox / Red Hat Security Response Team
>
>

[Andrew Buttner]

>> In my current mapping I use CPE identifiers such as
>>   cpe://redhat:enterprise_linux:2.1:as/bind
>>
>I have been developing the definitions for the distributions
>released by
>Novell. But i have not delinieated the package to a specific
>distribution. Simply due to the fact that a cpe identifier may be
>equivalent for some other 5+ distributions within Novell. So what I
>chose to do is the following:
>
> cpe:///novell:apparmor:2.0.1
>
>I left the os specification off and focus on the application
>identifier.  This simply says that the application may be
>installed on any distribution.

I agree that this is the way to go in this case.  I think this also
aligns with the file Mark is working on at Red Hat.  For example, the
very first line of his example should probably read:

cpe:/a:redhat:bind

What this would say is describes is all versions of that application
bind as released by Red Hat.  This could be futher defined by including
a version number if needed.

Mark - does this align with the information you are trying to convey?
In your file, are you saying that the given advisory which describes
CVE-xxxx applies to Bind?






>> Then we have the layered products, where "Red Hat
>> Application Stack" is just a set of applications
>> that are additional or replacements for the ones
>> shipped with the base OS.  Is "Red Hat Application
>> Stack" an application (probably not,
>> it's just a container for a number of apps)
>>
>> Example from the mapping:
>>   cpe://redhat:rhel_application_stack:1/mod_perl

I would concider this an application for CPE in the same view as
Microsoft Office is an application.  I think the bigger question is in
terms of matching.  If a vulnerability is in one of the individual
apps, and tool reports that Red Hat Application Stack is present, how
can we match that the application is part of the roll-up?

If was suggested before to have some type of alias structure in CPE to
account for these roll-ups.  But I don't see how we can implement this
in a nice way.

>> We also have the issue that the apps we ship are ones
>> containing our own backported patches, so unlike say
>> RealPlayer where anyone shipping RealPlayer
>> is shipping the official Adobe binaries, our Apache httpd
>> is not the official :apache_software_foundation:httpd and
>> to use that in a CPE referenced in our advisory would be
>> incorrect.
>
>You can review conversation that I brought up in the mailinglist
>archives with regards to this issue. I believe whole-heartedly
>that this
>should be handled as though the originating organization is the
>authoritative entity for each package:
>
>e.g. cpe:///redhat:httpd
>
>I know that Novell alters much of the code before packaging and
>distributes the package with varying degrees of support. The way I see
>it, this should be reason enough to use novell as the vendor
>identifier.
>The same would work for redhat and the fedora_project.

I agree, if you alter the package, the vendor name should change.




Thanks
Drew

[Andrew Buttner]

>So my confusion is also in the distinction between app and OS;
>for us Red Hat Enterprise Linux is a bundle of 2000+ different
>applications.  So we never issue an update that fixes the OS,
>just applications that are part of the OS (even the linux
>kernel itself is just one of the included applications).

I think the distinction in CPE is there only because the general public
think in these terms.  One of the original goals was to create a name
that seemed intuitive so breaking out the OS seemed natural.

Treating an OS as an Application would be easy enough to do in CPE.
Basically just rename everything that is an OS and change it to an App.
The OS piece would be thought of as the kernel.  We could have two
areas in that case: Hardward and Application.

Are there others that feel that this would be a good thing?  Why not do
this?

Thanks
Drew

[Mark J Cox-2]

> Mark - does this align with the information you are trying to convey?
> In your file, are you saying that the given advisory which describes
> CVE-xxxx applies to Bind?

So we ship lots of different versions of bind, and the advisory describes
a fix that applies to some of the versions of bind.

A better example might be RHSA-2007:0569
https://rhn.redhat.com/errata/RHSA-2007-0569.html

This advisory applies to tomcat5-5.5.23 as shipped in
redhat:enterprise_linux:5:client_workstation and
redhat:enterprise_linux:5:server
but not the tomcat we shipped in redhat:certificate_server:7.2 or
redhat:certificate_server:7.3 or redhat:rhel_application_server:1 or
redhat:rhel_application_server:2 or redhat:rhel_directory_server:3 or
fedora_project:fedora_core:6 or fedora_project:fedora:7, even though some
of those share the same tomcat version number (and indeed that isn't the
complete list of distributions in which we ship the same and different
versions of the tomcat application)

Cheers, Mark

[Andrew Buttner]

One thing to remember is that we can not encode all the information
about when a vulnerability/patch applies in a CPE Name.  At some point,
the level of information needs to stop and users need to be directed to
the OVAL Definition instead.

So what is the goal we are trying to accomplish by using a CPE Name?
Obviously everyone is going to have slightly different goals.  CPE is
trying to provide a unique name for a variety of platforms.

For the example we had been working with, I would suggest that you
provide a list of CPE Names.  Each name would represent a version of
Bind that is affected by the advisory.

cpe:/a:redhat:bind:2.3
cpe:/a:redhat:bind:2.4
cpe:/a:redhat:bind:2.5

Of course you provided an example where this wouldn't work ...

>A better example might be RHSA-2007:0569
>https://rhn.redhat.com/errata/RHSA-2007-0569.html
>
>This advisory applies to tomcat5-5.5.23 as shipped in
>redhat:enterprise_linux:5:client_workstation and
>redhat:enterprise_linux:5:server
>but not the tomcat we shipped in
>redhat:certificate_server:7.2 or
>redhat:certificate_server:7.3 or
>redhat:rhel_application_server:1 or
>redhat:rhel_application_server:2 or
>redhat:rhel_directory_server:3 or
>fedora_project:fedora_core:6 or
>fedora_project:fedora:7,
>even though some of those share the same tomcat version
>number (and indeed that isn't the complete list of
>distributions in which we ship the same and different
>versions of the tomcat application)

The current 2.0 draft would have this relationship expressed by the CPE
Language.  And given the talk to remove the string representation, this
would be done via a chunk of XML.  Looking at the info trying to be
conveyed in the example, XML may not be a bad idea.  Of course you may
not be set up to hold an XML block where this info is being stored.

I think this is a GREAT use case for helping us determine where to go
with CPE related to this issue.  The debate is about complex names vs.
languages.  Should CPE Names attempt to relay the information in the
example above?  Should this be left to the CPE Language?  Should the
CPE Language have a string representation so instances can be stored
along side traditional CPE Names?  Should users that need complex name
just be forced to use XML?

Lots of questions that require lots of thought.  The more opinions we
can have on this the better.

Thanks
Drew

[Stephen.Quinn]

Drew et al,

  I suggest we solicit DISA as to how they handled their platform naming
construct in the Gold Disk/VMS paradigm.  If I recall, it pairs a sequential
index number to an ordered, enumerated platform category.  This allows for
mathematical traversals of the index to determine conditional applicability of
vulnerabilities/misconfigurations (i.e. CCEs) while at the same time offering an
English Prose platform naming construct for higher-level roll up.  The approach
accommodated the requirements of both the host-based scanner and
import/reporting requirements of the database.  It also provided a clear
demarcation as to where the platform name stops and the logic for conditional
CCE/CVE begins.

Can anyone from the DISA VMS/Gold Disk team weigh in on this?  If I missed their
comments from an earlier thread, my apologies in advance.

Respectfully,
Steve

Quoting "Buttner, Drew" <[hidden email]>:

> One thing to remember is that we can not encode all the information
> about when a vulnerability/patch applies in a CPE Name.  At some point,
> the level of information needs to stop and users need to be directed to
> the OVAL Definition instead.
>
> So what is the goal we are trying to accomplish by using a CPE Name?
> Obviously everyone is going to have slightly different goals.  CPE is
> trying to provide a unique name for a variety of platforms.
>
> For the example we had been working with, I would suggest that you
> provide a list of CPE Names.  Each name would represent a version of
> Bind that is affected by the advisory.
>
> cpe:/a:redhat:bind:2.3
> cpe:/a:redhat:bind:2.4
> cpe:/a:redhat:bind:2.5
>
> Of course you provided an example where this wouldn't work ...
>
>
> >A better example might be RHSA-2007:0569
> >https://rhn.redhat.com/errata/RHSA-2007-0569.html
> >
> >This advisory applies to tomcat5-5.5.23 as shipped in
> >redhat:enterprise_linux:5:client_workstation and
> >redhat:enterprise_linux:5:server
> >but not the tomcat we shipped in
> >redhat:certificate_server:7.2 or
> >redhat:certificate_server:7.3 or
> >redhat:rhel_application_server:1 or
> >redhat:rhel_application_server:2 or
> >redhat:rhel_directory_server:3 or
> >fedora_project:fedora_core:6 or
> >fedora_project:fedora:7,
> >even though some of those share the same tomcat version
> >number (and indeed that isn't the complete list of
> >distributions in which we ship the same and different
> >versions of the tomcat application)
>
>
> The current 2.0 draft would have this relationship expressed by the CPE
> Language.  And given the talk to remove the string representation, this
> would be done via a chunk of XML.  Looking at the info trying to be
> conveyed in the example, XML may not be a bad idea.  Of course you may
> not be set up to hold an XML block where this info is being stored.
>
> I think this is a GREAT use case for helping us determine where to go
> with CPE related to this issue.  The debate is about complex names vs.
> languages.  Should CPE Names attempt to relay the information in the
> example above?  Should this be left to the CPE Language?  Should the
> CPE Language have a string representation so instances can be stored
> along side traditional CPE Names?  Should users that need complex name
> just be forced to use XML?
>
> Lots of questions that require lots of thought.  The more opinions we
> can have on this the better.
>
> Thanks
> Drew
>

--
Stephen Quinn
NIST

[Mark J Cox-2]

> Of course you may not be set up to hold an XML block where this info is
> being stored.

So it does come down to the goal -- what is the purpose of mapping a Red
Hat advisory to a CPE name?  My purpose was two-fold:

Firstly our advisories already may apply to multiple products, see for
example https://rhn.redhat.com/errata/RHSA-2007-0731.html I wanted to
ensure that each of the affected products is referred to by CPE name.  In
this case the fact this is a flaw in the tetex component is not so
important.

Secondly I used it for generation of statistics from
http://people.redhat.com/~mjc/metrics.html, so you can use CPE in order to
specify some subset of vulnerabilities you are interested in ("show
me all the vulnerbilities that affected xpdf on RHEL 5 server edition" is
as simple as specifying "cpe://redhat:enterprise_linux:5:server/xpdf" on
the command line to the tool.

For our OVAL queries I was intending to use this at the 'platform' level
too, see <affected> in
http://people.redhat.com/~mjc/oval/com.redhat.rhsa-20070731.xml

So, thinking outloud, perhaps the CPE distinction isn't OS vs Application
but more "platform" (where a platform can be a collection/framework of
applications) vs Application?

Mark

[Stephen.Quinn]

Team,

 This was the response from Christopher Johnson of DISA's VMS/Gold Disk team:

Steve,

VMS and Gold Disk employ elements and conditions in two distinct ways:

1.  Asset Registration:

Elements are used to describe securable objects.  A securable object is
defined as any physical or logical object for which security guidance
can be issued.  Each element is a singular assertion or fact used to
describe these objects.  During asset registration, the user either
manually traverses the element treeview display and selects those
products present on the system or imports the asset element posture from
an automated tool.  As seen in the examples below, an element can serve
as a container object (e.g., Computing, Operating System).  In most
cases, an effort has been made by the element maintainers to "fully
qualify" the name of each element.

    Computing -> Operating System -> Windows -> Windows 2000 -> Windows
2000 SP4
    Non-Computing -> Enclave -> Data Center Enclave

2.  Vulnerability Maintenance:

Conditions are Boolean expressions comprised of Elements.  Conditions
can be associated with vulnerabilities and with Gold Disk checks/fixes
and are used to identify the affected products.

    For example:  (Windows 2000 AND Member Server AND Oracle 9i)

When associating a condition with a vulnerability in VMS, the
vulnerability maintainer must also identify a "target" element.  The
target element in this context identifies the element that is
vulnerable.  For instance, in the previous example both Windows 2000 and
Oracle 9i are evaluated as part of the condition.  The ability to assign
a target allows the vulnerability maintainer to answer the questions "Is
this an Oracle vulnerability that is present when run on a Windows 2000
system" or "Is this a Windows vulnerability that manifests itself when
Oracle 9i is installed on the system?".  The target element also
provides a means for logically grouping vulnerabilities according to the
affected product.  Though available to the vulnerability maintainer,
most of the conditional complexity is implemented at the Gold Disk check
and fix level.

There is both a integer key and a unique textual description associated
with each element.  The element also maintains two integer values
(LeftNodeID and RightNodeID) that are used for traversal purposes as
part of a nested-set implementation.  These values determine the
element's global location within the tree hierarchy and establish the
set boundaries that are used by the stored procedure algorithms that
assign vulnerabilities to assets.


-Chris

Quoting [hidden email]:

> Drew et al,
>
>   I suggest we solicit DISA as to how they handled their platform naming
> construct in the Gold Disk/VMS paradigm.  If I recall, it pairs a sequential
> index number to an ordered, enumerated platform category.  This allows for
> mathematical traversals of the index to determine conditional applicability
> of
> vulnerabilities/misconfigurations (i.e. CCEs) while at the same time offering
> an
> English Prose platform naming construct for higher-level roll up.  The
> approach
> accommodated the requirements of both the host-based scanner and
> import/reporting requirements of the database.  It also provided a clear
> demarcation as to where the platform name stops and the logic for
> conditional
> CCE/CVE begins.
>
> Can anyone from the DISA VMS/Gold Disk team weigh in on this?  If I missed
> their
> comments from an earlier thread, my apologies in advance.
>
> Respectfully,
> Steve
>
> Quoting "Buttner, Drew" <[hidden email]>:
>
> > One thing to remember is that we can not encode all the information
> > about when a vulnerability/patch applies in a CPE Name.  At some point,
> > the level of information needs to stop and users need to be directed to
> > the OVAL Definition instead.
> >
> > So what is the goal we are trying to accomplish by using a CPE Name?
> > Obviously everyone is going to have slightly different goals.  CPE is
> > trying to provide a unique name for a variety of platforms.
> >
> > For the example we had been working with, I would suggest that you
> > provide a list of CPE Names.  Each name would represent a version of
> > Bind that is affected by the advisory.
> >
> > cpe:/a:redhat:bind:2.3
> > cpe:/a:redhat:bind:2.4
> > cpe:/a:redhat:bind:2.5
> >
> > Of course you provided an example where this wouldn't work ...
> >
> >
> > >A better example might be RHSA-2007:0569
> > >https://rhn.redhat.com/errata/RHSA-2007-0569.html
> > >
> > >This advisory applies to tomcat5-5.5.23 as shipped in
> > >redhat:enterprise_linux:5:client_workstation and
> > >redhat:enterprise_linux:5:server
> > >but not the tomcat we shipped in
> > >redhat:certificate_server:7.2 or
> > >redhat:certificate_server:7.3 or
> > >redhat:rhel_application_server:1 or
> > >redhat:rhel_application_server:2 or
> > >redhat:rhel_directory_server:3 or
> > >fedora_project:fedora_core:6 or
> > >fedora_project:fedora:7,
> > >even though some of those share the same tomcat version
> > >number (and indeed that isn't the complete list of
> > >distributions in which we ship the same and different
> > >versions of the tomcat application)
> >
> >
> > The current 2.0 draft would have this relationship expressed by the CPE
> > Language.  And given the talk to remove the string representation, this
> > would be done via a chunk of XML.  Looking at the info trying to be
> > conveyed in the example, XML may not be a bad idea.  Of course you may
> > not be set up to hold an XML block where this info is being stored.
> >
> > I think this is a GREAT use case for helping us determine where to go
> > with CPE related to this issue.  The debate is about complex names vs.
> > languages.  Should CPE Names attempt to relay the information in the
> > example above?  Should this be left to the CPE Language?  Should the
> > CPE Language have a string representation so instances can be stored
> > along side traditional CPE Names?  Should users that need complex name
> > just be forced to use XML?
> >
> > Lots of questions that require lots of thought.  The more opinions we
> > can have on this the better.
> >
> > Thanks
> > Drew
> >
>
>
> --
> Stephen Quinn
> NIST

--
Stephen Quinn
NIST

[Andrew Buttner]

>Firstly our advisories already may apply to multiple products, see for

>example https://rhn.redhat.com/errata/RHSA-2007-0731.html I wanted to
>ensure that each of the affected products is referred to by
>CPE name.  In this case the fact this is a flaw in the tetex component
>is not so important.

This is well within the ability of CPE.  These would be simple names
that specify a specific version/edition of the operating system.  You
would have one name for each OS affected.



>Secondly I used it for generation of statistics from
>http://people.redhat.com/~mjc/metrics.html, so you can use CPE
>in order to specify some subset of vulnerabilities you are interested
>in ("show me all the vulnerbilities that affected xpdf on RHEL 5
server
>edition" is as simple as specifying
>"cpe://redhat:enterprise_linux:5:server/xpdf" on the command line to
>the tool.

This is a bit more interesting.  Here, you need the mapping of OS and
Application.  The proposed way to do this in CPE 2.0 would be to use
the CPE Language.  You would have individual CPE Names for the
different operating systems, and individual CPE Names for each
application, and you would use the CPE Language to encode the
relationships.

For your implementation, each advisory could be associated with a chunk
of XML that represents these relationships via the CPE Language.  This
XML could then be used to generate the view needed at the top of this
email by just pulling out the affected OS names.  This XML could also
be used to support queries from the command line tool.

Was I clear in expressing what I am thinking?  Would this work for the
Red Hat advisories?



>For our OVAL queries I was intending to use this at the
>'platform' level too, see <affected> in
>http://people.redhat.com/~mjc/oval/com.redhat.rhsa-20070731.xml

I could see OVAL leveraging this technique talked about above in the
future.  Maybe the <affected> element becomes a chunk of XML that
follows the CPE Language.  It would hold all the relationships between
different CPE Names.  Maybe these relationships could then be leveraged
by the <criteria> of an OVAL Definition to determine when a definition
applies.  Hmmm.......




>So, thinking out loud, perhaps the CPE distinction isn't OS vs
>Application but more "platform" (where a platform can be a
>collection/framework of applications) vs Application?

I would agree with you here.

Thanks
Drew