Fedora Extras Security Response Team
by Josh Bressers
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
17 years, 11 months
Re: Fedora Extras Security Response Team
by Josh Bressers
> 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
18 years
Intro...
by Michael J. Knox
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
18 years
A few questions about cve.mitre.org
by David Eisenstein
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
18 years
Heads up! Firefox & Mozilla
by David Eisenstein
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
18 years
Fedora Extras Security Response Team
by Josh Bressers
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
18 years
