[MOVE THIS THREAD TO rpm-devel@ FOR FURTHER DISCUSSION. PLEASE REPLY HERE NOW]
-----------------------------------------------------------------------------
From: Jeff Johnson <n3npq@mac.com>
Date: Sat, 26 May 2007 22:02:59 -0400
Software maintenance, particularly for "stable" distros, is
increasingly the
drudgery of fixing security problems in deployed software packages.
I doubt there is anyone on this list who doesn't spend some significant
time figgering which packages are affected, adding patches, rebuilding,
retesting, releasing, etc, etc.
I've always wanted to try automating some of the drudgery. By this, I
mean using something like a RSS feed with a pattern match or
range comparsion against installed packages to display pertinent
CVE's using
rpm --query as a client.
Note that my ulterior motive is to start carefully using and extending
rpmio transport within rpm. Adding hkp:// pubkey retrieval to rpm-4.4.2
was my first step in this direction, CVE info as meta-metadata, or
perhaps
number of open bug reports, or position in a rebuild queue, are all
candidate
data streams.
If anyone wishes to help define a format, and/or help set up the
server side,
I'd love the excuse to hack a bit on rpmio.
Ralf: btw, I still owe you modern proxy support in rpmio. All I need is
a proxy to bounce against for a while. And I'm a lazy schmuck ;-)
73 de Jeff
-----------------------------------------------------------------------------
From: "Ralf S. Engelschall" <rse+rpm-devel@rpm5.org>
Date: Sun, 27 May 2007 09:52:11 +0200
On Sat, May 26, 2007, Jeff Johnson wrote:
> Software maintenance, particularly for "stable" distros, is increasingly the
> drudgery of fixing security problems in deployed software packages.
>
> I doubt there is anyone on this list who doesn't spend some significant
> time figgering which packages are affected, adding patches, rebuilding,
> retesting, releasing, etc, etc.
>
> I've always wanted to try automating some of the drudgery. By this, I
> mean using something like a RSS feed with a pattern match or
> range comparsion against installed packages to display pertinent CVE's using
> rpm --query as a client.
>
> Note that my ulterior motive is to start carefully using and extending
> rpmio transport within rpm. Adding hkp:// pubkey retrieval to rpm-4.4.2
> was my first step in this direction, CVE info as meta-metadata, or perhaps
> number of open bug reports, or position in a rebuild queue, are all
> candidate
> data streams.
>
> If anyone wishes to help define a format, and/or help set up the
> server side, I'd love the excuse to hack a bit on rpmio.
If I understand you correctly your idea is that one could do someting
like "rpm --check-security" (or whatever the command is), then "rpm"
will use a still-to-be-defined network protocol to find out from a
server database whether more or less the "rpm -qa" output matches any
CVE items and if yes, it reports the matched packages and security
issues. Cool, that's _exactly_ what I would like to see since many
years. This would be a major step forward for the admins.
Two hints from my side: First, FreeBSD Ports has a tool named
"vuxml" which does exactly this against an XML based database.
See http://www.vuxml.org/ for details. Second, there is OVAL (see
http://oval.mitre.org/) which can be used for describing security issues
in a comprehensive format, too. But VuXML is IMHO sufficient here.
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
-----------------------------------------------------------------------------
From: Jeff Johnson <n3npq@mac.com>
Date: Sun, 27 May 2007 07:39:35 -0400
On May 27, 2007, at 3:52 AM, Ralf S. Engelschall wrote:
>
> If I understand you correctly your idea is that one could do someting
> like "rpm --check-security" (or whatever the command is), then "rpm"
> will use a still-to-be-defined network protocol to find out from a
> server database whether more or less the "rpm -qa" output matches any
> CVE items and if yes, it reports the matched packages and security
> issues. Cool, that's _exactly_ what I would like to see since many
> years. This would be a major step forward for the admins.
>
Correct.
(aside) One of the whackier items on my TODO list is to actually
attach and distribute the exploits with the CVE. That's exactly
what I would want to see as a sysadmin, a means to verify that, indeed,
known problems are fixed. There are issues with distributing
malware however.
> Two hints from my side: First, FreeBSD Ports has a tool named
> "vuxml" which does exactly this against an XML based database.
> See http://www.vuxml.org/ for details. Second, there is OVAL (see
> http://oval.mitre.org/) which can be used for describing security
> issues
> in a comprehensive format, too. But VuXML is IMHO sufficient here.
>
VuXML looks pretty usable. Here's a snippet of the info that I would
use under the query to identify which installed packages were affected:
<vuln vid="0e575ed3-0764-11dc-a80b-0016179b2dd5">
<topic>squirrelmail -- Cross site scripting in HTML filter</topic>
<affects>
<package>
<name>squirrelmail</name>
<range><ge>1.4.0</ge><lt>1.4.9a</lt></range>
</package>
</affects>
...
</vuln>
It has most of the markup properties I'm seeking:
1) It exists, and so doesn't have to be reinvented imperfectly.
2) The markup is self-contained and modular, and so can be packaged
as well as downloaded and cached/updated without too much fuss.
OTOH, its xml, and so Yet Another Parser must be written.
If in YAML, the presentation could be as simple as writing to stdout:
vuln:
vid: 0e575ed3-0764-11dc-a80b-0016179b2dd5
topic: squirrelmail -- Cross site scripting in HTML filter
Affects: squirrelmail >= 1.4.0
Affects: squirrelmail < 1.4.9a
(Note I've taken liberties to re-write the ranges more like RPM
dependencies)
-----------------------------------------------------------------------------
From: "Thomas Lotterer" <thomas+rpm5@lotterer.net>
Date: Sun, 27 May 2007 11:01:29 +0200
rse+rpm-devel@rpm5.org wrote on 2007-05-27 09:52:
> On Sat, May 26, 2007, Jeff Johnson wrote:
>
> "rpm --check-security" [...] to find out from a server database [...] CVE
> items and if yes, it reports the matched packages and security issues.
>
That also means packages must carry information about CVEs they defeat with
patches in order not to trigger false alarms.
Provides: defense(CVE-xxxx-xxxx)
--
http://thomas.lotterer.net
-----------------------------------------------------------------------------
From: "Ralf S. Engelschall" <rse+rpm-devel@rpm5.org>
Date: Sun, 27 May 2007 11:09:16 +0200
On Sun, May 27, 2007, Thomas Lotterer wrote:
> rse+rpm-devel@rpm5.org wrote on 2007-05-27 09:52:
> > On Sat, May 26, 2007, Jeff Johnson wrote:
> >
> > "rpm --check-security" [...] to find out from a server database [...] CVE
> > items and if yes, it reports the matched packages and security issues.
> >
> That also means packages must carry information about CVEs they defeat with
> patches in order not to trigger false alarms.
>
> Provides: defense(CVE-xxxx-xxxx)
Ops, yes, of course! Good catch. Thanks.
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
-----------------------------------------------------------------------------
From: Jeff Johnson <n3npq@mac.com>
Date: Sun, 27 May 2007 08:03:39 -0400
On May 27, 2007, at 5:01 AM, Thomas Lotterer wrote:
> rse+rpm-devel@rpm5.org wrote on 2007-05-27 09:52:
>> On Sat, May 26, 2007, Jeff Johnson wrote:
>>
>> "rpm --check-security" [...] to find out from a server database
>> [...] CVE
>> items and if yes, it reports the matched packages and security
>> issues.
>>
> That also means packages must carry information about CVEs they
> defeat with
> patches in order not to trigger false alarms.
>
> Provides: defense(CVE-xxxx-xxxx)
>
There's nothing wrong with packages carrying info like this,
nor is there anything stopping anyone from doing so with current rpm.
However, the more interesting set of packages are those that
do *NOT* carry the marker, i.e. the affected packages. So
some means to tie a CVS to packages without change is likely
more useful.
73 de Jeff
-----------------------------------------------------------------------------
From: "Thomas Lotterer" <thomas+rpm5@lotterer.net>
Date: Sun, 27 May 2007 18:21:23 +0200
n3npq@mac.com wrote on 2007-05-27 14:03:
> The more interesting set of packages are those that do *NOT* carry the
> marker, i.e. the affected packages. So some means to tie a CVS to packages
> without change is likely more useful.
>
It is obvious that those "bad" markers will not usually ship with a package
(unless one knowingly ships bad code). So the information about bugs and
vulnerabilities must be drawn from an external source, fully agreed. In
practice, I doubt such an external source will exactly identify the package in
question down to a reasonable useful level unless it's is maintained by the
packager. Which is an approach with questionable quality and trust. What I
wanted to say is that once the vendor ships a fixed package, this package
should be able to identify itself as being fixed in order not to trigger the
same alarm again.
I want to amend that it should even be possible for the packager to operate a
public database to declare an existing package as being not affected without
shipping a new package.
Quickly three cases come into my mind. They all start with
packager ships foo-1.2.3-42
CVE reports foo-1.2.3 has security flaw with integrated zlib
rpm --check-security -> alarm
Example #1: fixed with new upstream version
packager ships foo-1.2.4-43 (upstream update)
rpm --check-security -> safe
Example #2: fixed same upstream version with patch
packager ships foo-1.2.3-43 (packager patch)
rpm --check-security -> safe
Example #3: not affected
vendor adjusts "not affected" database to declare "we use external zlib"
rpm --check-security -> safe
This means we need at least two configuration parameters
1.) identify access to a database which lists known vulnerabilities (CVE)
2.) identify access to a database which lists packager "not affected" statements
The logic is then
- find vulnerability in CVE database
- rule out issues declared "not affected" by the packer database
- rule out issues declared "fixed" from packages
- alarm if vulnerability exists and not ruled out
Because of the need for a "not affected" database it is questionable whether
there is any advantage of carrying "fixed" statements in new packages. They
could be proved by the "not affected" database, too.
Call me killjoy ;-)
--
http://thomas.lotterer.net
-----------------------------------------------------------------------------
From: Jeff Johnson <n3npq@mac.com>
Date: Sun, 27 May 2007 13:10:28 -0400
On May 27, 2007, at 12:21 PM, Thomas Lotterer wrote:
> n3npq@mac.com wrote on 2007-05-27 14:03:
>> The more interesting set of packages are those that do *NOT* carry
>> the
>> marker, i.e. the affected packages. So some means to tie a CVS to
>> packages
>> without change is likely more useful.
>>
> It is obvious that those "bad" markers will not usually ship with a
> package
> (unless one knowingly ships bad code). So the information about
> bugs and
> vulnerabilities must be drawn from an external source, fully
> agreed. In
> practice, I doubt such an external source will exactly identify the
> package in
> question down to a reasonable useful level unless it's is
> maintained by the
> packager. Which is an approach with questionable quality and
> trust. What I
> wanted to say is that once the vendor ships a fixed package, this
> package
> should be able to identify itself as being fixed in order not to
> trigger the
> same alarm again.
>
We entirely agree.
> I want to amend that it should even be possible for the packager to
> operate a
> public database to declare an existing package as being not
> affected without
> shipping a new package.
>
> Quickly three cases come into my mind. They all start with
> packager ships foo-1.2.3-42
> CVE reports foo-1.2.3 has security flaw with integrated zlib
> rpm --check-security -> alarm
>
> Example #1: fixed with new upstream version
> packager ships foo-1.2.4-43 (upstream update)
> rpm --check-security -> safe
>
> Example #2: fixed same upstream version with patch
> packager ships foo-1.2.3-43 (packager patch)
> rpm --check-security -> safe
>
> Example #3: not affected
> vendor adjusts "not affected" database to declare "we use
> external zlib"
> rpm --check-security -> safe
>
> This means we need at least two configuration parameters
> 1.) identify access to a database which lists known vulnerabilities
> (CVE)
> 2.) identify access to a database which lists packager "not
> affected" statements
>
> The logic is then
> - find vulnerability in CVE database
> - rule out issues declared "not affected" by the packer database
> - rule out issues declared "fixed" from packages
> - alarm if vulnerability exists and not ruled out
>
> Because of the need for a "not affected" database it is
> questionable whether
> there is any advantage of carrying "fixed" statements in new
> packages. They
> could be proved by the "not affected" database, too.
>
> Call me killjoy ;-)
>
You clearly have thought through many of the issues wrto software and
CVE's.
What I need is an example format (VuXML will do nicely, thank you) to
lash
together a proof-of-concept implementation underneath rpm --query.
Is the VuXML format good enough for an external database or not?
73 de Jeff
-----------------------------------------------------------------------------
From: "Ralf S. Engelschall" <rse+rpm-devel@rpm5.org>
Date: Sun, 27 May 2007 21:05:43 +0200
On Sun, May 27, 2007, Jeff Johnson wrote:
> [...]
> Is the VuXML format good enough for an external database or not?
It is at least used in practice since a longer time and
as it is XML it can be extended by us if necessary, too.
For a proof-of-concept is certainly is worth to be taken.
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
-----------------------------------------------------------------------------
From: "Thomas Lotterer" <thomas+rpm5@lotterer.net>
Date: Mon, 28 May 2007 00:23:44 +0200
Back from the homework you gave me.
VuXML is a a document format for describing security issues that affect a
software collection. It is NOT a database. Databases need to be created for
every use case, currently FreeBSD and OpenBSD exist. This is only a fraction of
what was in my mind.
OVAL is a language and data definition, with reference implementation of an
language interpreter and a repository containing descriptive database with
automatable tests. This looks far more complete, but it is very heavy stuff.
They have test extensions for various operating system environments, one is for
Linux/RPM. Interestingly, the database maintainers seem to focus on Microsoft
products, I only found 12 entries for RHEL4!? Looks like a POC only.
Both have in common that they use XML and both assume someone sets up an
official database for the use case. That means there is no capability and no
need for a third party to declare an entry as "not affected". The database
maintainer would have to withdraw his incorrect entry. This is explicitly
supported in VuXML. Please understand that this simplicity comes at the price
that it is not possible to use existing databases automatically. You would have
to create a vulnerability database for Fedora3, one for Fedora4 one for
Fedora5, SLES9, SLES10, openSUSE 10 ... also these would have a very large
overlap.
One more time I find myself in a hole. My idea was that someone maintains a
generic database with automated tests. For trust reasons this may not be the
packager himself. However, the packager should be able to log specific remedies
against the generic database to comment available "fixes" and "not affected"
(maybe there are more states like "work in progress"), anyway things only he
knows.
n3npq@mac.com wrote on 2007-05-27 19:10:
> Is the VuXML format good enough for an external database or not?
>
Yes, if you stick with *specific* databases.
No or only a starting point otherwise.
--
http://thomas.lotterer.net
-----------------------------------------------------------------------------
From: Jeff Johnson <n3npq@mac.com>
Date: Sun, 27 May 2007 18:39:54 -0400
On May 27, 2007, at 6:23 PM, Thomas Lotterer wrote:
> Back from the homework you gave me.
>
> VuXML is a a document format for describing security issues that
> affect a
> software collection. It is NOT a database. Databases need to be
> created for
> every use case, currently FreeBSD and OpenBSD exist. This is only a
> fraction of
> what was in my mind.
>
> OVAL is a language and data definition, with reference
> implementation of an
> language interpreter and a repository containing descriptive
> database with
> automatable tests. This looks far more complete, but it is very
> heavy stuff.
> They have test extensions for various operating system
> environments, one is for
> Linux/RPM. Interestingly, the database maintainers seem to focus
> on Microsoft
> products, I only found 12 entries for RHEL4!? Looks like a POC only.
>
> Both have in common that they use XML and both assume someone sets
> up an
> official database for the use case. That means there is no
> capability and no
> need for a third party to declare an entry as "not affected". The
> database
> maintainer would have to withdraw his incorrect entry. This is
> explicitly
> supported in VuXML. Please understand that this simplicity comes at
> the price
> that it is not possible to use existing databases automatically.
> You would have
> to create a vulnerability database for Fedora3, one for Fedora4 one
> for
> Fedora5, SLES9, SLES10, openSUSE 10 ... also these would have a
> very large
> overlap.
>
> One more time I find myself in a hole. My idea was that someone
> maintains a
> generic database with automated tests. For trust reasons this may
> not be the
> packager himself. However, the packager should be able to log
> specific remedies
> against the generic database to comment available "fixes" and "not
> affected"
> (maybe there are more states like "work in progress"), anyway
> things only he
> knows.
>
> n3npq@mac.com wrote on 2007-05-27 19:10:
>> Is the VuXML format good enough for an external database or not?
>>
> Yes, if you stick with *specific* databases.
> No or only a starting point otherwise.
>
OK. Basically what I see is a XML format that can be used for parsing.
That same XML format could be used as import to create a database if
you wish.
Name a database (presumably sqlite), define a schema, and I'll try to
hand you
a database.
I have no love of XML parsers, prefer extraction from a database too.
And rpm --query cares little whether its a database or XML or files
or ...
underneath. There are quite a few shortcuts I can take if/when
implementing.
Simplest to implement is likely to attach a CVE index using a header
extension
to existing packages.
rpm --rebuilddb and headers will be indexed by CVE keys.
If you want sql, a little more work, like a defined schema, will be
necessary
to create the database from VuXML as an import format.
73 de Jeff
-----------------------------------------------------------------------------
From: =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb@algonet.se>
Date: Sun, 27 May 2007 11:04:23 +0200
Jeff Johnson wrote:
> Software maintenance, particularly for "stable" distros, is
> increasingly the
> drudgery of fixing security problems in deployed software packages.
>
> I doubt there is anyone on this list who doesn't spend some significant
> time figgering which packages are affected, adding patches, rebuilding,
> retesting, releasing, etc, etc.
>
> I've always wanted to try automating some of the drudgery. By this, I
> mean using something like a RSS feed with a pattern match or
> range comparsion against installed packages to display pertinent CVE's
> using
> rpm --query as a client.
That would definitely be welcome... My current "workaround" is having
the CVE
listed in the changelogs, and then filtering them out in the rpm2html
display.
See https://savannah.nongnu.org/patch/index.php?4637 (now applied to
1.9.3 +)
A more structured approach would help, especially with extended
descriptions*.
--anders
* Like the lists on https://rhn.redhat.com/errata/, with details on the
issues and links to the CVE numbers and the RPM packages (now in
OVAL) ?
Received on Mon May 28 10:19:49 2007