security January 2007

security@lists.fedoraproject.org

12 participants
32 discussions

Start a nNew thread

[Bug 221694] New: CVE-2007-0095: phpMyAdmin <= 2.9.1.1 information disclosure
by Red Hat Bugzilla 10 Dec '07

10 Dec '07

1 13

[Bug 192830] New: CVE-2006-2453 Additional dia format string flaws
by Red Hat Bugzilla 30 Aug '07

30 Aug '07

1 13

[Bug 215136] New: CVE-2006-5864: gv <= 3.6.2 stack-based buffer overflow
by Red Hat Bugzilla 30 Aug '07

30 Aug '07

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=215136 Summary: CVE-2006-5864: gv <= 3.6.2 stack-based buffer overflow Product: Fedora Extras Version: fc6 Platform: All URL: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-5864 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: gv AssignedTo: orion(a)cora.nwra.com ReportedBy: ville.skytta(a)iki.fi QAContact: extras-qa(a)fedoraproject.org CC: extras-qa(a)fedoraproject.org,fedora-security- list(a)redhat.com http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-5864 "Stack-based buffer overflow in the ps_gettext function in ps.c for GNU gv 3.6.2, and possibly earlier versions, allows user-assisted attackers to execute arbitrary code via a PostScript (PS) file with certain headers that contain long comments, as demonstrated using the DocumentMedia header." -- 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.

1 5

[Bug 220041] New: CVE-2006-6625, CVE-2006-6626: moodle XSS vulnerabilities
by Red Hat Bugzilla 15 Apr '07

15 Apr '07

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=220041 Summary: CVE-2006-6625, CVE-2006-6626: moodle XSS vulnerabilities Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: moodle AssignedTo: imlinux(a)gmail.com ReportedBy: ville.skytta(a)iki.fi QAContact: extras-qa(a)fedoraproject.org CC: extras-qa(a)fedoraproject.org,fedora-security- list(a)redhat.com http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6625 Reported against 1.6.1 but an upstream patch which I suppose fixes this is not applied in 1.6.3: http://moodle.cvs.sourceforge.net/moodle/moodle/mod/forum/discuss.php?r1=1.… http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6626 Reported against 1.5, too little information available at the moment to say whether this is an issue with 1.6.3. All FC4+ distro releases are equally affected (or not). -- 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.

1 3

[Bug 209167] New: seamonkey < 1.0.5 multiple vulnerabilities
by Red Hat Bugzilla 10 Apr '07

10 Apr '07

1 13

[Bug 216706] New: CVE-2006-5793 libpng, libpng10 DoS
by Red Hat Bugzilla 12 Feb '07

12 Feb '07

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=216706 Summary: CVE-2006-5793 libpng, libpng10 DoS Product: Fedora Core Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: libpng AssignedTo: tgl(a)redhat.com ReportedBy: ville.skytta(a)iki.fi CC: fedora-security-list@redhat.com,mclasen@redhat.com +++ This bug was initially created as a clone of Bug #215405 +++ Tavis Ormandy told vendor-sec about a OOB memory read flaw in libpng. This flaw is a denial of service flaw. quoting the mail from Tavis: Hello, there's a typo in the sPLT chunk handling code in libpng, potentially resulting in an OOB read. AFAICT, the extent of the vulnerability is denial of service, but would appreciate a second pair of eyes to verify. Around line ~983 of pngset.c, in png_set_sPLT() to->entries =3D (png_sPLT_entryp)png_malloc(png_ptr,=20 from->nentries * png_sizeof(png_sPLT_t)); should be `png_sizeof(png_sPLT_entry)` and the same on this line: png_memcpy(to->entries, from->entries, from->nentries * png_sizeof(png_sPLT_t)); This issue also affects RHEL2.1 and RHEL3 -- Additional comment from bressers(a)redhat.com on 2006-11-14 16:28 EST -- This issue is now public: http://bugs.gentoo.org/show_bug.cgi?id=154380 --- Possibly affected: libpng in FC5, FC6, and devel, and libpng10 in FC5. (libpng10 in Extras has been updated, see bug 216263) -- 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.

3 6

Merging Core and Extras affecting security updates
by Josh Bressers 06 Feb '07

06 Feb '07

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

6 11

[Bug 219938] New: CVE-2006-6563: proftpd < 1.3.1rc1 mod_ctrls buffer overflow
by Red Hat Bugzilla 06 Feb '07

06 Feb '07

1 8

[Bug 214820] New: CVE-2006-5815: proftpd unspecified vulnerability
by Red Hat Bugzilla 05 Feb '07

05 Feb '07

1 24

[Bug 225919] New: CVE-2007-0619: chmlib < 0.3.9 arbitrary code execution
by Red Hat Bugzilla 01 Feb '07

01 Feb '07

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security January 2007