[Bug 192830] New: CVE-2006-2453 Additional dia format string flaws
by Red Hat Bugzilla
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=192830
Summary: CVE-2006-2453 Additional dia format string flaws
Product: Fedora Extras
Version: fc5
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: dia
AssignedTo: j.w.r.degoede(a)hhs.nl
ReportedBy: bressers(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: extras-qa(a)fedoraproject.org,fedora-security-
list(a)redhat.com
A number of additional format string issues were discovered by Hans de Goede and
has been assigned the CVE id CVE-2006-2453.
The fix is attachment 129852
--
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.
16 years
[Bug 209167] New: seamonkey < 1.0.5 multiple vulnerabilities
by Red Hat Bugzilla
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=209167
Summary: seamonkey < 1.0.5 multiple vulnerabilities
Product: Fedora Extras
Version: fc4
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: seamonkey
AssignedTo: kengert(a)redhat.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
seamonkey 1.0.4 in FE4 is probably affected by CVE-2006-4253, CVE-2006-4340,
CVE-2006-4565, CVE-2006-4566, CVE-2006-4568, CVE-2006-4570 and CVE-2006-4571.
According to upstream, these are fixed in 1.0.5 (FE5+)
--
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.
16 years, 5 months
[Bug 216706] New: CVE-2006-5793 libpng, libpng10 DoS
by Red Hat Bugzilla
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(a)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.
16 years, 7 months
Merging Core and Extras affecting security updates
by Josh Bressers
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
16 years, 7 months