[Buildroot] RFC: CVE analysis

[Buildroot] RFC: CVE analysis

[Matthew Weber]

I was curious if anyone has done a script similar to the "make legal-info"
that takes a package list and checks it against a CVE database?  We're
looking at doing some automated tracking of vulnerabilities with our
nightly builds and were at a point of putting something together.

It might also be an interesting feature to expose on the Buildroot
website.... maybe listing the current vulnerabilities of the last release
and the current tip?

-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted Third
Party Intellectual Property (TPIP) content must be encrypted and sent to
matthew.weber at corp.rockwellcollins.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140922/758ccf5c/attachment.html>

[Buildroot] RFC: CVE analysis

[Gustavo Zacarias]

On 09/22/2014 05:21 PM, Matthew Weber wrote:

> I was curious if anyone has done a script similar to the "make
> legal-info" that takes a package list and checks it against a CVE
> database?  We're looking at doing some automated tracking of
> vulnerabilities with our nightly builds and were at a point of putting
> something together.
> 
> It might also be an interesting feature to expose on the Buildroot
> website.... maybe listing the current vulnerabilities of the last
> release and the current tip?

Hi.
I usually track CVEs and bump/fix when appropiate.
It's mostly a mix of personal scripts, nothing too fancy that i'd like
normal people to see in the current state :)
The problem with actively pursuing security fixes is that it needs some
regular manpower in patching and testing, and that's without considering
backports (though the package infra is quite stable lately).
There are outstanding packages that have some severe vulnerabilities
like cups where i did a call for volunteers to bump/fix without much
success, and i can only do so much in my free time, with cups being
somewhat complicated to test because of varying combinations.
It's not a task that can really be fully automated either because you
can get a CVE for say PHP that fixes a vulnerability that only affects
windows operating systems - there must be some context analysis as well.
I normally try to maintain some format for my security bumps/fixes but
that's completely informal, like:

Subject: Security bump PACKAGE to version x.y
Fixes:
CVE-yyyy-nnnn - short description

But then some other people might catch the bump before myself and there
goes that.

Something nicer would probably be like the .hash files for packages
where we could describe the bumps that affect security and the relevant
CVEs.

Regards.

[Buildroot] RFC: CVE analysis

[Matthew Weber]

Gustavo,

On Mon, Sep 22, 2014 at 3:38 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> On 09/22/2014 05:21 PM, Matthew Weber wrote:
>
>> I was curious if anyone has done a script similar to the "make
>> legal-info" that takes a package list and checks it against a CVE
>> database?  We're looking at doing some automated tracking of
>> vulnerabilities with our nightly builds and were at a point of putting
>> something together.
>>
>> It might also be an interesting feature to expose on the Buildroot
>> website.... maybe listing the current vulnerabilities of the last
>> release and the current tip?
>
> Hi.
> I usually track CVEs and bump/fix when appropiate.
> It's mostly a mix of personal scripts, nothing too fancy that i'd like
> normal people to see in the current state :)

Yeah, we're thinking something simple that lists current CVEs against
whatever the package revision is that's in your current checkout.
Nothing to fancy or automated with respect to updating packages.....

> The problem with actively pursuing security fixes is that it needs some
> regular manpower in patching and testing, and that's without considering
> backports (though the package infra is quite stable lately).
> There are outstanding packages that have some severe vulnerabilities
> like cups where i did a call for volunteers to bump/fix without much
> success, and i can only do so much in my free time, with cups being
> somewhat complicated to test because of varying combinations.
> It's not a task that can really be fully automated either because you
> can get a CVE for say PHP that fixes a vulnerability that only affects
> windows operating systems - there must be some context analysis as well.
> I normally try to maintain some format for my security bumps/fixes but
> that's completely informal, like:

Yeah agree, I hope by automating at least the creation of a CVE list
as part of the build would make it easier to provide the information
to get funding to push updates on packages we use.

>
> Subject: Security bump PACKAGE to version x.y
> Fixes:
> CVE-yyyy-nnnn - short description
>
> But then some other people might catch the bump before myself and there
> goes that.

Maybe it would be beneficial to create a weekly email to the list with
a digest of all package CVEs?  I think there are a couple offline
databases that may make this fairly easy to do (prevent thrashing of
the CVE databases)
     Package, Version, CVE-yyyy-nnnn - short description

>
> Something nicer would probably be like the .hash files for packages
> where we could describe the bumps that affect security and the relevant
> CVEs.

Would it be worth using this also to document if a package needs
updating but hasn't been updated.  Then this could be queried as part
of the build (make cve-info) to generate a summary instead of a
Internet CVE database query.  It would require some automation work to
generate a patch to the list to append to that file that a new CVE was
issued against it though.....  guessing doing that manually isn't
realistic.

Thanks,

-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber at corp.rockwellcollins.com.

[Buildroot] RFC: CVE analysis

[Thomas Petazzoni]

Dear Matthew Weber,

On Mon, 22 Sep 2014 16:12:56 -0500, Matthew Weber wrote:

> >> I was curious if anyone has done a script similar to the "make
> >> legal-info" that takes a package list and checks it against a CVE
> >> database?  We're looking at doing some automated tracking of
> >> vulnerabilities with our nightly builds and were at a point of putting
> >> something together.

Seems really interesting.

> Would it be worth using this also to document if a package needs
> updating but hasn't been updated.  Then this could be queried as part
> of the build (make cve-info) to generate a summary instead of a
> Internet CVE database query.  It would require some automation work to
> generate a patch to the list to append to that file that a new CVE was
> issued against it though.....  guessing doing that manually isn't
> realistic.

It's probably worth mentioning
http://patchwork.ozlabs.org/patch/337267/: it's a Python script that
checks whether a package has new versions available. It's not written
with security/CVEs in mind, but you might find it interesting, and
maybe plug some more security/CVEs oriented checks in there.

That's a script we need to review/test and then commit, as I believe it
would be very useful to have. The aim is to use it as a replacement of
support/scripts/pkg-stats, whose output is updated every day at
http://autobuild.buildroot.org/stats/.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] RFC: CVE analysis

[Joshua Kinard]

On 09/22/2014 16:38, Gustavo Zacarias wrote:
> On 09/22/2014 05:21 PM, Matthew Weber wrote:
> 
>> I was curious if anyone has done a script similar to the "make
>> legal-info" that takes a package list and checks it against a CVE
>> database?  We're looking at doing some automated tracking of
>> vulnerabilities with our nightly builds and were at a point of putting
>> something together.
>>
>> It might also be an interesting feature to expose on the Buildroot
>> website.... maybe listing the current vulnerabilities of the last
>> release and the current tip?
> 
> Hi.
> I usually track CVEs and bump/fix when appropiate.
> It's mostly a mix of personal scripts, nothing too fancy that i'd like
> normal people to see in the current state :)
> The problem with actively pursuing security fixes is that it needs some
> regular manpower in patching and testing, and that's without considering
> backports (though the package infra is quite stable lately).
> There are outstanding packages that have some severe vulnerabilities
> like cups where i did a call for volunteers to bump/fix without much
> success, and i can only do so much in my free time, with cups being
> somewhat complicated to test because of varying combinations.
> It's not a task that can really be fully automated either because you
> can get a CVE for say PHP that fixes a vulnerability that only affects
> windows operating systems - there must be some context analysis as well.
> I normally try to maintain some format for my security bumps/fixes but
> that's completely informal, like:
> 
> Subject: Security bump PACKAGE to version x.y
> Fixes:
> CVE-yyyy-nnnn - short description
> 
> But then some other people might catch the bump before myself and there
> goes that.
> 
> Something nicer would probably be like the .hash files for packages
> where we could describe the bumps that affect security and the relevant
> CVEs.

I don't know if these two sites have a formal API that's queryable, but you can
generate RSS feeds based on criteria, so maybe something programmatic can be setup:

http://www.cvedetails.com/
http://www.itsecdb.com/oval/


Also, these deal more with cyber-threat information, but has ties into
vulnerability research and are both developed by the MITRE corporation (who
manages the CVE database):

https://stix.mitre.org/
http://taxii.mitre.org/

-- 
Joshua Kinard
Gentoo/MIPS
kumba at gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[Buildroot] RFC: CVE analysis

[Matthew Weber]

Joshua,

On Sep 23, 2014 5:14 PM, "Joshua Kinard" <kumba@gentoo.org> wrote:
>
> On 09/22/2014 16:38, Gustavo Zacarias wrote:
> > On 09/22/2014 05:21 PM, Matthew Weber wrote:
> >
> >> I was curious if anyone has done a script similar to the "make
> >> legal-info" that takes a package list and checks it against a CVE
> >> database?  We're looking at doing some automated tracking of
> >> vulnerabilities with our nightly builds and were at a point of putting
> >> something together.
> >>
> >> It might also be an interesting feature to expose on the Buildroot
> >> website.... maybe listing the current vulnerabilities of the last
> >> release and the current tip?
> >
> > Hi.
> > I usually track CVEs and bump/fix when appropiate.
> > It's mostly a mix of personal scripts, nothing too fancy that i'd like
> > normal people to see in the current state :)
> > The problem with actively pursuing security fixes is that it needs some
> > regular manpower in patching and testing, and that's without considering
> > backports (though the package infra is quite stable lately).
> > There are outstanding packages that have some severe vulnerabilities
> > like cups where i did a call for volunteers to bump/fix without much
> > success, and i can only do so much in my free time, with cups being
> > somewhat complicated to test because of varying combinations.
> > It's not a task that can really be fully automated either because you
> > can get a CVE for say PHP that fixes a vulnerability that only affects
> > windows operating systems - there must be some context analysis as well.
> > I normally try to maintain some format for my security bumps/fixes but
> > that's completely informal, like:
> >
> > Subject: Security bump PACKAGE to version x.y
> > Fixes:
> > CVE-yyyy-nnnn - short description
> >
> > But then some other people might catch the bump before myself and there
> > goes that.
> >
> > Something nicer would probably be like the .hash files for packages
> > where we could describe the bumps that affect security and the relevant
> > CVEs.
>
> I don't know if these two sites have a formal API that's queryable, but
you can
> generate RSS feeds based on criteria, so maybe something programmatic can
be setup:
>
> http://www.cvedetails.com/
> http://www.itsecdb.com/oval/
>

Yeah, I was also looking at the cve-search tool (offline database with
scheduled updates from those sites).  Where if we create buildroot scripts
that query that tool.... it would lessen the access to the public sites but
it would put a requirement on setting that database and apps up if you want
that buildroot feature.

>
> Also, these deal more with cyber-threat information, but has ties into
> vulnerability research and are both developed by the MITRE corporation
(who
> manages the CVE database):
>
> https://stix.mitre.org/
> http://taxii.mitre.org/
>
> --
> Joshua Kinard
> Gentoo/MIPS
> kumba at gentoo.org
> 4096R/D25D95E3 2011-03-28
>
> "The past tempts us, the present confuses us, the future frightens us.
And our
> lives slip away, moment by moment, lost in that vast, terrible
in-between."
>
> --Emperor Turhan, Centauri Republic
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140923/8d354e6c/attachment.html>