Re: Proper procedure for reporting possible security vulnerabilities?

[Jesper Juhl]

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 
REPORTING-BUGS or as a seperate REPORTING-SECURITY-BUGS document ?

> 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.


*****
* REPORTING-BUGS
*****

The purpose of this text is to give information on how to report security 
vulnerabilities, submit example exploit code and similar about the Linux 
kernel.
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 vendor-sec@xxxxxx 
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 
kernel.org) 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@xxxxxxxxxxxxxxxxx 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:
	- vendor-sec@xxxxxx
	- security@xxxxxxxxxx (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, vendor-sec@xxxxxx (so the vendors get a fair chance to 
react to the public information on an even footing with everyone else), 
linux-kernel@xxxxxxxxxxxxxxx (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 <linux-kernel@xxxxxxxxxxxxxxx>
Your CC list should most likely include:
        - vendor-sec@xxxxxx
        - security@xxxxxxxxxx (or equivalent)
	- special interrest mailing lists relevant to the affected code.





-- 
Jesper Juhl



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/