8:19 a.m.
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
9:04 a.m.
On Tue, Jan 16, 2007 at 09:19:07AM -0500, Josh Bressers wrote:
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.
I'd be interested in seeing the details of your Bugzilla CVE tracking.
The new package updating system, bodhi[0], currently keeps track of all
Bugzilla's and CVEs in their own tables. Upon adding an update, the
system grabs the bugs and checks them for a 'Security' keyword, and
changes the type of the update accordingly. All of this fun stuff can
be found in the model[1].
The 'New Update' form currently has an embargo field; can this safely be
removed ?
I also would like to completely revamp the current update notifications,
mainly to include references such as Bugs, CVE's, and maybe security
impact and such if available ?
luke
[0]: https://hosted.fedoraproject.org/projects/bodhi/ (I have yet to
migrate the stuff on the UpdatesSystem wiki[2] here yet)
[1]: https://hosted.fedoraproject.org/projects/bodhi/browser/bodhi/model.py
[2]: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem
2:51 p.m.
On Tuesday 16 January 2007 08:19, Josh Bressers wrote:
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.
This seems sane. :)
<snip>
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.
What would be nice i Think is a tool that puts cve's
with packages even before
bugzilla tickets are filed. this would need to tie into the package
database under development and the cve database. So we could see what CVE's
are out there for what packages that we have and bugzilla tickets filed and
would ignore CVE's for things we don't package.
I wonder if we should have monthly meetings. at least while a framework is
being developed.
how exactly is security handled inside Red Hat. Can we use existing
framework's tools?
I really hope we get some of Red Hat's security team involved in Fedora.
--
 ,-._|\   Dennis Gilmore, RHCE
/Aussie\ Â Proud Australian
\_.--._/ Â | Aurora | Fedora |
   v  Â
3:50 p.m.
<snip>
> 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.
What would be nice i Think is a tool that puts cve's with packages even before
bugzilla tickets are filed. this would need to tie into the package
database under development and the cve database. So we could see what CVE's
are out there for what packages that we have and bugzilla tickets filed and
would ignore CVE's for things we don't package.
I would love to see something like this, but sadly there isn't a nice
automated way to match a CVE id to a given package. I'd gladly hear ideas
on how to do this.
I wonder if we should have monthly meetings. at least while a framework is
being developed.
how exactly is security handled inside Red Hat. Can we use existing
framework's tools?
I'm rather anti meeting as they usually just end up creating an overly
complex and mostly unusable process. I'd much rather see us make things up
as we go along to see what works and what doesn't, and keep the things that
work.
As for security inside Red Hat, it's a rather manual effort. We track
things via a CVS repository, which doesn't really scale very well. Our
biggest advantage is the rather loose process we follow. The team is nimble
since it's not encumbered by an overly complex process. We can easily find
the people we need for any given tasks, which makes our lives much easier
during crunch time.
The fabled tools I speak of will also probably be used inside Red Hat as
well given the overlap that will exist. My challenge now it to find some
time to start working on them :)
--
JB
4:01 p.m.
I would love to see something like this, but sadly there isn't a
nice
automated way to match a CVE id to a given package. I'd gladly hear ideas
on how to do this.
NVD try to do this when they create their entries based on CVE (usually
they manage this before the CVE site gets updated, but after the CVENEW
mails come out). They map each vuln to a product dictionary which we
could map to package name, but it'll miss those cases where a
vulnerability gets reported for something that affects multiple products
(like some flaw being labelled as an Apple flaw when in fact it's in
xpdf), or where things affect multiple products (a xpdf issue affects many
open source projects).
example from
http://nvd.nist.gov/download/nvdcve-recent.xml
<vuln_soft>
<prod name="slocate" vendor="slocate">
<vers num="3.1"/>
</prod>
</vuln_soft>
Mark
5:49 a.m.
On Tue, 16 Jan 2007, Josh Bressers wrote:
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.
The process is quite straightforward imho:
1. Data acquisition
- keep track of vulnerabilities
- CVE (a good start but it should not be the only source of data)
- vulnerability databases (Bugtraq, OSVDB, Secunia...)
- mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
- other distros (they might have caught something we missed)
- Oval?
- weed out bogus reports (false reports, issues for MS Windows...)
- merge duplicate reports
- update existing reports when needed (exploit availability...)
2. Triage
- assess new and updated reports
- eliminate irrelevant reports (package not included in distro...)
- assign score to relevant reports (see below)
- reassess reports considered irrelevant when they become relevant
(new package added to distro...)
- prioritize reports according to their score
3. Remediation
- select a report/issue to work on
- find or develop patches
- check whether the patches fix the vulnerabilities
- deploy fixed packages
Embargoed (i.e. secret) issues can be implemented quite easily by
"polyinstantiation" of these three steps.
An interesting thing is that step 1 and a large part of step 2 do not
depend on the choice of distro. Moreover, step 1 alone generates "just
another vulnerability database". This provides an opportunity for mutually
beneficial cooperation with other subjects (other distros, OSVDB...).
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.
This sounds like a task for CVSS: a Firefox critical update will get a
high score due to its the remote attack vector, high target distribution,
and last but not least partial (or higher) integrity and confidentiality
impact (assuming it allows arbitrary code execution) while a minor lha
temporary file flaw will get a much lower score due its local attack
vector, low target distribution (well, it is probably installed on many
systems but most of the time, it is a dead harmless bag of bits because no
one is using it), and lower impact (partial integrity impact, no
confidentiality impact). The availability of exploits can be taken into
account as well.
On the other hand, it is quite easy to get an absurd CVSS score if input
metrics are set sloppily (as demonstrated by many examples at NVD). Some
experience (or guidance) and good judgement is needed.
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.
Bugzilla may be fine for the remediation step (see above).
But I do not feel it is (in its standard form) the right tool for steps
one and two. It's just too clumsy. Its search dialog is as complex as the
space shuttle dashboard and something as simple as checking whether a
report for a certain CVE has already been filed needs a lot of work. I
am probably biased, inexperienced, or even stupid (*). YMMV.
(*) But the sheer amount of duplicate reports in every Bz database
suggests I am not alone. ;)
On Tue, 16 Jan 2007, Mark J Cox wrote:
They map each vuln to a product dictionary which we could map to
package
name, but it'll miss those cases where a vulnerability gets reported for
something that affects multiple products (like some flaw being labelled
as an Apple flaw when in fact it's in xpdf), or where things affect
multiple products (a xpdf issue affects many open source projects).
It might be possible to search the source (*) code of all available
packages (maybe even packages not included in the distro) for duplicate or
similar pieces code and find out whether a bug in package A affects
package B because B uses some code from A (or vice versa).
(*) Statically linked libraries from other packages are not addressed by
this approach but they can be caught by other means.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
4:15 a.m.
1. Data acquisition
- keep track of vulnerabilities
- CVE (a good start but it should not be the only source of data)
- vulnerability databases (Bugtraq, OSVDB, Secunia...)
- mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
- other distros (they might have caught something we missed)
- Oval?
- weed out bogus reports (false reports, issues for MS Windows...)
- merge duplicate reports
- update existing reports when needed (exploit availability...)
That's a good summary of the process the Red Hat security response team
currently follow -- with the addition that when we discover something by
tracking that doesn't have a CVE we ensure that it gets a CVE name
assigned to it. Therefore the CVE list can be used as a definitive list
for anything that may affect Red Hat or Fedora (indeed for Fedora tracking
right now we base it off the CVENEW mails)
(OVAL just provides a way of expressing how to detect the presence of some
particular CVE named flaw)
This sounds like a task for CVSS:
I don't believe CVSS really works for open source software (or indeed any
software that is shipped by multiple vendors). Even assigning a Base
score is tricky to do. Is that flaw in ImageMagick where a buffer
overflow could be triggered if you open a malicious file you were given
"remote" or "local"? The attacker is remote. If you argue it's
"local"
then how about a flaw in something like xpdf? is that also local?
NVD say these are "user complicit" and marked as local. But doesn't it
depend on if xpdf is associated with pdf files in your web browser? It's
no user complicit if all you need to do is visit some malicious website.
How about if the flaw is in some widely used library like libpng; won't
the local/remote rating depend on exactly what software is using that
library in what ways?
Then you have to take into account the version of Fedora Core or RHEL as
each has different security technologies. Some double-free flaws can lead
to a complete loss of integrity on some systems, but no loss of integrity
but partial availability on others.
We do currently assign severities though, but we use a simple 4-level
scale with defined actions and goals for dealing with each level (for
example we aim to get a fix out for a critical vulnerability within a day
of it being public so we have to start paging people).
Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team
8:35 a.m.
On Mon, 22 Jan 2007, Mark J Cox wrote:
That's a good summary of the process the Red Hat security
response team
currently follow --
It was not me who broke into your offices and stole your papers. ;)
with the addition that when we discover something by tracking that
doesn't have a CVE we ensure that it gets a CVE name assigned to it.
Therefore the CVE list can be used as a definitive list for anything
that may affect Red Hat or Fedora (indeed for Fedora tracking right now
we base it off the CVENEW mails)
How much time does it take to get a new CVE number? Hours? Days?
How do you handle duplicate CVEs? (I don't know how often it happens
nowadays but they had some duplicate entries in the past.)
(OVAL just provides a way of expressing how to detect the presence of
some
particular CVE named flaw)
I know. I occurred to me a corpus of OVAL files (or anything similar in a
machine-readable form) might be used for automatic checks whether the
corresponding issues are relevant and (after the fact) whether they have
been handled properly.
> This sounds like a task for CVSS:
I don't believe CVSS really works for open source software (or indeed any
software that is shipped by multiple vendors).
It is impossible to assign a fixed universal severity rating to a
vulnerability in a software package used in more than one environment
and one configuration (there are many examples of software being secure
in one configuration and providing "instant remote root" in another
configuration).
Even assigning a Base score is tricky to do. Is that flaw in
ImageMagick where a buffer overflow could be triggered if you open a
malicious file you were given "remote" or "local"? The attacker is
remote. If you argue it's "local" then how about a flaw in something
like xpdf? is that also local?
Most vulnerabilities exploitable by evil files are "remote" because you do
not need a local account to exploit them. But the attacker cannot initiate
the execution of vulnerable code at will and it should be expressed as
"high access complexity" in CVSS terminology.
NVD say these are "user complicit" and marked as local.
I think they got it wrong. See above.
But doesn't it depend on if xpdf is associated with pdf files in
your
web browser? It's no user complicit if all you need to do is visit some
malicious website.
Well, it is "user complicit" as long as the attacker needs to convince a
local user to do something (to visit a website, to download and view a
file, to view an email attachment...).
On the other hand I find the choice of words ("complicit") misleading
when it is used to describe attacks when the user expects the operation
(visiting a website etc.) not to cause any harm.
How about if the flaw is in some widely used library like libpng;
won't
the local/remote rating depend on exactly what software is using that
library in what ways?
Sure. In fact anything can depend on the way the library is used: the same
vulnerability can be irrelevant in the context of one program (using the
library to process good trusted data only, e.g. the files shipped with the
program), a minor problem in the context of another program (the library
is used to process trusted data only but some inputs can trigger the bug,
e.g. outputs from some other program, and it makes the program using the
library unreliable), or a major hole in the context of yet another program
(accepting untrusted data from anyone in the Internet, e.g. files uploaded
via a publicly accessible web form, and feeding them to the library).
I myself would compute some kind of aggregate score over all reasonable
uses of the library. The exact meaning of "reasonable" and "not
reasonable" is fuzzy but I hope a little bit of common sense will help in
most cases. E.g. feeding an untrusted image to libpng is reasonable,
feeding an untrusted .gtkrc to libgtk is not reasonable (and it is the
program using the library that needs fixing in the first place). An
important reality check (in both directions): all existing uses in the
distro should be reasonable.
Then you have to take into account the version of Fedora Core or RHEL
as
each has different security technologies. Some double-free flaws can lead
to a complete loss of integrity on some systems, but no loss of integrity
but partial availability on others.
A vulnerable program running on a system with the double-free protection
and the same program running on a system without it are two different
pieces of software from this point of view. We are dealing with a certain
kind of a staged attack here: the first stage of the attack is to exploit
a vulnerability in the program itself violate the integrity of its
communication with the memory allocator, and the second stage is to
subvert the allocator through this channel.
It might be possible to rate such a program with an expression depending
on variables describing the rest of the system (e.g. its sensitivity to
double-frees), and compute multiple final results for every environment
being taken into account.
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
3:40 a.m.
Pavel Kankovsky wrote:
On Tue, 16 Jan 2007, Josh Bressers wrote:
> 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.
The process is quite straightforward imho:
1. Data acquisition
- keep track of vulnerabilities
- CVE (a good start but it should not be the only source of data)
- vulnerability databases (Bugtraq, OSVDB, Secunia...)
- mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
- other distros (they might have caught something we missed)
- Oval?
- weed out bogus reports (false reports, issues for MS Windows...)
- merge duplicate reports
- update existing reports when needed (exploit availability...)
2. Triage
- assess new and updated reports
- eliminate irrelevant reports (package not included in distro...)
- assign score to relevant reports (see below)
- reassess reports considered irrelevant when they become relevant
(new package added to distro...)
- prioritize reports according to their score
3. Remediation
- select a report/issue to work on
- find or develop patches
- check whether the patches fix the vulnerabilities
- deploy fixed packages
It has been awhile since I have done much here. Got lots of questions.
My concern here is how does someone new to this process come about
fairly easily and quickly knowing the status of any given vulnerability?
And how does someone know where to pitch in?
How many security issues might we have that could be open at the same time?
In order for any kind of orderly work to get done, a diverse and
geographically-spread team would need to know what area of work needs
the most work, and how to find out what issues are ones that they can
work on, plus some way of flagging issues so someone else five minutes
later signing on the the system to do some work won't start working on
the very same thing (avoiding duplication of effort, if possible).
If we have, for example, people identifying issues -- how do we make it
so a team of three identifiers don't identify the same issue three
times? (Or is that not a problem?) Do we have a quick 'n dirty way of
telling Joe Blow, a fellow scanning the Internet for vulnerabilities,
that CVE-2007-yyyy is already in the database and needs triage (which I
assume means "prioritization" = do we worry about this flaw today,
tomorrow, or next Wednesday)? Or of telling John Q. Public that
CVE-2007-xxxx has been triaged and now needs patches to be found and
published somewhere for Jim-Billy Bobb to go into the package CVS and
build a new package? How do we know when who does what and who has
access to which information where to get work done?
And how does the QA process fit in with all of this? Er, do we have
some kind of package QA process for security vulnerabilities? Would
community members be welcome to pitch in on this if there is a QA
process in place?
A good start might be a breakdown for those of us here who don't know --
who *now* does what for Core packages and for extras packages? What
does a security issue look like walked through the entire process, from
identifying the vulnerability to the release of a fixed package? What
does the process *now* look like and how do Red Hat people envision
opening up the process to let others in? How is information going to be
shared outside of the Security Response Team so it will be able to be
efficiently known about by your community contributors (excluding
embargoed issues, of course, for now)? And are embargoed issues for
former core packages now going to be ignored until the embargo is
lifted, or are they going to be able to be worked on by trusted
individuals inside Red Hat while embargoed, just as they are now?
If today I wanted to start being a security bug watcher, where do I
report them? Bugzilla? Or is there a person or a group of people that
already does this as a paid job inside of Red Hat?
Does the Fedora Security Team maintain a database (or "flat file")
stored out in a Fedora CVS server somewhere that indicates status of any
given CVE issue? If it is there, is the "how to use it" documented
anywhere? Is manipulating this flat file the best way to get security
bugs "into the system" for review?
If there are things that people know tacitly how to do, I would be more
than happy to help document current processes.
Is there any estimate of an ideal level of manpower doing things? And
what levels of expertise are needed for each of the security tasks,
especially when dealing with former Core packages by community members?
Thanks.
-David
10:36 a.m.
It has been awhile since I have done much here. Got lots of questions.
Wow, this mail is a lot of questions. I'll do my best to answer the ones I
have ideas for.
My concern here is how does someone new to this process come about
fairly easily and quickly knowing the status of any given vulnerability?
And how does someone know where to pitch in?
We'll have to figure this one out moving forward. I think the best way
will be to have an easy to understand and very public task list. A new
person could then easily identify orphaned things that need some attention.
How many security issues might we have that could be open at the same time?
I think the answer to this is "as many as there are". Ideally, there won't
be any open, but realistically, this number will probably be larger than
any of us will want.
In order for any kind of orderly work to get done, a diverse and
geographically-spread team would need to know what area of work needs
the most work, and how to find out what issues are ones that they can
work on, plus some way of flagging issues so someone else five minutes
later signing on the the system to do some work won't start working on
the very same thing (avoiding duplication of effort, if possible).
If we have, for example, people identifying issues -- how do we make it
so a team of three identifiers don't identify the same issue three
times? (Or is that not a problem?) Do we have a quick 'n dirty way of
telling Joe Blow, a fellow scanning the Internet for vulnerabilities,
that CVE-2007-yyyy is already in the database and needs triage (which I
assume means "prioritization" = do we worry about this flaw today,
tomorrow, or next Wednesday)? Or of telling John Q. Public that
CVE-2007-xxxx has been triaged and now needs patches to be found and
published somewhere for Jim-Billy Bobb to go into the package CVS and
build a new package? How do we know when who does what and who has
access to which information where to get work done?
This is where some tools can come in handy. I'm still working on getting
things in order, but here is the basics of what I'm thinking.
There is a queue in bugzilla called "Security Response". The plan is to
have one bug for each CVE id we have any sort of interest in. This would
then be a place we can add comments regarding an issue and track what's
affected.
We will then have product bugs for everything that needs one (Fedora, RHEL,
anything else that needs a bug). The product bugs will then be child bugs
of our CVE bug. This means that in order to determine what a given CVE id
affects, you'll have to look at the child bugs for each CVE bug. This
would be silly for a person to do, which is why we'll have a pretty web
page with it listed for us. I envision each CVE bug having an owner. The
tasks that aren't being worked on will be orphaned, and obviously up for
grabs. Here is a bad ASCII picture for those of you confused by my
gibberish.
CVE-XXXX-0001 <-- parent bug describing a flaw
|
+ Bug 12345 <-- filed against xpdf in Fedora
|
+ Bug 12346 <-- filed against cups in Fedora
|
+ Bug 12348 <-- filed against xpdf in RHEL
So obviously we'd have a tool that would make this very obvious as trolling
around bugzilla wouldn't be. The biggest advantage to this is that since
the various package developers use bugzilla for tracking their tasks, our
issue database is also the same place the developers look for what needs to
be fixed.
The only way this can work is with some tools. I'm currently working on
some python libraries to parse all this nicely. Once I have a basic
working prototype, I'll put the code in the fedora CVS then other can lend
a hand.
And how does the QA process fit in with all of this? Er, do we have
some kind of package QA process for security vulnerabilities? Would
community members be welcome to pitch in on this if there is a QA
process in place?
Right now we let the Fedora developers handle the package updates, which
also involve some amount of QA. I think we'll leave the QA bits up to the
developer and any QA groups that form. I think we should keep a somewhat
narrow focus on security updates. It's easy to get sidetracked and this is
a path that would likely have no end for this group.
A good start might be a breakdown for those of us here who don't know --
who *now* does what for Core packages and for extras packages? What
does a security issue look like walked through the entire process, from
identifying the vulnerability to the release of a fixed package? What
does the process *now* look like and how do Red Hat people envision
opening up the process to let others in? How is information going to be
shared outside of the Security Response Team so it will be able to be
efficiently known about by your community contributors (excluding
embargoed issues, of course, for now)? And are embargoed issues for
former core packages now going to be ignored until the embargo is
lifted, or are they going to be able to be worked on by trusted
individuals inside Red Hat while embargoed, just as they are now?
I'd start by taking a look at this message:
https://www.redhat.com/archives/fedora-security-list/2007-January/msg0003...
It's a pretty good description of our current process. I'm not really
interested in letting people into the current Red Hat process. I'm
interested in letting Red Hat into the Fedora process. Since we don't
really have a Fedora process, we get to make it up :)
If today I wanted to start being a security bug watcher, where do I
report them? Bugzilla? Or is there a person or a group of people that
already does this as a paid job inside of Red Hat?
I don't think I understand this question. Right now all security bugs
should be in bugzilla yes. There are people inside Red Hat, the Red Hat
Security Response Team that look for and deal with security bugs, but the
focus of this team is on Fedora Core and Red Hat Enterprise Linux. Once
Fedora 7 is out, I foresee some members of the team joining the Fedora
Security Response Team. There will be some task overlap, so I think it
just makes sense.
Does the Fedora Security Team maintain a database (or "flat file")
stored out in a Fedora CVS server somewhere that indicates status of any
given CVE issue? If it is there, is the "how to use it" documented
anywhere? Is manipulating this flat file the best way to get security
bugs "into the system" for review?
See my above comments about tools.
If there are things that people know tacitly how to do, I would be more
than happy to help document current processes.
We should probably start some wiki pages to capture all this information.
I honestly don't even remember what's all on the wiki about security
things. I wouldn't complain if someone could take the lead on handling the
documentation of questions and answers along with tool and process plans.
I don't expect to have time to look into this myself until I have my
prototype python library done.
Is there any estimate of an ideal level of manpower doing things? And
what levels of expertise are needed for each of the security tasks,
especially when dealing with former Core packages by community members?
I think the ideal level of manpower is as many people as are willing to
help :)
There isn't really a minimal competency level for this stuff. Obviously
some things require a certain level of expertise, but as those issues
arise, we'll have people around to handle those. I'm a believer in the
idea that everyone is at the bottom of the ladder at some point and time,
so if you're willing learn, we should be willing to teach.
--
JB
5:51 a.m.
On Sun, 28 Jan 2007, Pavel Kankovsky wrote:
How much time does it take to get a new CVE number? Hours? Days?
How do you handle duplicate CVEs? (I don't know how often it happens
nowadays but they had some duplicate entries in the past.)
Red Hat is a Candidate Naming Authority which means that for issues that
are not already public we can assign names from our pool. Where an issue
is public Mitre usually respond within a day or two. We can get them to
respond faster if it's urgent (like some new issue that's critcial and
going to get a lot of attention)
> NVD say these are "user complicit" and marked as
local.
I think they got it wrong. See above.
A severity rating system is useless to us if it reaches a level of
complexity where 1) it's unlikely two researchers will assign the same
values given the same conditions and 2) it takes longer to assign a
severity rating than triage and fix the flaw. But based on your comments
we do plan on looking at a sampling of more recent CVSS examples on NVD
again and seeing if they're getting closer to being useful.
Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team
5:55 a.m.
Does the Fedora Security Team maintain a database (or "flat
file") stored out
in a Fedora CVS server somewhere that indicates status of any given CVE
issue? If it is there, is the "how to use it" documented anywhere? Is
manipulating this flat file the best way to get security bugs "into the
system" for review?
Well there's a file in CVS for each Fedora:
http://cvs.fedora.redhat.com/viewcvs/fedora-security/audit/fc6?root=fedor...
It's actually more up to date than the header states though :)
Thanks, Mark
--
Mark J Cox / Red Hat Security Response Team
6288
days inactive
6309
days old
security@lists.fedoraproject.org
11 comments
6 participants
participants (6)
-
David Eisenstein -
Dennis Gilmore -
Josh Bressers -
Luke Macken -
Mark Cox -
Pavel Kankovsky