From dmitry at athabascau.ca Wed Jun 13 15:11:04 2012 From: dmitry at athabascau.ca (Dmitry Makovey) Date: Wed, 13 Jun 2012 09:11:04 -0600 Subject: RHSA vs CVE Message-ID: <2563540.l7W3DrKexd@dimon2.pc.athabascau.ca> Hi everybody, Background: we're currently going through external security audit and it's report enumerates things in CVE terms which paints things very "black-and-white" - they rely on reported package versions vs. actual vulnerabilities. To address this I have created a tool: https://github.com/droopy4096/rhsa_cve/blob/master/rhsa_cve/rhsa_cve_check.py what it does is it fetches RHSA mapped to CVE, CPE dictionary and CVE databases from RedHat and Mitre. Problem: Working on above tool I hav erealized that mappings are "fuzzy" to generate reliable report. Example: CVE-2009-3094 maps to RHSA-2009:1580,RHSA-2010:0602,RHSA-2009:1579,RHSA-2010:0011,RHSA-2009:1461 Now here's the trick - using RHSA data above I end up with packages like postgresql* in the mix where CVE-2009-3094 specifically refers to a single package - httpd (except it can't be reliably extracted from any of the official sources as far as I can tell) The whole purpose of above is to get CVE information, find out which packages need to be verified, then generate the script that can be ran on a machine checking whether CVE is listed in the changelog as a confirmation that issue has been addressed (even though package version has not changed). Question: Is there a better way of mapping CVE to RHSA/packages? How are others dealing with similar situation? Manual response (esp. that every audit comes up with repeats of CVE's we have appealed on the last round) doesn't seem feasible. We have increased number of external audits as well so Crafting response to each one becomes burdensome. -- Exterminate! Exterminate! -- Daleks O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- From samfw at redhat.com Wed Jun 13 18:50:56 2012 From: samfw at redhat.com (Samuel Folk-Williams) Date: Wed, 13 Jun 2012 14:50:56 -0400 (EDT) Subject: RHSA vs CVE In-Reply-To: <2563540.l7W3DrKexd@dimon2.pc.athabascau.ca> Message-ID: <21a5fdd5-6c39-4c5b-9918-73b40bfd5ed9@zmail10.collab.prod.int.phx2.redhat.com> Hi - this article should help: https://access.redhat.com/knowledge/articles/124913 Feel free to comment there with addition questions as well. -Sam ----- Original Message ----- > Hi everybody, > > Background: > we're currently going through external security audit and it's report > enumerates things in CVE terms which paints things very > "black-and-white" - > they rely on reported package versions vs. actual vulnerabilities. To > address > this I have created a tool: > > https://github.com/droopy4096/rhsa_cve/blob/master/rhsa_cve/rhsa_cve_check.py > > what it does is it fetches RHSA mapped to CVE, CPE dictionary and CVE > databases from RedHat and Mitre. > > Problem: > Working on above tool I hav erealized that mappings are "fuzzy" to > generate > reliable report. Example: CVE-2009-3094 maps to > RHSA-2009:1580,RHSA-2010:0602,RHSA-2009:1579,RHSA-2010:0011,RHSA-2009:1461 > > Now here's the trick - using RHSA data above I end up with packages > like > postgresql* in the mix where CVE-2009-3094 specifically refers to a > single > package - httpd (except it can't be reliably extracted from any of > the > official sources as far as I can tell) > > The whole purpose of above is to get CVE information, find out which > packages > need to be verified, then generate the script that can be ran on a > machine > checking whether CVE is listed in the changelog as a confirmation > that issue > has been addressed (even though package version has not changed). > > Question: > Is there a better way of mapping CVE to RHSA/packages? How are others > dealing > with similar situation? Manual response (esp. that every audit comes > up with > repeats of CVE's we have appealed on the last round) doesn't seem > feasible. We > have increased number of external audits as well so Crafting response > to each > one becomes burdensome. > > -- > Exterminate! Exterminate! > -- Daleks > > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > -- > This communication is intended for the use of the recipient to > whom it > is addressed, and may contain confidential, personal, and or > privileged > information. Please contact us immediately if you are not the > intended > recipient of this communication, and do not copy, distribute, or > take > action relying on it. Any communications received in error, or > subsequent reply, should be deleted or destroyed. > --- > > -- > redhat-sysadmin-list mailing list > redhat-sysadmin-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-sysadmin-list > From dmitry at athabascau.ca Wed Jun 13 21:40:52 2012 From: dmitry at athabascau.ca (Dmitry Makovey) Date: Wed, 13 Jun 2012 15:40:52 -0600 Subject: RHSA vs CVE In-Reply-To: <21a5fdd5-6c39-4c5b-9918-73b40bfd5ed9@zmail10.collab.prod.int.phx2.redhat.com> References: <21a5fdd5-6c39-4c5b-9918-73b40bfd5ed9@zmail10.collab.prod.int.phx2.redhat.com> Message-ID: <1675789.RYnN49ERit@dimon2.pc.athabascau.ca> On June 13, 2012 14:50:56 Samuel Folk-Williams wrote: > Hi - this article should help: > https://access.redhat.com/knowledge/articles/124913 > > Feel free to comment there with addition questions as well. Thanks for the link I've managed to overlook it somehow. It mentiones both OVAL and CVRF and spending some time staring at those files I can't really find the mapping I'm looking for. I kind of vaguelly see how I can "ductape it together" using what I've got plus some OVAL. CVRF seems to go only as far as 2012 and I need older entries (unless I'm missing something here). Trying to save myself time parsing all the extra docs - what is the best way to get mapping: CVE -> RHEL/RPM version ? RHSA is only a side-effect in my code as it was the only one providing package names associated (albeit remotely) with CVE's -- Dmitry Makovey Web Systems Administrator Athabasca University (780) 675-6245 --- Confidence is what you have before you understand the problem Woody Allen When in trouble when in doubt run in circles scream and shout http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330 -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- From rprice at redhat.com Thu Jun 14 13:42:05 2012 From: rprice at redhat.com (Robin Price II) Date: Thu, 14 Jun 2012 09:42:05 -0400 Subject: RHSA vs CVE In-Reply-To: <2563540.l7W3DrKexd@dimon2.pc.athabascau.ca> References: <2563540.l7W3DrKexd@dimon2.pc.athabascau.ca> Message-ID: <4FD9EA2D.3050909@redhat.com> Dmitry, I believe the following will help. https://access.redhat.com/security/cve/ I was able to find the CVE you mentioned. https://access.redhat.com/security/cve/CVE-2009-3094 HTHs, ~rp On 06/13/2012 11:11 AM, Dmitry Makovey wrote: > Hi everybody, > > Background: > we're currently going through external security audit and it's report > enumerates things in CVE terms which paints things very "black-and-white" - > they rely on reported package versions vs. actual vulnerabilities. To address > this I have created a tool: > > https://github.com/droopy4096/rhsa_cve/blob/master/rhsa_cve/rhsa_cve_check.py > > what it does is it fetches RHSA mapped to CVE, CPE dictionary and CVE > databases from RedHat and Mitre. > > Problem: > Working on above tool I hav erealized that mappings are "fuzzy" to generate > reliable report. Example: CVE-2009-3094 maps to > RHSA-2009:1580,RHSA-2010:0602,RHSA-2009:1579,RHSA-2010:0011,RHSA-2009:1461 > > Now here's the trick - using RHSA data above I end up with packages like > postgresql* in the mix where CVE-2009-3094 specifically refers to a single > package - httpd (except it can't be reliably extracted from any of the > official sources as far as I can tell) > > The whole purpose of above is to get CVE information, find out which packages > need to be verified, then generate the script that can be ran on a machine > checking whether CVE is listed in the changelog as a confirmation that issue > has been addressed (even though package version has not changed). > > Question: > Is there a better way of mapping CVE to RHSA/packages? How are others dealing > with similar situation? Manual response (esp. that every audit comes up with > repeats of CVE's we have appealed on the last round) doesn't seem feasible. We > have increased number of external audits as well so Crafting response to each > one becomes burdensome. > -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE,RHCDS,RHCVA | | Solutions Architect - Public Sector | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | @robinpriceii | +---------[ http://people.redhat.com/rprice ]---------+ From dmitry at athabascau.ca Thu Jun 14 15:00:27 2012 From: dmitry at athabascau.ca (Dmitry Makovey) Date: Thu, 14 Jun 2012 09:00:27 -0600 Subject: RHSA vs CVE In-Reply-To: <4FD9EA2D.3050909@redhat.com> References: <2563540.l7W3DrKexd@dimon2.pc.athabascau.ca> <4FD9EA2D.3050909@redhat.com> Message-ID: <1386200.6EuBohquIt@dimon2.pc.athabascau.ca> On June 14, 2012 09:42:05 Robin Price II wrote: > Dmitry, > > I believe the following will help. > https://access.redhat.com/security/cve/ > > I was able to find the CVE you mentioned. > https://access.redhat.com/security/cve/CVE-2009-3094 Thank you Robin, however above are interfaces that are useful for manual checks but are a mess to automate (HTML-scraping) and automated tools would have to be re-coded for each change of web design of the page. Having some "more spartan" format is what needed to automate tasks like what I'm facing. CVRF looks very promissing as it covers everything I need but it doesn't go back and doesn't have any "top level index" entry that could be used to fetch all relevant items. -- Dmitry Makovey Web Systems Administrator Athabasca University (780) 675-6245 --- Confidence is what you have before you understand the problem Woody Allen When in trouble when in doubt run in circles scream and shout http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330 -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- From dmitry at athabascau.ca Wed Jun 20 21:08:24 2012 From: dmitry at athabascau.ca (Dmitry Makovey) Date: Wed, 20 Jun 2012 15:08:24 -0600 Subject: libvirt's "default" (NAT) network is bad? Message-ID: <95754267.3dqB26cZTI@dimon2.pc.athabascau.ca> Hi, I came across this article recently: http://www.cyberciti.biz/faq/linux-kvm-disable-virbr0-nat-interface/ and we are using NAT network for inter-VM communications. Now the box in question has it's own share of performance problems that we're struggling to resolve which means I'm not 100% sure our problems stem from above source. However I was wondering whether claimed performance degradation was *that* bad? If I do NFS-over-NAT for VM's - would that really kill performance or any other aspects of setup? Or to turn the problem on it's head - what would be the most effective (best performing) way of sharing [N]FS across VMs on the same box. In this particular case even dom0 is in the mix (i.e. it's a NFS-host serving data to all VMs over NAT'ed (actually - private) network). -- Dmitry Makovey Web Systems Administrator Athabasca University (780) 675-6245 --- Confidence is what you have before you understand the problem Woody Allen When in trouble when in doubt run in circles scream and shout http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330 -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. ---