security April 2006

security@lists.fedoraproject.org

21 participants
14 discussions

Fedora Extras Security Response Team
by Josh Bressers 10 May '06

10 May '06

Hello everybody. In case you didn't see, there was a post by Thorsten Leemhuis to the fedora-extras list regarding the creation of a Fedora Extras security response team. The message can be seen here: https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01650.html Here are the people I know have an interest in helping out with the security response team: Hans de Goede Jason L Tibbitts III Dennis Gilmore Jochen Schmitt Ville Skyttä Michael J Knox If you're interested, feel free to chime in. Right now I have a pretty good idea of what's needed to get this project off the ground. We have a mailing list (which would be step one). I need to fix up some CVS space for things like tools and tracking text files. This repository is here: http://cvs.fedora.redhat.com/viewcvs/fedora-security/?root=fedora We will need a package manifest. Basically a file that tells us which packages and versions we're currently shipping in extras. A tool to generate this will also be needed since we'll want to update this file on a regular basis. Given how fast Extras changes I think this will be the easiest way to check if we currently ship package <foo>. An errata template is needed. I'm thinking we should copy the current Fedora Core template for now. We can mangle it as we see fit at a later date. Process needs to be documented on the fedoraproject wiki. Since we don't currently have a process, this is the only thing done :) The most important part of this will be making it easy to specify what we expect of ourselves. I hope to have some time this weekend to clean up the security wiki pages a bit. I think this is enough for now. Questions, Comments? -- JB

9 17

Re: Fedora Extras Security Response Team
by Josh Bressers 28 Apr '06

28 Apr '06

> On Fri, 28 Apr 2006, Josh Bressers wrote: > > > If you're interested, feel free to chime in. > > I'm interested as well > > > We will need a package manifest. Basically a file that tells us which > > packages and versions we're currently shipping in extras. A tool to > > generate this will also be needed since we'll want to update this file on a > > regular basis. Given how fast Extras changes I think this will be the > > easiest way to check if we currently ship package <foo>. > > What's the scope here? Should it cover what's in CVS or what's built and > shipped as a package? I can see pros and cons each way I think it's important to keep an eye out for new things, but also there's no reason to track a deprecated package that also happens to be in CVS. A blend of the two will be needed. > > Also, does it need to be part of the Fedora infrastructure stuff (say, a > script run on the repository every time a package push hits), or can it be > client-side (say, once a day I check out CVS trees for FE, walk them to > see what's in them, check results into fedora-security/package or > whatever) I was thinking that initially we just run a manual client side process from time to time. Eventually I would like to see an automated process that updates a package manifest. -- JB

1 0

Intro...
by Michael J. Knox 28 Apr '06

28 Apr '06

Hey All, Based on Josh Bressers' email to me on devel... I have joined up here to help out with the "Security Response Team / EOL" and to hopefully work on a better way to handle "retired" packages. Michael

1 0

A few questions about cve.mitre.org
by David Eisenstein 24 Apr '06

24 Apr '06

Hi there, There is something I've always wondered... How do CVE items in CVE's database have their status changed? In my time of working with vulnerabilities, I have only seen a few items graduate from Status="Candidate" to Status="..." (is it "Confirmed"?). Another question. How does one submit information or corrections to the cve.mitre.org folks? I've been recently mentoring someone on identifying and reporting vulnerabilities into Bugzilla (or "Vulnerability Tracking"). We were reviewing <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058>. In reviewing it, I noticed that its description, although true, is not the whole truth: "Signal handler race condition in Sendmail 8.13.x before 8.13.6 allows remote attackers to execute arbitrary code by triggering timeouts in a way that causes the setjmp and longjmp function calls to be interrupted and modify unexpected memory locations." Someone reading this summary description (and nothing else) might walk away thinking, "Oh! I run Sendmail 8.11.6, so I am not vulnerable to this issue." Although true that this affects Sendmail 8.13.x before 8.13.x, ac- cording to Bugtraq ID 17192, <http://www.securityfocus.com/bid/17192>, it exists also in Sendmail versions 8.12.x, 8.11.x 8.10(.x), 8.9(.x), and 8.8.8. Which is why Red Hat issued updates for RHEL 2.1 and 3 as well as RHEL 4, and why Legacy issued updates for all distro's we maintain. So I would propose that the CVE people need to change the summary description to say something like: "Signal handler race condition in Sendmail versions 8.8.8 before 8.13.6 allows remote attackers to execute arbitrary code by trig- gering timeouts in a way that causes the setjmp and longjmp func- tion calls to be interrupted and modify unexpected memory locations." Also -- What makes the CVE maintainers notice a given advisory and maybe skip another? The Fedora Legacy advisory FLSA:186277 mentioned in CVE-2006-0058's references is referring to an obsolete advisory, as Legacy had to re-release sendmail with an updated advisory. * The original Legacy advisory for this issue is at <http://www.securityfocus.com/archive/1/archive/1/428656/100/0/threaded> (also at <http://www.securityfocus.com/archive/1/428656/100/0/threaded>) * The updated Legacy advisory is at <http://www.securityfocus.com/archive/1/430308/100/300/threaded> Do we need to renumber the advisory so it will get attention by the CVE folks? Or make a special effort to send mail to the CVE people letting them know that the reference in CVE-2006-0058 needs updating? If so, who do we write? Thanks in advance! Warm regards, David Eisenstein

2 1

Heads up! Firefox & Mozilla
by David Eisenstein 18 Apr '06

18 Apr '06

Hi Folks, Over the (HOLIDAY!) weekend, Mozilla released a new Firefox (1.0.8) fixing a set of critical vulnerabilities. The upstream (mozilla.org) chose *not*, however, to release the Mozilla code for 1.7.13 yet, but I am told that the updated Mozilla will be released officially in the near future. We may, however, be able to get our hands on the sources before then and get it in the pipeline for QA and such. Some of the critical issues (potential remotely exploited code execution) can be mitigated by turning off Javascript, but not all, as there is one issue that I am told that can be triggered by HTML tags. From MFSA 2006-18 <http://www.mozilla.org/security/announce/2006/mfsa2006-18.html>, <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0749>: "A particular sequence of HTML tags that reliably crash Mozilla clients was reported by an anonymous researcher via TippingPoint and the Zero Day Initiative. The crash is due to memory corruption that can be exploited to run arbitary code. "Mozilla mail clients will crash on the tag sequence, but without the ability to run scripts to fill memory with the attack code it may not be possible for an attacker to exploit this crash." These issues affect Mozilla Firefox and Thunderbird 1.x before 1.5 and 1.0.x before 1.0.8, Mozilla Suite before 1.7.13, and SeaMonkey before 1.0, according to CVE-2006-0749. Be careful out there! We'll get these out for Legacy as soon as we can. Regards, David Eisenstein

2 1

[(nowhere)] [BuHa-Security] Stack Based Buffer Overflow Vulnerability in Amaya 9.4 #2
by Jason L Tibbitts III 13 Apr '06

13 Apr '06

This would seem to apply to Extras. What should happen from here? Bugzilla? - J< -- Jason L Tibbitts III - tibbs(a)math.uh.edu - 713/743-3486 - 660PGH - 94 PC800 System Manager: University of Houston Department of Mathematics And with death The knowledge comes It was the life all along We'd been afraid of

3 3

Results of todays LWN security page check
by Hans de Goede 13 Apr '06

13 Apr '06

As every thursday, see: perl-Imager, CVE-2006-0053: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188315 clamav, CVE-2006-1614 CVE-2006-1615 CVE-2006-1630: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188881 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188882 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188883 mplayer, CVE-2006-1502: http://bugzilla.livna.org/show_bug.cgi?id=849 openvpn, CVE-2006-1629: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188050 plone, CVE-2006-1711: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188886 Regards, Hans

3 2

ClamAV
by Dennis Gilmore 07 Apr '06

07 Apr '06

I just reported a security bug for ClamAV in extras it came to me from bug traq while i know its not the be all and end all of finding issues its a place to start. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188286 -- Regards Dennis Gilmore, RHCE Proud Australian

5 10

Results of chekcing todays lwn security page
by Hans de Goede 06 Apr '06

06 Apr '06

2 vulnerabilities in "Extras" found and reported: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188122 http://bugzilla.livna.org/show_bug.cgi?id=889 Also a number in core but I assume those are known: MySQL: logging bypass: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0903 php: insecure data: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1490 samba: clear text password exposure: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1059 Regards, Hans

3 3

Fedora Extras Security Response Team
by Josh Bressers 06 Apr '06

06 Apr '06

OK, it seems there is no longer an Extras security SIG. I'm going to contact the FESCO and get this ball moving properly. I'll send a notice to this list when there is something to post. -- JB

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security April 2006