Fedora Extras Security Response Team

[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?

[Jesse Keating]

On Fri, 2006-04-28 at 16:15 -0400, Josh Bressers wrote:
> If you're interested, feel free to chime in.

Add me to the list.  I can try to help w/ packaging up stuff that gets
reported, or reviewing proposed updates.

I'm also really trying to drive this policy approval home within Extras.

[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

It's been suggested that we call this group the "Fedora Security Response
Team".  I don't have a complaint.  Unless someone has a very good reason,
we'll say that's the name.

[Jason L Tibbitts III]

> > > > > "JB" == Josh Bressers  writes:

JB> We will need a package manifest.  Basically a file that tells us
JB> which packages and versions we're currently shipping in extras.

Here's the query script I use:

#!/usr/bin/perl -w

$OWNERS='/home/tibbs/work/extras-cvs/owners/owners.list';
$MIRROR='/nas/redhat/mirror-extras';
@RELEASES=qw(3 4 5 development);

$qa=''; #quiet warning

open OWNERS, $OWNERS or die "Can't open $OWNERS: $!";
while (defined($l = <OWNERS>)) {
  next if $l =~ /^#/;
  chomp $l;

($distro, $package, $desc, $owner, $qa, $cc) = split(/|/, $l);

last if $package eq $ARGV[0];
}

unless ($package) {
  print "Could not find package $ARGV[0] in $OWNERS\n";
  exit 1;
}

print "Found package $package in owners.list:\n";
print "  Distro:\t$distro\n";
print "  Desc:\t\t$desc\n";
print "  Owner:\t$owner\n";
print "  CC:\t\t$cc\n";
print "  Releases and versions:\n";

for $release (@RELEASES) {
  $dir = "$MIRROR/$release/SRPMS";
  $release eq "development" && ($release = "dev");

opendir DIR, $dir or die "Can't opendir $dir: $!";
  while (defined($f = readdir(DIR))) {
    next unless $f =~ /^$package-(.*).src.rpm$/;
    next if $1 =~ /-.*-/;

($ver, $rev) = $1 =~ /^([^-]+)-([^-]+)$/;

print "    $release\t$ver\t$rev\t$dir/$f\n";
  }
}
> releases xmms

Found package xmms in owners.list:
  Distro:       Fedora Extras
  Desc:         The X MultiMedia System, a media player which resembles Winamp
  Owner:        [e-mail]
  CC:
  Releases and versions:
    4   1.2.10  19.fc4  /nas/redhat/mirror-extras/4/SRPMS/xmms-1.2.10-19.fc4.src.rpm
    4   1.2.10  21.fc4  /nas/redhat/mirror-extras/4/SRPMS/xmms-1.2.10-21.fc4.src.rpm
    5   1.2.10  22.fc5  /nas/redhat/mirror-extras/5/SRPMS/xmms-1.2.10-22.fc5.src.rpm
    5   1.2.10  23.fc5  /nas/redhat/mirror-extras/5/SRPMS/xmms-1.2.10-23.fc5.src.rpm
    dev 1.2.10  23.fc6  /nas/redhat/mirror-extras/development/SRPMS/xmms-1.2.10-23.fc6.src.rpm

- J<

[Luke Macken]

On Fri, Apr 28, 2006 at 04:15:19PM -0400, Josh Bressers wrote:
> 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.

I'm definitely willing to help out.

luke

[Hans de Goede]

Josh Bressers wrote:
> 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

I'm most definetly still interested IOW count me in. I won't be doing
much of the monitoring and bookkeeping, expect for the checking of lwn's
weekly security report against extras. I already get way to much mail as
things are. I'm however "available" for helping out with / reviewing
less then trivial fixes (C and C++ only) and I'm available to fix
packages where the maintainer is not available or not responsive.

I would like to suggest the following procedure for any "help needed (in
any form)" requests:
-send a mail to this list with the "help" request
-if appropriate someone can claim this (assign bz ticket?)
-if appropriate once the fix is in CVS the fixer posts a request for
 a review to this list.

Regards,

Hans

[Christian Iseli]

[e-mail] said:
> A tool to generate this will also be needed since we'll want to update this
> file on a regular basis.

Should be easy to snarf a piece of my script here:
http://cvs.fedora.redhat.com/viewcvs/status-report-scripts/?root=fedora

Basically, you just need to retain the grabRepoList piece for Extras, keep a
bit more info than just the package name, and format the output to taste.

If no one beats me to it, I'm happy to do the job some time in the coming days
(sorry, a bit swamped right now...).

Cheers,
    				Christian

(who didn't notice the reply-to was not the list...)

Fedora Security Response Team

[Josh Bressers]

> 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

I now have the ability to control who has commit access to this space, so
we're in good shape here now.  If you want to check this repository out
anonymously you can do so as such:

cvs -d :pserver:[e-mail]:/cvs/fedora \
co fedora-security

The current plan is to create files called fe4 and fe5 to sit next to the
fc4 and fc5 files in this location.  The format of fc[45] is currently
working, so I believe it's the correct way to go initially.

Those of you interested in being a part of the security response team will
need to send me your fedora account system username.  I can then add access
and provide further instructions.
> 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>.

There have been a few scripts that have been brought to my attention for
this, unless someone else gets to it first, I'm going to create a "tools"
directory in CVS and add such a script.
> 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.

Sadly I didn't get to this over the weekend.  I'll do what I can this week.

At this point, there should be three primary focal points for the security
response team.

1) Tracking new issues
2) Tracking old issues
3) Documentation

#1 and #3 are entertaining tasks.  #2 is going to be painful and horrible.
I'm not sure how far back we should go in CVE space.  I guess as far back
as we can with people willing to do the work.  These tasks do require a
manifest, which we don't technically have yet, but should soon.

Does this all sound sane to everyone else?

Thanks.

Fedora Security Response Team

[Jesse Keating]

On Tue, 2006-05-02 at 10:35 -0400, Josh Bressers wrote:
> Those of you interested in being a part of the security response team will
> need to send me your fedora account system username.  I can then add access
> and provide further instructions.

'jkeating' is my username.  Or it could be '[e-mail]'  not
sure.

Your plan does seem sane.

Fedora Security Response Team

[Dennis Gilmore]

On Tuesday 02 May 2006 09:35, Josh Bressers wrote:
> Those of you interested in being a part of the security response team will
> need to send me your fedora account system username.  I can then add access
> and provide further instructions.

ausil is my username
> At this point, there should be three primary focal points for the security
> response team.
> Tracking new issues
> Tracking old issues
> Documentation
>
> #1 and #3 are entertaining tasks.  #2 is going to be painful and horrible.
> I'm not sure how far back we should go in CVE space.  I guess as far back
> as we can with people willing to do the work.  These tasks do require a
> manifest, which we don't technically have yet, but should soon.
>
> Does this all sound sane to everyone else?
>
> Thanks.

Sounds Sane to me

Fedora Security Response Team

[Josh Bressers]

> > 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>.
>
> There have been a few scripts that have been brought to my attention for
> this, unless someone else gets to it first, I'm going to create a "tools"
> directory in CVS and add such a script.

I just added a script which was written by Jason L Tibbitts III (it was a
bit help, thanks Jason).  You can see it here if you wish:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/tools/?root=fedora

Jason's original script relied on a local archive of things, this one grabs
what it needs remotely.  It's not the fastest thing ever, but it should be
good enough for now.

% ./package-release nmh
Found package nmh in owners.list:
  Distro:       Fedora Extras
  Desc:         A mail handling system with a command line interface
  Owner:        [e-mail]
  CC:
  Releases and versions:
    3   1.1     13.fc3 /pub/fedora/linux/extras/3/SRPMS/nmh-1.1-13.fc3.src.rpm
    3   1.1     14.fc3 /pub/fedora/linux/extras/3/SRPMS/nmh-1.1-14.fc3.src.rpm
    4   1.1     13.fc4 /pub/fedora/linux/extras/4/SRPMS/nmh-1.1-13.fc4.src.rpm
    4   1.1     14.fc4 /pub/fedora/linux/extras/4/SRPMS/nmh-1.1-14.fc4.src.rpm
    5   1.1     18.fc5 /pub/fedora/linux/extras/5/SRPMS/nmh-1.1-18.fc5.src.rpm
    dev 1.1     18.fc5 /pub/fedora/linux/extras/development/SRPMS/nmh-1.1-18.fc5.src.rpm

Fedora Security Response Team

[Dave Eisenstein]

Josh Bressers wrote:
> I just added a script which was written by Jason L Tibbitts III (it was a
> bit help, thanks Jason).  You can see it here if you wish:
> http://cvs.fedora.redhat.com/viewcvs/fedora-security/tools/?root=fedora
>
> Jason's original script relied on a local archive of things, this one grabs
> what it needs remotely.  It's not the fastest thing ever, but it should be
> good enough for now.
>
> % ./package-release nmh
> Found package nmh in owners.list:
> <<snip>>
>     5   1.1     18.fc5 /pub/fedora/linux/extras/5/SRPMS/nmh-1.1-18.fc5.src.rpm
>     dev 1.1     18.fc5 /pub/fedora/linux/extras/development/SRPMS/nmh-1.1-18.fc5.src.rpm

SO how hard would it be to re-tool this script to look up things in legacy's
repositories?  (I haven't yet looked at the script in detail...)

-David

Fedora Security Response Team

[Josh Bressers]

> Josh Bressers wrote:
> > I just added a script which was written by Jason L Tibbitts III (it was a
> > bit help, thanks Jason).  You can see it here if you wish:
> > http://cvs.fedora.redhat.com/viewcvs/fedora-security/tools/?root=fedora
> >
> > Jason's original script relied on a local archive of things, this one grabs
> > what it needs remotely.  It's not the fastest thing ever, but it should be
> > good enough for now.
> >
> > % ./package-release nmh
> > Found package nmh in owners.list:
> > <<snip>>
> >     5   1.1     18.fc5 /pub/fedora/linux/extras/5/SRPMS/nmh-1.1-18.fc5.src.rpm
> >     dev 1.1     18.fc5 /pub/fedora/linux/extras/development/SRPMS/nmh-1.1-18.fc5.src.rpm
>
> SO how hard would it be to re-tool this script to look up things in legacy's
> repositories?  (I haven't yet looked at the script in detail...)

It shouldn't be too hard.  The bit where the file is displayed is sucked
off an ftp server.

Fedora Security Response Team

[Jason L Tibbitts III]

> > > > > "DE" == Dave Eisenstein  writes:

DE> SO how hard would it be to re-tool this script to look up things
DE> in legacy's repositories?

There's not much to it, but it does extract information from the
owners.list file which wouldn't make much sense for Legacy (or Core,
for that matter).  Without that you're basically looking through
directories for files with the right name.

DE> (I haven't yet looked at the script in detail...)

It's now on the order of 100 lines of perl after making everything
talk over the network to the FTP servers; nothing huge.

- J<

Fedora Security Response Team

[David Eisenstein]

Josh Bressers wrote:
> The current plan is to create files called fe4 and fe5 to sit next to the
> fc4 and fc5 files in this location.  The format of fc[45] is currently
> working, so I believe it's the correct way to go initially.

So is there a problem with creating and/or adding fc{3,2,1} rhl{7,9} files
here as well to track CVE issues with you all for Fedora Legacy issues?

If it's not a problem, I am wondering if any of you have any thoughts or
suggestions on how to go about generating such lists?
> Those of you interested in being a part of the security response team will
> need to send me your fedora account system username.  I can then add access
> and provide further instructions.

Probably would be a good idea to add me as well, if you don't mind, Josh,
since Fedora Legacy *is* security and critical updates to older distros.
That's all I and other Fedora Legacy workers do.  My fedora account system
username is uh, "questor", .  Thanks.
> <snip>
>
> At this point, there should be three primary focal points for the security
> response team.
> Tracking new issues
> Tracking old issues
> Documentation
>
> #1 and #3 are entertaining tasks.  #2 is going to be painful and horrible.
> I'm not sure how far back we should go in CVE space.  I guess as far back
> as we can with people willing to do the work.  These tasks do require a
> manifest, which we don't technically have yet, but should soon.

Um ... since we've never started a list for Fedora Legacy for all the CVE's
that ever existed (or at least since the Fedora Legacy project has existed),
is the creation and maintenance of these going to be torturous and cumbersome?

Legacy tends to work on issues by sets of related CVE #s, opening one Legacy
Bugzilla ticket per .src.rpm package (or related packages) to handle all the
distros that a given (set of) CVE's address for that (those) package(s).  We
also use package codes in the "Status Whiteboard" to indicate which distros
for a given package are affected by those CVE's.  We therefore tend to
ignore the actual version tag at the top of a Bugzilla report (often setting
it to the legacy-specific value "unspecified") unless a vulnerability only
affects one of the 5 distros we maintain.

Due to this way of working with bugs, and to reduce duplication, my
temptation is to suggest that, if legacy may also maintain CVE status
file(s) there in CVS, for legacy's use, we just use one file (maybe name it
'legacy'?) with all the CVE entries, and mark each individual CVE line for
which particular distros that CVE affects (or at least seems to affect).
Doing this in lieu of maintaining 5 separate files with 5 separate
copies of all the CVE numbers would seem to be a big labor-saver.  What do
you think, Jesse?  Or anyone else?

Putting together a fairly complete list of all the CVE's and all the
packages that are vulnerable or fixed by all of these CVE's ... ugh, it
indeed sounds like a horrible task!  Are there any plans or thoughts to have
something like "security days" whereby a bunch of us folks can get together
and do the work while yakking it up on an IRC channel, making the process at
least potentially a *little* more fun, and making it possible for us to get
to know one another better?
> Does this all sound sane to everyone else?

Everything sounds sane to me, Josh.  Thanks for taking the ball and running
with it in getting this stuff going.  :-)

Warm regards,
    David Eisenstein

Fedora Security Response Team

[Josh Bressers]

> So is there a problem with creating and/or adding fc{3,2,1} rhl{7,9} files
> here as well to track CVE issues with you all for Fedora Legacy issues?
>
> If it's not a problem, I am wondering if any of you have any thoughts or
> suggestions on how to go about generating such lists?

If you have the information captured in bugzilla you may be able to extract
it from there.  The descriptions MITRE provides for issues is prose, so
there isn't really a nice way to get what you need from there.

I have no complaints about tracking the Fedora Legacy distributions in CVS.
I think keeping things close together is wise.  If we are tracking this
many distributions though, perhaps one file for each is not the right way
to go.  Perhaps some thought and discussion is warranted.
> Probably would be a good idea to add me as well, if you don't mind, Josh,
> since Fedora Legacy *is* security and critical updates to older distros.
> That's all I and other Fedora Legacy workers do.  My fedora account system
> username is uh, "questor", .  Thanks.

Done.
> > <snip>
> >
> > At this point, there should be three primary focal points for the security
> > response team.
> > Tracking new issues
> > Tracking old issues
> > Documentation
> >
> > #1 and #3 are entertaining tasks.  #2 is going to be painful and horrible.
> > I'm not sure how far back we should go in CVE space.  I guess as far back
> > as we can with people willing to do the work.  These tasks do require a
> > manifest, which we don't technically have yet, but should soon.
>
> Um ... since we've never started a list for Fedora Legacy for all the CVE's
> that ever existed (or at least since the Fedora Legacy project has existed),
> is the creation and maintenance of these going to be torturous and cumbersome?

The creation is painful as there are literally tens of thousands of CVE ids
per year.  Once you're caught up things aren't as bad since the ids are
just a constant trickle of information.
> Putting together a fairly complete list of all the CVE's and all the
> packages that are vulnerable or fixed by all of these CVE's ... ugh, it
> indeed sounds like a horrible task!  Are there any plans or thoughts to have
> something like "security days" whereby a bunch of us folks can get together
> and do the work while yakking it up on an IRC channel, making the process at
> least potentially a *little* more fun, and making it possible for us to get
> to know one another better?

This isn't a half bad idea (what do others think?).  At the very least perhaps an IRC channel is in
order.  I see #fedora-security already exists on Freenode, no doubt just
for this purpose :)

Fedora Security Response Team

[Dennis Gilmore]

On Wednesday 10 May 2006 09:00, Josh Bressers wrote:
> > So is there a problem with creating and/or adding fc{3,2,1} rhl{7,9}
> > files here as well to track CVE issues with you all for Fedora Legacy
> > issues?
> >
> > If it's not a problem, I am wondering if any of you have any thoughts or
> > suggestions on how to go about generating such lists?
>
> If you have the information captured in bugzilla you may be able to extract
> it from there.  The descriptions MITRE provides for issues is prose, so
> there isn't really a nice way to get what you need from there.

a simple perl script  should be able to extract the info from the bugzilla 
database and insert it into a text file.  I did something kinda similar  but 
in reverse  i extracted  the component info from Fedora's  describe 
components  page  and inserted into Aurora's  bugzilla database.   it saved 
much typing.
> I have no complaints about tracking the Fedora Legacy distributions in CVS.
> I think keeping things close together is wise.  If we are tracking this
> many distributions though, perhaps one file for each is not the right way
> to go.  Perhaps some thought and discussion is warranted.

I think we should track  Legacy here.  It serves  the ultimate goal  of having 
one central location for Fedora Security.   I see 3 ways  to track the info

1)  as we are  one file per release  perhaps  merging extras and core into one 
file. (not now  but later)
2) use one file per CVE.  has alot of files  but you could have  in it each 
effected release
3) Time based rotation of files. List in a similar manner to currently done   
but add the releases effected to the end   and rotate  files  each 
month/quarter/half year/full year
> > Um ... since we've never started a list for Fedora Legacy for all the
> > CVE's that ever existed (or at least since the Fedora Legacy project has
> > existed), is the creation and maintenance of these going to be torturous
> > and cumbersome?
>
> The creation is painful as there are literally tens of thousands of CVE ids
> per year.  Once you're caught up things aren't as bad since the ids are
> just a constant trickle of information.

Back tracking will be extremly painful.   and the further forward we move the 
less neccesary it will become.  for instance  once Legacy drops FC1 supprot  
there wont be much concern if older security ises were resolved or not.
> > Putting together a fairly complete list of all the CVE's and all the
> > packages that are vulnerable or fixed by all of these CVE's ... ugh, it
> > indeed sounds like a horrible task!  Are there any plans or thoughts to
> > have something like "security days" whereby a bunch of us folks can get
> > together and do the work while yakking it up on an IRC channel, making
> > the process at least potentially a *little* more fun, and making it
> > possible for us to get to know one another better?
>
> This isn't a half bad idea (what do others think?).  At the very least
> perhaps an IRC channel is in order.  I see #fedora-security already exists
> on Freenode, no doubt just for this purpose :)

I started #fedora-security  back when the SIG  was first proposed  Just for 
this type of thing.   the security days   sounds like a great idea.

Fedora Security Response Team

[Josh Bressers]

> as we are  one file per release  perhaps  merging extras and core into one
>
> file. (not now  but later)

This will depend on the outcome of the bizarre mating ritual that will no
doubt happen once core is freed.
> use one file per CVE.  has alot of files  but you could have  in it each
>
> effected release

This also complicates the issue of moving things forward.  Right now, when
FE6 must be tracked, a 'cp fe5 fe6' is a pretty solid start.
> Time based rotation of files. List in a similar manner to currently done
>
> but add the releases effected to the end   and rotate  files  each 
> month/quarter/half year/full year

I don't think this is wise.  The files will be rotated when EOL is reached.
Having everything in one easy to find place for each distribution is easier
IMO.

We can also just keep tracking things the way they currently are, but I
fear it won't scale.  One entry, per package, per distribution.  This fails
to scale with something like mozilla.

For each CVE id a mozilla application is assigned, we have to add a CVE id
for mozilla, thunderbird, firefox, seamonkey, in the FC[45], FE[45], and
all the legacy files (for those of you not counting on your fingers that
would be 16 lines added).  This isn't ideal, but the files are great for
tracking, simply because each one contains a good set of information.  If I
want to know what products CVE-2006-0123 affects, all I have to do is
'grep CVE-2006-0123 *'

I think the answer is tools.  The data the tools output can be whatever we
want, this particular format being something I like.  You might like
something different, which would be doable as it's all just information.
Ideally I should be able to visit a web page, or create a YAML file (or
some other format/process you prefer) which will note which versions of a
product and which packages are or are not vulnerable, why, then file
bugzilla bits for us automagically.