archive mirror
 help / color / mirror / Atom feed
From: Jesper Juhl <>
To: Alan Cox <>
Cc: Jesper Juhl <>, Chris Wright <>,
	Steve Bergman <>,
	Linux Kernel Mailing List <>
Subject: Re: Proper procedure for reporting possible security vulnerabilities?
Date: Tue, 11 Jan 2005 22:25:18 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.61.0501111854120.3368@dragon.hygekrogen.localhost> (raw)
In-Reply-To: <1105461562.16168.46.camel@localhost.localdomain>

On Tue, 11 Jan 2005, Alan Cox wrote:

> On Maw, 2005-01-11 at 17:05, Jesper Juhl wrote:
> > Problem is that the info can then get stuck at a vendor or maintainer 
> > outside of public view and risk being mothballed. It also limits the 
> > number of people who can work on a solution (including peole getting to 
> > work on auditing other code for similar issues). It also prevents admins 
> > from taking alternative precautions prior to availability of a fix (you 
> > have to assume the bad guys already know of the bug, not just the good 
> > guys).
> The evidence is that for the most part the bad guys don't know about the
> bug and the majority of the bad guys are not skilled enough to write
> some of the complex exploits. They also automate extensively so given an
> exploit can make very fast very effective use of it. There is an entire
> field of economics and game theory tied up in this as well as papers by
> some in the field who look at computer security models this way.
Of course there are downsides to full disclosure, but there are downsides 
to controlled disclosure as well. We could argue that for ages, but even 
if the arguments persuaded a few to move to a different 'camp' there's 
still going to be two "camps" out there and there always will be. 

This thread got started by a question about how to go about informing 
people about security vulnerabilities so I think we should erhaps try to 
provide some sensible information about how to go about that that can be 
useful to people no matter what "disclosure camp" the agree with. How 
about something like what I've written below as an addition to 

> If you are a member of the full disclosure camp then fine, but please cc
> vendor-sec when you publish the hole just in case Linus loses the email
> and so vendors know too and can plan appropriately.
not informing vendors would be stupid, they should get told just as 
everyone else.

If we added something like the text below to REPORTING-BUGS or a sepperate 
document, then people would have an easier time finding out how to 
properly report security sensitive bugs, no matter what disclosure camp 
they belong to.
The text below is very much a draft, comments welcome.


The purpose of this text is to give information on how to report security 
vulnerabilities, submit example exploit code and similar about the Linux 
For general bug reporting information, please see the REPORTING-BUGS 
document in the root of the kernel source.

It is generally recognized that there exists two main views on 
how security vulnerabilities should be reported - the "full disclosure" 
and "coordinated disclosure" schools of thought. 
This text gives advice on how to report the issue depending on what camp 
you belong to. 

Coordinated disclosure
If you belong to the camp that believes that security vulnerabilities are 
best handled initially by maintainers, developers and vendors so that they 
get a chance to develop a fix before the public at large gets told about 
it then here's how you should probably report the issue.

Send your bugreport to the maintainer of the code affected. If there is no 
maintainer send it to the maintainer of the stable kernel series that it 
applies to. You may choose to send it to the kernel series maintainer as 
well in any case.
In most cases you want to also send the bugreport to the 
mailing list. This is a cross-vendor security list, and by sending your 
mail there it should reach most of the security contacts at the major 
Linux vendors.
If you are using a kernel from a vendor (as opposed to a kernel from and the issue only applies to the vendor kernel, then you 
should also copy the email to the security coordinator at your vendor 
(usually security@vendorsdomain.tld or similar). You may want to do this 
in any case even if the bug is not secific to your vendors kernel.

To sum this up. 
Your primary recipients should be:
	- maintainer of code in question
	- maintainer of stable kernel series
Your CC list should most likely include:
	- security@vendor.tld (or equivalent)

If you choose this approach, then please allow some time to pass for the 
maintainer/vendor to develop a fix - depending on the nature of the 
vulnerability, 14-30 days seems adequate before you publish the 
information in a larger forum. Also, please do follow up on your 
submission, make sure it's recieved and acted upon.

Full disclosure
If you belong to the camp that believes that information about security 
vulnerabilities should be made public broadly and with as many details as 
possible as fast as possible, then we request that you, in addition to 
whatever full disclosure mailing lists you are going to submit to, send a 
copy of your report to the maintainer of the code, the stable kernel 
series maintainer, (so the vendors get a fair chance to 
react to the public information on an even footing with everyone else), (so the kernel community at large gets a 
chance to respond) and also to any subsystem or special interrest mailing 
lists relevant to the code (if it's a net bug send a copy to netdev, if 
it's a scsi bug send a coy to linux-scsi etc).

So, to sum up the recipients:
Your primary recipients should be:
        - maintainer of code in question
        - maintainer of stable kernel series
	- the Linux Kernel Mailing List <>
Your CC list should most likely include:
        - security@vendor.tld (or equivalent)
	- special interrest mailing lists relevant to the affected code.

Jesper Juhl

  reply	other threads:[~2005-01-11 21:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-10 16:46 Steve Bergman
2005-01-10 18:23 ` Indrek Kruusa
2005-01-10 19:24 ` Alan Cox
2005-01-11  9:32   ` Florian Weimer
2005-01-10 21:31 ` Florian Weimer
2005-01-10 21:42   ` Steve Bergman
2005-01-10 22:08     ` Diego Calleja
2005-01-11  0:19       ` Barry K. Nathan
2005-01-11  0:45         ` Diego Calleja
2005-01-11  9:35         ` Florian Weimer
2005-01-11 16:57         ` Jesper Juhl
2005-01-11 17:05           ` Jan Engelhardt
2005-01-10 22:09     ` linux-os
2005-01-11  0:44       ` Barry K. Nathan
2005-01-10 22:11     ` Jesper Juhl
2005-01-11  0:40       ` Chris Wright
2005-01-11  1:09         ` Diego Calleja
2005-01-11  1:18           ` Chris Wright
2005-01-11 17:05         ` Jesper Juhl
2005-01-11 16:39           ` Alan Cox
2005-01-11 21:25             ` Jesper Juhl [this message]
2005-01-11 21:29               ` Chris Wright
2005-01-12 21:05                 ` Jesper Juhl
2005-01-17 22:49                 ` Werner Almesberger
2005-01-17 22:52                   ` Chris Wright
2005-01-17 23:23                     ` Christoph Hellwig
2005-01-17 23:26                       ` Chris Wright
2005-01-17 23:57                         ` Alan Cox
2005-01-18  1:08                           ` Chris Wright
2005-01-11 17:57           ` Chris Wright
2005-01-12 12:23           ` Florian Weimer
2005-01-11  9:49       ` Florian Weimer
2005-01-11 16:10     ` Alan Cox
2005-01-12 12:33       ` Florian Weimer
2005-01-13 15:36         ` Alan Cox
     [not found] <>
2005-01-10 21:36 ` Indrek Kruusa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0501111854120.3368@dragon.hygekrogen.localhost \ \ \ \ \ \
    --subject='Re: Proper procedure for reporting possible security vulnerabilities?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).