* [Buildroot] RFC: CVE analysis @ 2014-09-22 20:21 Matthew Weber 2014-09-22 20:38 ` Gustavo Zacarias 0 siblings, 1 reply; 6+ messages in thread From: Matthew Weber @ 2014-09-22 20:21 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] RFC: CVE analysis 2014-09-22 20:21 [Buildroot] RFC: CVE analysis Matthew Weber @ 2014-09-22 20:38 ` Gustavo Zacarias 2014-09-22 21:12 ` Matthew Weber 2014-09-23 22:06 ` Joshua Kinard 0 siblings, 2 replies; 6+ messages in thread From: Gustavo Zacarias @ 2014-09-22 20:38 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] RFC: CVE analysis 2014-09-22 20:38 ` Gustavo Zacarias @ 2014-09-22 21:12 ` Matthew Weber 2014-09-23 7:43 ` Thomas Petazzoni 2014-09-23 22:06 ` Joshua Kinard 1 sibling, 1 reply; 6+ messages in thread From: Matthew Weber @ 2014-09-22 21:12 UTC (permalink / raw) To: buildroot 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] RFC: CVE analysis 2014-09-22 21:12 ` Matthew Weber @ 2014-09-23 7:43 ` Thomas Petazzoni 0 siblings, 0 replies; 6+ messages in thread From: Thomas Petazzoni @ 2014-09-23 7:43 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] RFC: CVE analysis 2014-09-22 20:38 ` Gustavo Zacarias 2014-09-22 21:12 ` Matthew Weber @ 2014-09-23 22:06 ` Joshua Kinard 2014-09-23 22:50 ` Matthew Weber 1 sibling, 1 reply; 6+ messages in thread From: Joshua Kinard @ 2014-09-23 22:06 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] RFC: CVE analysis 2014-09-23 22:06 ` Joshua Kinard @ 2014-09-23 22:50 ` Matthew Weber 0 siblings, 0 replies; 6+ messages in thread From: Matthew Weber @ 2014-09-23 22:50 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-23 22:50 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-22 20:21 [Buildroot] RFC: CVE analysis Matthew Weber 2014-09-22 20:38 ` Gustavo Zacarias 2014-09-22 21:12 ` Matthew Weber 2014-09-23 7:43 ` Thomas Petazzoni 2014-09-23 22:06 ` Joshua Kinard 2014-09-23 22:50 ` Matthew Weber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox