From bugzilla at redhat.com Sat Jan 6 08:34:47 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 6 Jan 2007 03:34:47 -0500 Subject: [Bug 221694] New: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221694 Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: normal Component: phpMyAdmin AssignedTo: imlinux at gmail.com ReportedBy: ville.skytta at iki.fi QAContact: extras-qa at fedoraproject.org CC: fedora-security-list at redhat.com,redhat- bugzilla at linuxnetz.de http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0095 "phpMyAdmin 2.9.1.1 allows remote attackers to obtain sensitive information via a direct request for themes/darkblue_orange/layout.inc.php, which reveals the path in an error message." FC5+ apparently affected, even though I'm not sure if this is an issue at all. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From stein at stone-is.com Sat Jan 6 17:00:44 2007 From: stein at stone-is.com (stein at stone-is.com) Date: 6 Jan 2007 18:00:44 +0100 Subject: AUTORESP Fedora-security-list Digest, Vol 11, Issue 2 Message-ID: <20070106170044.22378.qmail@be1.1-eurohost.com> We hebben uw mail goed ontvangen. Indien u echter een supportvraag heeft als klant, gelieve een support ticket te openen op https://cis.stone-is.net/cp , uw ticket wordt dan prioritair en met meer effici?ntie behandeld. We have received your mail. If you have a support question and are one of our customers, please open a ticket on https://cis.stone-is.net/cp, your support request will be handled more efficiently. Thank you, Stone Internet Services bvba 1-eurohost.com From bugzilla at redhat.com Sat Jan 6 17:05:05 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 6 Jan 2007 12:05:05 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200701061705.l06H55C8012801@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221694 ------- Additional Comments From tibbs at math.uh.edu 2007-01-06 12:04 EST ------- For any Fedora installation, you know the path just from inspecting the RPM. But this does disclose that the site is probably run on Fedora, which could conceivably be an issue. Not that our Apache doesn't by default do the same thing, but that's configurable. So yes, this is an issue, although it's a terribly minor one. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From stein at stone-is.com Sun Jan 7 17:00:39 2007 From: stein at stone-is.com (stein at stone-is.com) Date: 7 Jan 2007 18:00:39 +0100 Subject: AUTORESP Fedora-security-list Digest, Vol 11, Issue 3 Message-ID: <20070107170039.11051.qmail@be1.1-eurohost.com> We hebben uw mail goed ontvangen. Indien u echter een supportvraag heeft als klant, gelieve een support ticket te openen op https://cis.stone-is.net/cp , uw ticket wordt dan prioritair en met meer effici?ntie behandeld. We have received your mail. If you have a support question and are one of our customers, please open a ticket on https://cis.stone-is.net/cp, your support request will be handled more efficiently. Thank you, Stone Internet Services bvba 1-eurohost.com From bugzilla at redhat.com Mon Jan 8 01:42:36 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 7 Jan 2007 20:42:36 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200701080142.l081gaq1030343@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221694 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From imlinux at gmail.com 2007-01-07 20:42 EST ------- I agree with Tibbs, I'm going to keep an eye on this to see if anything more comes of it I'll update. Otherwise I'll wait until the next version comes out. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From stein at stone-is.com Mon Jan 8 16:59:38 2007 From: stein at stone-is.com (stein at stone-is.com) Date: 8 Jan 2007 17:59:38 +0100 Subject: AUTORESP Fedora-security-list Digest, Vol 11, Issue 4 Message-ID: <20070108165938.22295.qmail@vz07.lin.stone-is.net> Indien u als bestaande klant een supportvraag heeft, gelieve een ticket te openen op https://cis.stone-is.net/cp. U zal dan sneller en efficienter geholpen worden. Bedankt! If you have a support question and you are an existing customer, please open a ticket on https://cis.stone-is.net/cp. We will be able to help you in a more efficient way. Thank you! Stone Internet Services bvba / 1-eurohost.com From chitlesh at fedoraproject.org Mon Jan 8 17:59:25 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 8 Jan 2007 18:59:25 +0100 Subject: SPAMMERS in this list Message-ID: <13dbfe4f0701080959w488f7966k56644ce094b9b7e@mail.gmail.com> Hello there, I confirm what I said in my previous mail in this list. There are spammers around here! Chitlesh -- http://clunixchit.blogspot.com From dennis at ausil.us Mon Jan 8 18:05:46 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Jan 2007 12:05:46 -0600 Subject: SPAMMERS in this list In-Reply-To: <13dbfe4f0701080959w488f7966k56644ce094b9b7e@mail.gmail.com> References: <13dbfe4f0701080959w488f7966k56644ce094b9b7e@mail.gmail.com> Message-ID: <200701081205.46701.dennis@ausil.us> On Monday 08 January 2007 11:59, Chitlesh GOORAH wrote: > Hello there, > I confirm what I said in my previous mail in this list. > There are spammers around here! > > Chitlesh umm AFAIKT this is your first post to this list -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From chitlesh at fedoraproject.org Mon Jan 8 18:09:06 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 8 Jan 2007 19:09:06 +0100 Subject: SPAMMERS in this list In-Reply-To: <200701081205.46701.dennis@ausil.us> References: <13dbfe4f0701080959w488f7966k56644ce094b9b7e@mail.gmail.com> <200701081205.46701.dennis@ausil.us> Message-ID: <13dbfe4f0701081009v42284693he2a2cade68e12e18@mail.gmail.com> On 1/8/07, Dennis Gilmore wrote: > umm AFAIKT this is your first post to this list > umm, true, I'd press on Reply instead of Reply to All anyway, an example of spam see the mail : Re: AUTORESP Fedora-security-list Digest, Vol 11, Issue 4 Chitlesh -- http://clunixchit.blogspot.com From bugzilla at redhat.com Mon Jan 8 23:43:18 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 8 Jan 2007 18:43:18 -0500 Subject: [Bug 212698] CVE-2006-4513: multiple integer overflows in wv < 1.2.3 In-Reply-To: Message-ID: <200701082343.l08NhIiQ012438@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-4513: multiple integer overflows in wv < 1.2.3 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212698 uwog at uwog.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |UPSTREAM ------- Additional Comments From uwog at uwog.net 2007-01-08 18:43 EST ------- Fixed in abi 2.4.6 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Jan 9 09:54:55 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 9 Jan 2007 04:54:55 -0500 Subject: [Bug 221958] New: Security vulnerability in MediaWiki Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221958 Summary: Security vulnerability in MediaWiki Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: urgent Priority: urgent Component: mediawiki AssignedTo: Axel.Thimm at ATrpms.net ReportedBy: roozbeh at farsiweb.info QAContact: extras-qa at fedoraproject.org CC: fedora-security- list at redhat.com,fedora at theholbrooks.org,roozbeh at farsiweb .info MediaWiki has just made a release with a security vulnerabiliy fixed: http://lists.wikimedia.org/pipermail/mediawiki-announce/2007-January/000056.html This means that FC6 and devel branches should be upgraded to 1.8.3. The situation for FC5 is more complex, as it is shipping 1.5.8 which is considered obsolete by upstream it seems. It may need to be upgraded to the 1.6.x or later series. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Jan 9 10:41:12 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 9 Jan 2007 05:41:12 -0500 Subject: [Bug 191089] mantis multiple vulnerabilities In-Reply-To: Message-ID: <200701091041.l09AfCOW015199@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: mantis multiple vulnerabilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191089 giallu at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From giallu at gmail.com 2007-01-09 05:40 EST ------- No more updates are going to FC4. Closing since it is not applicable to FC5 and newer -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Jan 9 10:47:08 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 9 Jan 2007 05:47:08 -0500 Subject: [Bug 219720] CVE-2006-6515: mantis bug reminder threshold issue In-Reply-To: Message-ID: <200701091047.l09Al8nZ015890@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-6515: mantis bug reminder threshold issue https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219720 giallu at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX ------- Additional Comments From giallu at gmail.com 2007-01-09 05:47 EST ------- FC3/4 are not receiving updates anymore. FC5 and newer are not affected. Closing -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Jan 9 11:38:17 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 9 Jan 2007 06:38:17 -0500 Subject: [Bug 219937] CVE-2006-6574: mantis < 1.1.0a2 information disclosure In-Reply-To: Message-ID: <200701091138.l09BcHT1018923@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-6574: mantis < 1.1.0a2 information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219937 ------- Additional Comments From giallu at gmail.com 2007-01-09 06:38 EST ------- mantis references: http://www.mantisbt.org/bugs/view.php?id=7364 http://www.mantisbt.org/bugs/view.php?id=3375 both fixed in CVS -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Jan 9 12:17:54 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 9 Jan 2007 07:17:54 -0500 Subject: [Bug 221958] Security vulnerability in MediaWiki In-Reply-To: Message-ID: <200701091217.l09CHsXv021253@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Security vulnerability in MediaWiki https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221958 Axel.Thimm at ATrpms.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From Axel.Thimm at ATrpms.net 2007-01-09 07:17 EST ------- Building updated packages. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Tue Jan 9 13:07:10 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 9 Jan 2007 08:07:10 -0500 Subject: [Bug 221958] Security vulnerability in MediaWiki In-Reply-To: Message-ID: <200701091307.l09D7AaJ024347@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Security vulnerability in MediaWiki https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221958 Axel.Thimm at ATrpms.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |CURRENTRELEASE Fixed In Version| |1_8_3-7 ------- Additional Comments From Axel.Thimm at ATrpms.net 2007-01-09 08:06 EST ------- Packages are waiting in the needsign queue. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Jan 11 13:29:33 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 11 Jan 2007 08:29:33 -0500 Subject: [Bug 208299] CVE-2006-4976: php-adodb information disclosure In-Reply-To: Message-ID: <200701111329.l0BDTXUc011304@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-4976: php-adodb information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208299 gauret at free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution| |NOTABUG Status|NEW |CLOSED ------- Additional Comments From gauret at free.fr 2007-01-11 08:29 EST ------- As seen in this thread, it seems there is no threat. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Jan 12 15:17:28 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 12 Jan 2007 10:17:28 -0500 Subject: [Bug 222410] Remote execution vulnerability in cacti. In-Reply-To: Message-ID: <200701121517.l0CFHSUq014980@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Remote execution vulnerability in cacti. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222410 bressers at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-security- | |list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Jan 12 15:25:32 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 12 Jan 2007 10:25:32 -0500 Subject: [Bug 222410] Remote execution vulnerability in cacti. In-Reply-To: Message-ID: <200701121525.l0CFPWMI015784@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Remote execution vulnerability in cacti. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222410 bressers at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |Security -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Jan 12 15:39:39 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 12 Jan 2007 10:39:39 -0500 Subject: [Bug 222410] Remote execution vulnerability in cacti. In-Reply-To: Message-ID: <200701121539.l0CFddYZ017152@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Remote execution vulnerability in cacti. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222410 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Jan 12 18:14:54 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 12 Jan 2007 13:14:54 -0500 Subject: [Bug 222410] Remote execution vulnerability in cacti. In-Reply-To: Message-ID: <200701121814.l0CIEsrL028818@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Remote execution vulnerability in cacti. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222410 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From imlinux at gmail.com 2007-01-12 13:14 EST ------- Built, should be on the mirrors soon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Jan 12 23:11:53 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 12 Jan 2007 18:11:53 -0500 Subject: [Bug 219937] CVE-2006-6574: mantis < 1.1.0a2 information disclosure In-Reply-To: Message-ID: <200701122311.l0CNBrXO017590@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-6574: mantis < 1.1.0a2 information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219937 giallu at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |CURRENTRELEASE Fixed In Version| |1.0.6-2 ------- Additional Comments From giallu at gmail.com 2007-01-12 18:11 EST ------- Patched packages are now published in all branches (FC5, FC6 and devel) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bressers at redhat.com Tue Jan 16 14:19:07 2007 From: bressers at redhat.com (Josh Bressers) Date: Tue, 16 Jan 2007 09:19:07 -0500 Subject: Merging Core and Extras affecting security updates Message-ID: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> With the current plans to merge Fedora Core and Extras, we need to create a unified security team to handle the various security flaws that emerge within the distribution. I've been thinking about this quite a bit, and I think the goal that needs to be kept in mind is "Keep Fedora users secure". That goal is fairly vague on purpose. Here's how I'm thinking this can be done. Initially, we're going to ignore embargoed issues. Every time a security conversation comes up, people start creating overly complex processes to handle them. Once there is a concrete team and process, this can be investigated. In the meantime, we'll just deal with issues once they're public. I think we should handle security flaws in a logical and sensible manner. There are a lot of packages to support, and unless we prioritize the load in a sensible manner, things will get out of hand. The first thing to understand is that there is not enough time or manpower to fix every single security flaw we see. I wish there was, but the truth of the matter is that we can't fix it all. Based on that idea, I think it's important to fix things in a prioritized manner. The way I see this is that it makes more sense to invest extra time working on getting a Firefox critical update out before say a minor lha temporary file flaw. I don't think the team should ever tell someone not to work on something, but we should also not obsess over less severe issues and packages when there are more important things. This makes me think the security team should view Fedora in a light where we place extra priority based on the most used packages. How can we determine what are the most used packages? I'd say initially we can trust that anything shipped on the install media is used more heavily than things that are not, but also using common sense. If there is a flaw that affects Firefox and lynx in the same way, I'd say Firefox would deserve a first look as it's obviously used more than lynx. We would of course want to fix lynx, but given limited manpower, that fix may be delayed a day or two. Other factors such as "does an exploit exist" and "how likely is it this flaw will be exploited" should be considered. Right now Red Hat fixes flaws by severity alone. The Fedora Security Response Team will probably have to classify flaws by risk, which takes severity into account, but isn't the sole category. This definite of risk will need to be defined and no doubt will evolve over time. I'm also not a fan of being an exclusive group. I think letting anyone help who wants to is the way to go. We already have a public list. Bugzilla is available to anyone who has a login. We should welcome and encourage outsiders to help file bugs, triage issues, and find patches. Obviously, when we handle embargoed issues, we would have a backchannel communication method with trusted individuals. The more transparent we make our security process, the less it can be scrutinized. We should never have anything to hide. Right now the Red Hat Security Response Team handles Fedora Core issues, while Extras is mostly ignored due to missing infrastructure to properly handle security flaws. The tracking of the flaws that affect only Fedora Core and Red Hat Enterprise Linux is a considerable task currently. The workload is nearly one full time person per week simply to determine which flaws affect what is shipped. Once Extras and Core are merged, this load is going to go up substantially for Fedora. Handling the pace of incoming flaws will prove to be a challenge. I suspect there are members of the Red Hat Security Response Team who will want to work with Fedora as the success of Fedora is in our best interest. There will also be some overlap on tasks. If we're investigating a flaw for Red Hat Enterprise Linux that also affects Fedora, it would be silly not to also conduct the Fedora investigation. This brings me to the next topic: how to make this all work. The biggest missing puzzle piece is the lack of tools. I'm currently working on some tools to more easily track CVE ids via a clever bugzilla interface. I have some notes on how I plan to do this elsewhere. I can post them at a later date if anyone is interested. The bigger tool I'm looking for is the package release tool. It's likely that the security team will want to view the text of all security updates and edit it if needed. I've mailed lmacken requesting this ability, he has informed me that the functionality is there. I'm of the impression that as long as the team has the right tools, we can operate very efficiently and handle the current inflow of issues. If you think I've missed something here, please let me know. I'm certain that this transition will be a bit bumpy, but should work out in the end as long as everyone cooperates. Thanks. -- JB From lmacken at redhat.com Tue Jan 16 15:04:35 2007 From: lmacken at redhat.com (Luke Macken) Date: Tue, 16 Jan 2007 10:04:35 -0500 Subject: Merging Core and Extras affecting security updates In-Reply-To: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> References: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> Message-ID: <20070116150435.GL3456@tomservo.rh.rit.edu> On Tue, Jan 16, 2007 at 09:19:07AM -0500, Josh Bressers wrote: > The biggest missing puzzle piece is the lack of tools. I'm currently working > on some tools to more easily track CVE ids via a clever bugzilla interface. I > have some notes on how I plan to do this elsewhere. I can post them at a > later date if anyone is interested. The bigger tool I'm looking for is the > package release tool. It's likely that the security team will want to view > the text of all security updates and edit it if needed. I've mailed lmacken > requesting this ability, he has informed me that the functionality is there. > I'm of the impression that as long as the team has the right tools, we can > operate very efficiently and handle the current inflow of issues. I'd be interested in seeing the details of your Bugzilla CVE tracking. The new package updating system, bodhi[0], currently keeps track of all Bugzilla's and CVEs in their own tables. Upon adding an update, the system grabs the bugs and checks them for a 'Security' keyword, and changes the type of the update accordingly. All of this fun stuff can be found in the model[1]. The 'New Update' form currently has an embargo field; can this safely be removed ? I also would like to completely revamp the current update notifications, mainly to include references such as Bugs, CVE's, and maybe security impact and such if available ? luke [0]: https://hosted.fedoraproject.org/projects/bodhi/ (I have yet to migrate the stuff on the UpdatesSystem wiki[2] here yet) [1]: https://hosted.fedoraproject.org/projects/bodhi/browser/bodhi/model.py [2]: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem From dennis at ausil.us Tue Jan 16 20:51:13 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 16 Jan 2007 14:51:13 -0600 Subject: Merging Core and Extras affecting security updates In-Reply-To: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> References: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> Message-ID: <200701161451.13608.dennis@ausil.us> On Tuesday 16 January 2007 08:19, Josh Bressers wrote: > With the current plans to merge Fedora Core and Extras, we need to create a > unified security team to handle the various security flaws that emerge > within the distribution. I've been thinking about this quite a bit, and I > think the goal that needs to be kept in mind is "Keep Fedora users secure". > That goal is fairly vague on purpose. Here's how I'm thinking this can be > done. > > Initially, we're going to ignore embargoed issues. Every time a security > conversation comes up, people start creating overly complex processes to > handle them. Once there is a concrete team and process, this can be > investigated. In the meantime, we'll just deal with issues once they're > public. This seems sane. :) > The biggest missing puzzle piece is the lack of tools. I'm currently > working on some tools to more easily track CVE ids via a clever bugzilla > interface. I have some notes on how I plan to do this elsewhere. I can > post them at a later date if anyone is interested. The bigger tool I'm > looking for is the package release tool. It's likely that the security > team will want to view the text of all security updates and edit it if > needed. I've mailed lmacken requesting this ability, he has informed me > that the functionality is there. I'm of the impression that as long as the > team has the right tools, we can operate very efficiently and handle the > current inflow of issues. What would be nice i Think is a tool that puts cve's with packages even before bugzilla tickets are filed. this would need to tie into the package database under development and the cve database. So we could see what CVE's are out there for what packages that we have and bugzilla tickets filed and would ignore CVE's for things we don't package. I wonder if we should have monthly meetings. at least while a framework is being developed. how exactly is security handled inside Red Hat. Can we use existing framework's tools? I really hope we get some of Red Hat's security team involved in Fedora. -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From bressers at redhat.com Tue Jan 16 21:50:25 2007 From: bressers at redhat.com (Josh Bressers) Date: Tue, 16 Jan 2007 16:50:25 -0500 Subject: Merging Core and Extras affecting security updates In-Reply-To: <200701161451.13608.dennis@ausil.us> References: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> <200701161451.13608.dennis@ausil.us> Message-ID: <200701162150.l0GLoPEd022954@devserv.devel.redhat.com> > > > The biggest missing puzzle piece is the lack of tools. I'm currently > > working on some tools to more easily track CVE ids via a clever bugzilla > > interface. I have some notes on how I plan to do this elsewhere. I can > > post them at a later date if anyone is interested. The bigger tool I'm > > looking for is the package release tool. It's likely that the security > > team will want to view the text of all security updates and edit it if > > needed. I've mailed lmacken requesting this ability, he has informed me > > that the functionality is there. I'm of the impression that as long as the > > team has the right tools, we can operate very efficiently and handle the > > current inflow of issues. > > What would be nice i Think is a tool that puts cve's with packages even before > bugzilla tickets are filed. this would need to tie into the package > database under development and the cve database. So we could see what CVE's > are out there for what packages that we have and bugzilla tickets filed and > would ignore CVE's for things we don't package. I would love to see something like this, but sadly there isn't a nice automated way to match a CVE id to a given package. I'd gladly hear ideas on how to do this. > > I wonder if we should have monthly meetings. at least while a framework is > being developed. > > how exactly is security handled inside Red Hat. Can we use existing > framework's tools? I'm rather anti meeting as they usually just end up creating an overly complex and mostly unusable process. I'd much rather see us make things up as we go along to see what works and what doesn't, and keep the things that work. As for security inside Red Hat, it's a rather manual effort. We track things via a CVS repository, which doesn't really scale very well. Our biggest advantage is the rather loose process we follow. The team is nimble since it's not encumbered by an overly complex process. We can easily find the people we need for any given tasks, which makes our lives much easier during crunch time. The fabled tools I speak of will also probably be used inside Red Hat as well given the overlap that will exist. My challenge now it to find some time to start working on them :) -- JB From mjc at redhat.com Tue Jan 16 22:01:11 2007 From: mjc at redhat.com (Mark J Cox) Date: Tue, 16 Jan 2007 22:01:11 +0000 (GMT) Subject: Merging Core and Extras affecting security updates In-Reply-To: <200701162150.l0GLoPEd022954@devserv.devel.redhat.com> References: <200701161419.l0GEJ7BN020824@devserv.devel.redhat.com> <200701161451.13608.dennis@ausil.us> <200701162150.l0GLoPEd022954@devserv.devel.redhat.com> Message-ID: > I would love to see something like this, but sadly there isn't a nice > automated way to match a CVE id to a given package. I'd gladly hear ideas > on how to do this. NVD try to do this when they create their entries based on CVE (usually they manage this before the CVE site gets updated, but after the CVENEW mails come out). They map each vuln to a product dictionary which we could map to package name, but it'll miss those cases where a vulnerability gets reported for something that affects multiple products (like some flaw being labelled as an Apple flaw when in fact it's in xpdf), or where things affect multiple products (a xpdf issue affects many open source projects). example from http://nvd.nist.gov/download/nvdcve-recent.xml Mark From bugzilla at redhat.com Wed Jan 17 21:31:46 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 17 Jan 2007 16:31:46 -0500 Subject: [Bug 223101] New: CVE-2007-0{106, 107, 109, 262}: Wordpress < 2.0.7 multiple vulnerabilities Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223101 Summary: CVE-2007-0{106,107,109,262}: Wordpress < 2.0.7 multiple vulnerabilities Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: wordpress AssignedTo: jwb at redhat.com ReportedBy: ville.skytta at iki.fi QAContact: extras-qa at fedoraproject.org CC: fedora-security-list at redhat.com http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0106 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0107 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0109 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0262 FE5+ apparently affected. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Jan 17 23:22:15 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 17 Jan 2007 18:22:15 -0500 Subject: [Bug 212699] CVE-2006-5602: xsupplicant < 1.2.6 memory leaks In-Reply-To: Message-ID: <200701172322.l0HNMFVs002116@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-5602: xsupplicant < 1.2.6 memory leaks https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212699 Christian.Iseli at licr.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |Christian.Iseli at licr.org ------- Additional Comments From Christian.Iseli at licr.org 2007-01-17 18:22 EST ------- FC3 and FC4 have now been EOL'd. Please check the ticket against a current Fedora release, and either adjust the release number, or close it if appropriate. Thanks. Your friendly BZ janitor :-) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Jan 17 23:27:17 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 17 Jan 2007 18:27:17 -0500 Subject: [Bug 212699] CVE-2006-5602: xsupplicant < 1.2.6 memory leaks In-Reply-To: Message-ID: <200701172327.l0HNRHdh002990@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-5602: xsupplicant < 1.2.6 memory leaks https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212699 tcallawa at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |CLOSED Resolution| |WONTFIX ------- Additional Comments From tcallawa at redhat.com 2007-01-17 18:27 EST ------- This was only against FC-3. Anyone worried about this bug should upgrade to at least FC-4. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Jan 20 10:34:38 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 20 Jan 2007 05:34:38 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200701201034.l0KAYcju015804@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221694 imlinux at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From imlinux at gmail.com 2007-01-20 05:34 EST ------- 2.9.2 is out. Its built and should be on the mirrors soon. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Jan 20 11:03:06 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 20 Jan 2007 06:03:06 -0500 Subject: [Bug 221694] CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure In-Reply-To: Message-ID: <200701201103.l0KB36nk018309@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221694 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |NEW Keywords| |Reopened Resolution|NEXTRELEASE | ------- Additional Comments From ville.skytta at iki.fi 2007-01-20 06:03 EST ------- It doesn't look like 2.9.2 fixes this though. The demo server at http://pma.cihar.com/STABLE/ runs 2.9.2, but directly requesting http://pma.cihar.com/STABLE/themes/darkblue_orange/layout.inc.php after logging in reveals a path: "Fatal error: Call to a member function getImgPath() on a non-object in /srv/http/pma.cihar.com/STABLE/themes/darkblue_orange/layout.inc.php" -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Jan 20 11:43:19 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 20 Jan 2007 06:43:19 -0500 Subject: [Bug 222410] CVE-2006-6799: Remote execution vulnerability in cacti. In-Reply-To: Message-ID: <200701201143.l0KBhJYT020146@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-6799: Remote execution vulnerability in cacti. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222410 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Remote execution |CVE-2006-6799: Remote |vulnerability in cacti. |execution vulnerability in | |cacti. ------- Additional Comments From ville.skytta at iki.fi 2007-01-20 06:43 EST ------- For reference, this is CVE-2006-6799 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Jan 20 11:48:57 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 20 Jan 2007 06:48:57 -0500 Subject: [Bug 221958] CVE-2007-0177: Security vulnerability in MediaWiki In-Reply-To: Message-ID: <200701201148.l0KBmvM5020251@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0177: Security vulnerability in MediaWiki https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221958 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Security vulnerability in |CVE-2007-0177: Security |MediaWiki |vulnerability in MediaWiki ------- Additional Comments From ville.skytta at iki.fi 2007-01-20 06:48 EST ------- For reference, this is CVE-2007-0177 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From peak at argo.troja.mff.cuni.cz Sun Jan 21 11:49:36 2007 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Sun, 21 Jan 2007 12:49:36 +0100 (CET) Subject: Merging Core and Extras affecting security updates In-Reply-To: Message-ID: <20070121110252.932.0@paddy.troja.mff.cuni.cz> On Tue, 16 Jan 2007, Josh Bressers wrote: > Initially, we're going to ignore embargoed issues. Every time a security > conversation comes up, people start creating overly complex processes to > handle them. Once there is a concrete team and process, this can be > investigated. In the meantime, we'll just deal with issues once they're > public. The process is quite straightforward imho: 1. Data acquisition - keep track of vulnerabilities - CVE (a good start but it should not be the only source of data) - vulnerability databases (Bugtraq, OSVDB, Secunia...) - mailing lists (Bugtraq, Full-disclosure, Vendor-sec...) - other distros (they might have caught something we missed) - Oval? - weed out bogus reports (false reports, issues for MS Windows...) - merge duplicate reports - update existing reports when needed (exploit availability...) 2. Triage - assess new and updated reports - eliminate irrelevant reports (package not included in distro...) - assign score to relevant reports (see below) - reassess reports considered irrelevant when they become relevant (new package added to distro...) - prioritize reports according to their score 3. Remediation - select a report/issue to work on - find or develop patches - check whether the patches fix the vulnerabilities - deploy fixed packages Embargoed (i.e. secret) issues can be implemented quite easily by "polyinstantiation" of these three steps. An interesting thing is that step 1 and a large part of step 2 do not depend on the choice of distro. Moreover, step 1 alone generates "just another vulnerability database". This provides an opportunity for mutually beneficial cooperation with other subjects (other distros, OSVDB...). > Based on that idea, I think it's important to fix things in a > prioritized manner. The way I see this is that it makes more sense to > invest extra time working on getting a Firefox critical update out > before say a minor lha temporary file flaw. This sounds like a task for CVSS: a Firefox critical update will get a high score due to its the remote attack vector, high target distribution, and last but not least partial (or higher) integrity and confidentiality impact (assuming it allows arbitrary code execution) while a minor lha temporary file flaw will get a much lower score due its local attack vector, low target distribution (well, it is probably installed on many systems but most of the time, it is a dead harmless bag of bits because no one is using it), and lower impact (partial integrity impact, no confidentiality impact). The availability of exploits can be taken into account as well. On the other hand, it is quite easy to get an absurd CVSS score if input metrics are set sloppily (as demonstrated by many examples at NVD). Some experience (or guidance) and good judgement is needed. > The biggest missing puzzle piece is the lack of tools. I'm currently > working on some tools to more easily track CVE ids via a clever bugzilla > interface. Bugzilla may be fine for the remediation step (see above). But I do not feel it is (in its standard form) the right tool for steps one and two. It's just too clumsy. Its search dialog is as complex as the space shuttle dashboard and something as simple as checking whether a report for a certain CVE has already been filed needs a lot of work. I am probably biased, inexperienced, or even stupid (*). YMMV. (*) But the sheer amount of duplicate reports in every Bz database suggests I am not alone. ;) On Tue, 16 Jan 2007, Mark J Cox wrote: > They map each vuln to a product dictionary which we could map to package > name, but it'll miss those cases where a vulnerability gets reported for > something that affects multiple products (like some flaw being labelled > as an Apple flaw when in fact it's in xpdf), or where things affect > multiple products (a xpdf issue affects many open source projects). It might be possible to search the source (*) code of all available packages (maybe even packages not included in the distro) for duplicate or similar pieces code and find out whether a bug in package A affects package B because B uses some code from A (or vice versa). (*) Statically linked libraries from other packages are not addressed by this approach but they can be caught by other means. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From bugzilla at redhat.com Mon Jan 22 02:05:50 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 21 Jan 2007 21:05:50 -0500 Subject: [Bug 194511] CVE-2006-2894 arbitrary file read vulnerability In-Reply-To: Message-ID: <200701220205.l0M25oBW017471@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-2894 arbitrary file read vulnerability https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194511 ajschult at verizon.net changed: What |Removed |Added ---------------------------------------------------------------------------- External Bug| |http://bugzilla.mozilla.org/ Reference| |show_bug.cgi?id=258875 ------- Additional Comments From ajschult at verizon.net 2007-01-21 21:05 EST ------- A fix for this is in Mozilla trunk (SeaMonkey 1.5) in bug 258875, but never made it to the 1.8 branch -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From mjc at redhat.com Mon Jan 22 10:15:51 2007 From: mjc at redhat.com (Mark J Cox) Date: Mon, 22 Jan 2007 10:15:51 +0000 (GMT) Subject: Merging Core and Extras affecting security updates In-Reply-To: <20070121110252.932.0@paddy.troja.mff.cuni.cz> References: <20070121110252.932.0@paddy.troja.mff.cuni.cz> Message-ID: > 1. Data acquisition > - keep track of vulnerabilities > - CVE (a good start but it should not be the only source of data) > - vulnerability databases (Bugtraq, OSVDB, Secunia...) > - mailing lists (Bugtraq, Full-disclosure, Vendor-sec...) > - other distros (they might have caught something we missed) > - Oval? > - weed out bogus reports (false reports, issues for MS Windows...) > - merge duplicate reports > - update existing reports when needed (exploit availability...) That's a good summary of the process the Red Hat security response team currently follow -- with the addition that when we discover something by tracking that doesn't have a CVE we ensure that it gets a CVE name assigned to it. Therefore the CVE list can be used as a definitive list for anything that may affect Red Hat or Fedora (indeed for Fedora tracking right now we base it off the CVENEW mails) (OVAL just provides a way of expressing how to detect the presence of some particular CVE named flaw) > This sounds like a task for CVSS: I don't believe CVSS really works for open source software (or indeed any software that is shipped by multiple vendors). Even assigning a Base score is tricky to do. Is that flaw in ImageMagick where a buffer overflow could be triggered if you open a malicious file you were given "remote" or "local"? The attacker is remote. If you argue it's "local" then how about a flaw in something like xpdf? is that also local? NVD say these are "user complicit" and marked as local. But doesn't it depend on if xpdf is associated with pdf files in your web browser? It's no user complicit if all you need to do is visit some malicious website. How about if the flaw is in some widely used library like libpng; won't the local/remote rating depend on exactly what software is using that library in what ways? Then you have to take into account the version of Fedora Core or RHEL as each has different security technologies. Some double-free flaws can lead to a complete loss of integrity on some systems, but no loss of integrity but partial availability on others. We do currently assign severities though, but we use a simple 4-level scale with defined actions and goals for dealing with each level (for example we aim to get a fix out for a critical vulnerability within a day of it being public so we have to start paging people). Thanks, Mark -- Mark J Cox / Red Hat Security Response Team From smooge at gmail.com Sat Jan 27 01:20:33 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 26 Jan 2007 18:20:33 -0700 Subject: Security fix to Bind-9.2.8/Bind-9.3.4 Message-ID: <80d7e4090701261720n150e322bi2cc1be965b6ec0db@mail.gmail.com> The 9.3.4 affects FCL-5,6 BIND 9.3.4 is now available. BIND 9.3.4 is a security release for BIND 9.3. BIND 9.3.4 contains security fixes: 2126. [security] Serialise validation of type ANY responses. [RT #16555] 2124. [security] It was possible to dereference a freed fetch context. [RT #16584] 2089. [security] Raise the minimum safe OpenSSL versions to OpenSSL 0.9.7l and OpenSSL 0.9.8d. Versions prior to these have known security flaws which are (potentially) exploitable in named. [RT #16391] 2088. [security] Change the default RSA exponent from 3 to 65537. [RT #16391] 2066. [security] Handle SIG queries gracefully. [RT #16300] 1941. [bug] ncache_adderesult() should set eresult even if no rdataset is passed to it. [RT #15642] If you are running a BIND 9.3.x or BIND 9.4.x version without these changes you are advised to upgrade as soon as possible to one of BIND 9.3.4 or BIND 9.4.0rc2. BIND 9.3.4 can be downloaded from ftp://ftp.isc.org/isc/bind9/9.3.4/bind-9.3.4.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.3.4/bind-9.3.4.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.3.4/bind-9.3.4.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.3.4/bind-9.3.4.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at . A binary kit for Windows 2000, Windows XP and Windows 2003 is at ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.zip ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.debug.zip The PGP signature of the binary kit for Windows 2000, Windows XP and Windows 2003 is at ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.zip.asc ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.3.4/BIND9.3.4.debug.zip.sha512.asc Note: There is no Windows NT 4.0 binary kit for BIND 9.3.4. Windows NT 4.0 is still supported in source form. A list of changes made since 9.3.0 follows. For earlier changes, see the file CHANGES in the distribution. -------- --- 9.3.4 released --- 2126. [security] Serialise validation of type ANY responses. [RT #16555] 2124. [security] It was possible to dereference a freed fetch context. [RT #16584] -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From peak at argo.troja.mff.cuni.cz Sun Jan 28 14:35:16 2007 From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Sun, 28 Jan 2007 15:35:16 +0100 (CET) Subject: Merging Core and Extras affecting security updates In-Reply-To: Message-ID: <20070128000845.932.0@paddy.troja.mff.cuni.cz> On Mon, 22 Jan 2007, Mark J Cox wrote: > That's a good summary of the process the Red Hat security response team > currently follow -- It was not me who broke into your offices and stole your papers. ;) > with the addition that when we discover something by tracking that > doesn't have a CVE we ensure that it gets a CVE name assigned to it. > Therefore the CVE list can be used as a definitive list for anything > that may affect Red Hat or Fedora (indeed for Fedora tracking right now > we base it off the CVENEW mails) How much time does it take to get a new CVE number? Hours? Days? How do you handle duplicate CVEs? (I don't know how often it happens nowadays but they had some duplicate entries in the past.) > (OVAL just provides a way of expressing how to detect the presence of some > particular CVE named flaw) I know. I occurred to me a corpus of OVAL files (or anything similar in a machine-readable form) might be used for automatic checks whether the corresponding issues are relevant and (after the fact) whether they have been handled properly. > > This sounds like a task for CVSS: > I don't believe CVSS really works for open source software (or indeed any > software that is shipped by multiple vendors). It is impossible to assign a fixed universal severity rating to a vulnerability in a software package used in more than one environment and one configuration (there are many examples of software being secure in one configuration and providing "instant remote root" in another configuration). > Even assigning a Base score is tricky to do. Is that flaw in > ImageMagick where a buffer overflow could be triggered if you open a > malicious file you were given "remote" or "local"? The attacker is > remote. If you argue it's "local" then how about a flaw in something > like xpdf? is that also local? Most vulnerabilities exploitable by evil files are "remote" because you do not need a local account to exploit them. But the attacker cannot initiate the execution of vulnerable code at will and it should be expressed as "high access complexity" in CVSS terminology. > NVD say these are "user complicit" and marked as local. I think they got it wrong. See above. > But doesn't it depend on if xpdf is associated with pdf files in your > web browser? It's no user complicit if all you need to do is visit some > malicious website. Well, it is "user complicit" as long as the attacker needs to convince a local user to do something (to visit a website, to download and view a file, to view an email attachment...). On the other hand I find the choice of words ("complicit") misleading when it is used to describe attacks when the user expects the operation (visiting a website etc.) not to cause any harm. > How about if the flaw is in some widely used library like libpng; won't > the local/remote rating depend on exactly what software is using that > library in what ways? Sure. In fact anything can depend on the way the library is used: the same vulnerability can be irrelevant in the context of one program (using the library to process good trusted data only, e.g. the files shipped with the program), a minor problem in the context of another program (the library is used to process trusted data only but some inputs can trigger the bug, e.g. outputs from some other program, and it makes the program using the library unreliable), or a major hole in the context of yet another program (accepting untrusted data from anyone in the Internet, e.g. files uploaded via a publicly accessible web form, and feeding them to the library). I myself would compute some kind of aggregate score over all reasonable uses of the library. The exact meaning of "reasonable" and "not reasonable" is fuzzy but I hope a little bit of common sense will help in most cases. E.g. feeding an untrusted image to libpng is reasonable, feeding an untrusted .gtkrc to libgtk is not reasonable (and it is the program using the library that needs fixing in the first place). An important reality check (in both directions): all existing uses in the distro should be reasonable. > Then you have to take into account the version of Fedora Core or RHEL as > each has different security technologies. Some double-free flaws can lead > to a complete loss of integrity on some systems, but no loss of integrity > but partial availability on others. A vulnerable program running on a system with the double-free protection and the same program running on a system without it are two different pieces of software from this point of view. We are dealing with a certain kind of a staged attack here: the first stage of the attack is to exploit a vulnerability in the program itself violate the integrity of its communication with the memory allocator, and the second stage is to subvert the allocator through this channel. It might be possible to rate such a program with an expression depending on variables describing the rest of the system (e.g. its sensitivity to double-frees), and compute multiple final results for every environment being taken into account. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation." From lkundrak at redhat.com Mon Jan 29 08:52:03 2007 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 29 Jan 2007 09:52:03 +0100 Subject: Security fix to Bind-9.2.8/Bind-9.3.4 In-Reply-To: <80d7e4090701261720n150e322bi2cc1be965b6ec0db@mail.gmail.com> References: <80d7e4090701261720n150e322bi2cc1be965b6ec0db@mail.gmail.com> Message-ID: <1170060723.3386.103.camel@pluto> Hi Stephen, On Pi, 2007-01-26 at 18:20 -0700, Stephen John Smoogen wrote: > --- 9.3.4 released --- > > 2126. [security] Serialise validation of type ANY responses. [RT #16555] > > 2124. [security] It was possible to dereference a freed fetch > context. [RT #16584] There is a bug open in bugzilla for this update. See #224443 [1]. Unfortunately, there is too little information to find out why is update 2126 a security issue, and why did not ISC issue an advisory for it. *Sigh* ISC is not good at providing with usable informaation. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224443 Regards, -- Lubomir Kundrak (Red Hat Security Response Team) From deisenst at gtw.net Mon Jan 29 09:40:59 2007 From: deisenst at gtw.net (David Eisenstein) Date: Mon, 29 Jan 2007 03:40:59 -0600 Subject: Merging Core and Extras affecting security updates In-Reply-To: <20070121110252.932.0@paddy.troja.mff.cuni.cz> References: <20070121110252.932.0@paddy.troja.mff.cuni.cz> Message-ID: <45BDC12B.3040000@gtw.net> Pavel Kankovsky wrote: > On Tue, 16 Jan 2007, Josh Bressers wrote: > >> Initially, we're going to ignore embargoed issues. Every time a security >> conversation comes up, people start creating overly complex processes to >> handle them. Once there is a concrete team and process, this can be >> investigated. In the meantime, we'll just deal with issues once they're >> public. > > The process is quite straightforward imho: > > 1. Data acquisition > - keep track of vulnerabilities > - CVE (a good start but it should not be the only source of data) > - vulnerability databases (Bugtraq, OSVDB, Secunia...) > - mailing lists (Bugtraq, Full-disclosure, Vendor-sec...) > - other distros (they might have caught something we missed) > - Oval? > - weed out bogus reports (false reports, issues for MS Windows...) > - merge duplicate reports > - update existing reports when needed (exploit availability...) > > 2. Triage > - assess new and updated reports > - eliminate irrelevant reports (package not included in distro...) > - assign score to relevant reports (see below) > - reassess reports considered irrelevant when they become relevant > (new package added to distro...) > - prioritize reports according to their score > > 3. Remediation > - select a report/issue to work on > - find or develop patches > - check whether the patches fix the vulnerabilities > - deploy fixed packages > It has been awhile since I have done much here. Got lots of questions. My concern here is how does someone new to this process come about fairly easily and quickly knowing the status of any given vulnerability? And how does someone know where to pitch in? How many security issues might we have that could be open at the same time? In order for any kind of orderly work to get done, a diverse and geographically-spread team would need to know what area of work needs the most work, and how to find out what issues are ones that they can work on, plus some way of flagging issues so someone else five minutes later signing on the the system to do some work won't start working on the very same thing (avoiding duplication of effort, if possible). If we have, for example, people identifying issues -- how do we make it so a team of three identifiers don't identify the same issue three times? (Or is that not a problem?) Do we have a quick 'n dirty way of telling Joe Blow, a fellow scanning the Internet for vulnerabilities, that CVE-2007-yyyy is already in the database and needs triage (which I assume means "prioritization" = do we worry about this flaw today, tomorrow, or next Wednesday)? Or of telling John Q. Public that CVE-2007-xxxx has been triaged and now needs patches to be found and published somewhere for Jim-Billy Bobb to go into the package CVS and build a new package? How do we know when who does what and who has access to which information where to get work done? And how does the QA process fit in with all of this? Er, do we have some kind of package QA process for security vulnerabilities? Would community members be welcome to pitch in on this if there is a QA process in place? A good start might be a breakdown for those of us here who don't know -- who *now* does what for Core packages and for extras packages? What does a security issue look like walked through the entire process, from identifying the vulnerability to the release of a fixed package? What does the process *now* look like and how do Red Hat people envision opening up the process to let others in? How is information going to be shared outside of the Security Response Team so it will be able to be efficiently known about by your community contributors (excluding embargoed issues, of course, for now)? And are embargoed issues for former core packages now going to be ignored until the embargo is lifted, or are they going to be able to be worked on by trusted individuals inside Red Hat while embargoed, just as they are now? If today I wanted to start being a security bug watcher, where do I report them? Bugzilla? Or is there a person or a group of people that already does this as a paid job inside of Red Hat? Does the Fedora Security Team maintain a database (or "flat file") stored out in a Fedora CVS server somewhere that indicates status of any given CVE issue? If it is there, is the "how to use it" documented anywhere? Is manipulating this flat file the best way to get security bugs "into the system" for review? If there are things that people know tacitly how to do, I would be more than happy to help document current processes. Is there any estimate of an ideal level of manpower doing things? And what levels of expertise are needed for each of the security tasks, especially when dealing with former Core packages by community members? Thanks. -David From smooge at gmail.com Mon Jan 29 15:58:53 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 29 Jan 2007 08:58:53 -0700 Subject: Security fix to Bind-9.2.8/Bind-9.3.4 In-Reply-To: <1170060723.3386.103.camel@pluto> References: <80d7e4090701261720n150e322bi2cc1be965b6ec0db@mail.gmail.com> <1170060723.3386.103.camel@pluto> Message-ID: <80d7e4090701290758x601fd7a2q6d1d8e4141900e64@mail.gmail.com> On 1/29/07, Lubomir Kundrak wrote: > Hi Stephen, > > On Pi, 2007-01-26 at 18:20 -0700, Stephen John Smoogen wrote: > > --- 9.3.4 released --- > > > > 2126. [security] Serialise validation of type ANY responses. [RT #16555] > > > > 2124. [security] It was possible to dereference a freed fetch > > context. [RT #16584] > > There is a bug open in bugzilla for this update. See #224443 [1]. > Unfortunately, there is too little information to find out why is update > 2126 a security issue, and why did not ISC issue an advisory for it. > *Sigh* ISC is not good at providing with usable informaation. > Yeah.. the story I have heard multiple times is, people pay ISC for support then get better answers on the newsgroups from ISC people. There was some discussion on ISC this weekend about it with CVE numbers which probably tell even less :). http://isc.sans.org/diary.html?storyid=2129 > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224443 > > Regards, > -- > Lubomir Kundrak (Red Hat Security Response Team) > > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From bressers at redhat.com Mon Jan 29 16:36:21 2007 From: bressers at redhat.com (Josh Bressers) Date: Mon, 29 Jan 2007 11:36:21 -0500 Subject: Merging Core and Extras affecting security updates In-Reply-To: <45BDC12B.3040000@gtw.net> References: <20070121110252.932.0@paddy.troja.mff.cuni.cz> <45BDC12B.3040000@gtw.net> Message-ID: <200701291636.l0TGaLwM011263@devserv.devel.redhat.com> > > It has been awhile since I have done much here. Got lots of questions. Wow, this mail is a lot of questions. I'll do my best to answer the ones I have ideas for. > > My concern here is how does someone new to this process come about > fairly easily and quickly knowing the status of any given vulnerability? > And how does someone know where to pitch in? We'll have to figure this one out moving forward. I think the best way will be to have an easy to understand and very public task list. A new person could then easily identify orphaned things that need some attention. > > How many security issues might we have that could be open at the same time? I think the answer to this is "as many as there are". Ideally, there won't be any open, but realistically, this number will probably be larger than any of us will want. > > In order for any kind of orderly work to get done, a diverse and > geographically-spread team would need to know what area of work needs > the most work, and how to find out what issues are ones that they can > work on, plus some way of flagging issues so someone else five minutes > later signing on the the system to do some work won't start working on > the very same thing (avoiding duplication of effort, if possible). > > If we have, for example, people identifying issues -- how do we make it > so a team of three identifiers don't identify the same issue three > times? (Or is that not a problem?) Do we have a quick 'n dirty way of > telling Joe Blow, a fellow scanning the Internet for vulnerabilities, > that CVE-2007-yyyy is already in the database and needs triage (which I > assume means "prioritization" = do we worry about this flaw today, > tomorrow, or next Wednesday)? Or of telling John Q. Public that > CVE-2007-xxxx has been triaged and now needs patches to be found and > published somewhere for Jim-Billy Bobb to go into the package CVS and > build a new package? How do we know when who does what and who has > access to which information where to get work done? This is where some tools can come in handy. I'm still working on getting things in order, but here is the basics of what I'm thinking. There is a queue in bugzilla called "Security Response". The plan is to have one bug for each CVE id we have any sort of interest in. This would then be a place we can add comments regarding an issue and track what's affected. We will then have product bugs for everything that needs one (Fedora, RHEL, anything else that needs a bug). The product bugs will then be child bugs of our CVE bug. This means that in order to determine what a given CVE id affects, you'll have to look at the child bugs for each CVE bug. This would be silly for a person to do, which is why we'll have a pretty web page with it listed for us. I envision each CVE bug having an owner. The tasks that aren't being worked on will be orphaned, and obviously up for grabs. Here is a bad ASCII picture for those of you confused by my gibberish. CVE-XXXX-0001 <-- parent bug describing a flaw | + Bug 12345 <-- filed against xpdf in Fedora | + Bug 12346 <-- filed against cups in Fedora | + Bug 12348 <-- filed against xpdf in RHEL So obviously we'd have a tool that would make this very obvious as trolling around bugzilla wouldn't be. The biggest advantage to this is that since the various package developers use bugzilla for tracking their tasks, our issue database is also the same place the developers look for what needs to be fixed. The only way this can work is with some tools. I'm currently working on some python libraries to parse all this nicely. Once I have a basic working prototype, I'll put the code in the fedora CVS then other can lend a hand. > > And how does the QA process fit in with all of this? Er, do we have > some kind of package QA process for security vulnerabilities? Would > community members be welcome to pitch in on this if there is a QA > process in place? Right now we let the Fedora developers handle the package updates, which also involve some amount of QA. I think we'll leave the QA bits up to the developer and any QA groups that form. I think we should keep a somewhat narrow focus on security updates. It's easy to get sidetracked and this is a path that would likely have no end for this group. > > A good start might be a breakdown for those of us here who don't know -- > who *now* does what for Core packages and for extras packages? What > does a security issue look like walked through the entire process, from > identifying the vulnerability to the release of a fixed package? What > does the process *now* look like and how do Red Hat people envision > opening up the process to let others in? How is information going to be > shared outside of the Security Response Team so it will be able to be > efficiently known about by your community contributors (excluding > embargoed issues, of course, for now)? And are embargoed issues for > former core packages now going to be ignored until the embargo is > lifted, or are they going to be able to be worked on by trusted > individuals inside Red Hat while embargoed, just as they are now? I'd start by taking a look at this message: https://www.redhat.com/archives/fedora-security-list/2007-January/msg00034.html It's a pretty good description of our current process. I'm not really interested in letting people into the current Red Hat process. I'm interested in letting Red Hat into the Fedora process. Since we don't really have a Fedora process, we get to make it up :) > > If today I wanted to start being a security bug watcher, where do I > report them? Bugzilla? Or is there a person or a group of people that > already does this as a paid job inside of Red Hat? I don't think I understand this question. Right now all security bugs should be in bugzilla yes. There are people inside Red Hat, the Red Hat Security Response Team that look for and deal with security bugs, but the focus of this team is on Fedora Core and Red Hat Enterprise Linux. Once Fedora 7 is out, I foresee some members of the team joining the Fedora Security Response Team. There will be some task overlap, so I think it just makes sense. > > Does the Fedora Security Team maintain a database (or "flat file") > stored out in a Fedora CVS server somewhere that indicates status of any > given CVE issue? If it is there, is the "how to use it" documented > anywhere? Is manipulating this flat file the best way to get security > bugs "into the system" for review? See my above comments about tools. > > If there are things that people know tacitly how to do, I would be more > than happy to help document current processes. We should probably start some wiki pages to capture all this information. I honestly don't even remember what's all on the wiki about security things. I wouldn't complain if someone could take the lead on handling the documentation of questions and answers along with tool and process plans. I don't expect to have time to look into this myself until I have my prototype python library done. > > Is there any estimate of an ideal level of manpower doing things? And > what levels of expertise are needed for each of the security tasks, > especially when dealing with former Core packages by community members? I think the ideal level of manpower is as many people as are willing to help :) There isn't really a minimal competency level for this stuff. Obviously some things require a certain level of expertise, but as those issues arise, we'll have people around to handle those. I'm a believer in the idea that everyone is at the bottom of the ladder at some point and time, so if you're willing learn, we should be willing to teach. -- JB From Christian.Iseli at licr.org Tue Jan 30 19:34:31 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 30 Jan 2007 20:34:31 +0100 Subject: clamav BZ tickets Message-ID: <20070130203431.45630e7e@ludwig-alpha.unil.ch> Hi folks, Could anyone from the security team have a look at BZ tickets 192266 and 192407 ? Not sure if these are real serious issues, but I'd feel better if someone versed in virus things could have a look... Thanks, C From bugzilla at redhat.com Tue Jan 30 19:48:56 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 30 Jan 2007 14:48:56 -0500 Subject: [Bug 225469] New: wordpress < 2.1 multiple vulnerabilities Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225469 Summary: wordpress < 2.1 multiple vulnerabilities Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: wordpress AssignedTo: jwb at redhat.com ReportedBy: ville.skytta at iki.fi QAContact: extras-qa at fedoraproject.org CC: fedora-security-list at redhat.com Multiple (low CVSS score) vulnerabilities reported against Wordpress < 2.1: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0539 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0540 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0541 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Jan 31 19:08:11 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 Jan 2007 14:08:11 -0500 Subject: [Bug 225919] New: CVE-2007-0619: chmlib < 0.3.9 arbitrary code execution Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225919 Summary: CVE-2007-0619: chmlib < 0.3.9 arbitrary code execution Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: chmlib AssignedTo: lemenkov at gmail.com ReportedBy: ville.skytta at iki.fi QAContact: extras-qa at fedoraproject.org CC: fedora-security-list at redhat.com http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0619 "chmlib before 0.39 allows user-assisted remote attackers to execute arbitrary code via a crafted page block length in a CHM file, which triggers memory corruption." FC5+ seemingly affected. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Jan 31 22:28:01 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 Jan 2007 17:28:01 -0500 Subject: [Bug 221023] CVE-2006-6808: wordpress 2.0.5 XSS vulnerability In-Reply-To: Message-ID: <200701312228.l0VMS1Za024324@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2006-6808: wordpress 2.0.5 XSS vulnerability https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221023 jwb at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Jan 31 22:29:27 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 Jan 2007 17:29:27 -0500 Subject: [Bug 223101] CVE-2007-0{106, 107, 109, 262}: Wordpress < 2.0.7 multiple vulnerabilities In-Reply-To: Message-ID: <200701312229.l0VMTRtb024580@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: CVE-2007-0{106,107,109,262}: Wordpress < 2.0.7 multiple vulnerabilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223101 jwb at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Jan 31 22:31:02 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 31 Jan 2007 17:31:02 -0500 Subject: [Bug 225469] wordpress < 2.1 multiple vulnerabilities In-Reply-To: Message-ID: <200701312231.l0VMV236024823@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: wordpress < 2.1 multiple vulnerabilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225469 jwb at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.