Proper procedure for reporting possible security vulnerabilities?

Proper procedure for reporting possible security vulnerabilities?

[Steve Bergman]

There seems to be some confusion in certain quarters as to the proper 
procedure for reporting possible kernel security issues.   
REPORTING-BUGS says send bug reports to the maintainer of that area of 
the kernel.  However, what about areas for which a maintainer is not 
listed?  (e.g. VM)  It seems that some take that to mean send it 
directly to Linus and if you don't hear something back quickly, release 
an exploit to the wild.

So what is the preferred procedure and is it documented somewhere?  
Should it be made more prominent?

Thanks for any information,
Steve Bergman

Re: Proper procedure for reporting possible security vulnerabilities?

[Indrek Kruusa]

Steve Bergman wrote:

> There seems to be some confusion in certain quarters as to the proper 
> procedure for reporting possible kernel security issues.   
> REPORTING-BUGS says send bug reports to the maintainer of that area of 
> the kernel.


Unfortunately my english is not on a par with this but this document 
*needs* updating at every corner and after that the direct hyperlink to 
this document on the kernel.org should be placed above links of the 
kernel source (currently it is somewhere at the middle of the page). And 
the note "please read before using vanilla kernel" should be in red. It 
*seems* to me that there is a big cap between reality and this 
document/common sense (in the days of heavily patched kernels and 2.6 
devel. model). There should be several separate parts in this document: 
for kernel developers, for distro makers, for "smart" users, for 
"enthusiasts"....

regards,
Indrek

Re: Proper procedure for reporting possible security vulnerabilities?

[Alan Cox]

On Llu, 2005-01-10 at 16:46, Steve Bergman wrote:
> So what is the preferred procedure and is it documented somewhere?  
> Should it be made more prominent?

Good question. The preferred procedure depends on your viewpoint on
disclosure

vendor-sec@lst.de is a cross vendor security list and a good place for
stuff. It will deal with both public and date embargoed security
information. security@[your-vendor] should work for most responsible
vendors and may be more appropriate if it involves a vendor kernel that
may have bugs not in the base tree. 

For stuff in -bk kernel snapshots and the like that isn't in the
production kernels then I'd start by mailing Linus/(Andrew for -mm) or
the list.

Alan

Re: Proper procedure for reporting possible security vulnerabilities?

[Florian Weimer]

* Steve Bergman:

> So what is the preferred procedure and is it documented somewhere?  

Contact your vendor.  You are using vendor kernels, are you? 8-)

Re: Proper procedure for reporting possible security vulnerabilities?

[Steve Bergman]

Florian Weimer wrote:

>Contact your vendor.  You are using vendor kernels, are you? 8-)
>  
>

Actually I am having a discussion with a Pax Team member about how the 
recent exploits discovered by the grsecurity guys should have been 
handled.  They clam that they sent email to Linus and Andrew and did not 
receive a response for 3 weeks, and that is why they released exploit 
code into the wild.

Anyone here have any comments on what I should tell him?

Thanks,
Steve Bergman

Re: Proper procedure for reporting possible security vulnerabilities?

[Diego Calleja]

El Mon, 10 Jan 2005 15:42:11 -0600 Steve Bergman <steve@rueb.com> escribió:

> Actually I am having a discussion with a Pax Team member about how the 
> recent exploits discovered by the grsecurity guys should have been 
> handled.  They clam that they sent email to Linus and Andrew and did not 
> receive a response for 3 weeks, and that is why they released exploit 
> code into the wild.


They could have mailed to *THIS* mailing list, so anyone can make a patch.

Re: Proper procedure for reporting possible security vulnerabilities?

[linux-os]

Are you sure it's an exploit? My information was that grsecurity
wanted some of their 'hooks' added to recent kernels and it hasn't
happened. That's not a security problem, that's an application
problem.

On Mon, 10 Jan 2005, Steve Bergman wrote:

> Florian Weimer wrote:
>
>> Contact your vendor.  You are using vendor kernels, are you? 8-)
>> 
>
> Actually I am having a discussion with a Pax Team member about how the recent 
> exploits discovered by the grsecurity guys should have been handled.  They 
> clam that they sent email to Linus and Andrew and did not receive a response 
> for 3 weeks, and that is why they released exploit code into the wild.
>
> Anyone here have any comments on what I should tell him?
>
> Thanks,
> Steve Bergman
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Proper procedure for reporting possible security vulnerabilities?

[Jesper Juhl]

On Mon, 10 Jan 2005, Steve Bergman wrote:

> Florian Weimer wrote:
> 
> > Contact your vendor.  You are using vendor kernels, are you? 8-)
> >  
> 
> Actually I am having a discussion with a Pax Team member about how the recent
> exploits discovered by the grsecurity guys should have been handled.  They
> clam that they sent email to Linus and Andrew and did not receive a response
> for 3 weeks, and that is why they released exploit code into the wild.
> 
> Anyone here have any comments on what I should tell him?
> 
I don't know what other people would do or what the general feeling on 
the list is, but personally I'd send such reports to the maintainer and 
CC lkml, if there is no maintainer I'd just send to lkml.

-- 
Jesper Juhl

Re: Proper procedure for reporting possible security vulnerabilities?

[Barry K. Nathan]

On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
> They could have mailed to *THIS* mailing list, so anyone can make a patch.

And abandon the whole idea of coordinated disclosure? That would put
anyone using vendor kernels at a disadvantage (there would be a time gap
between the vulnerability being public and the vendor kernel being
released -- which happened anyway with uselib() but which doesn't
*always* happen).

-Barry K. Nathan <barryn@pobox.com>

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Jesper Juhl (juhl-lkml@dif.dk) wrote:
> On Mon, 10 Jan 2005, Steve Bergman wrote:
> > Actually I am having a discussion with a Pax Team member about how the recent
> > exploits discovered by the grsecurity guys should have been handled.  They
> > clam that they sent email to Linus and Andrew and did not receive a response
> > for 3 weeks, and that is why they released exploit code into the wild.
> > 
> > Anyone here have any comments on what I should tell him?
> > 
> I don't know what other people would do or what the general feeling on 
> the list is, but personally I'd send such reports to the maintainer and 
> CC lkml, if there is no maintainer I'd just send to lkml.

Problem is, the rest of the world uses a security contact for reporting
security sensitive bugs to project maintainers and coordinating
disclosures.  I think it would be good for the kernel to do that as well.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Proper procedure for reporting possible security vulnerabilities?

[Barry K. Nathan]

On Mon, Jan 10, 2005 at 05:09:18PM -0500, linux-os wrote:
> Are you sure it's an exploit? My information was that grsecurity
> wanted some of their 'hooks' added to recent kernels and it hasn't
> happened. That's not a security problem, that's an application
> problem.

Yes, exploit (although the severity is arguable). See the 2.6.10-ac7
portion of the changelog here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=110523047925271&w=2

-Barry K. Nathan <barryn@pobox.com>

Re: Proper procedure for reporting possible security vulnerabilities?

[Diego Calleja]

El Mon, 10 Jan 2005 16:19:01 -0800 "Barry K. Nathan" <barryn@pobox.com> escribió:

> On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
> > They could have mailed to *THIS* mailing list, so anyone can make a patch.
> 
> And abandon the whole idea of coordinated disclosure? That would put
> anyone using vendor kernels at a disadvantage (there would be a time gap
> between the vulnerability being public and the vendor kernel being
> released -- which happened anyway with uselib() but which doesn't
> *always* happen).

Yes it wouldn't be "coordinated disclosure" but at least you'd get a patch
instead of a public exploit. 

Re: Proper procedure for reporting possible security vulnerabilities?

[Diego Calleja]

El Mon, 10 Jan 2005 16:40:02 -0800 Chris Wright <chrisw@osdl.org> escribió:

> Problem is, the rest of the world uses a security contact for reporting
> security sensitive bugs to project maintainers and coordinating
> disclosures.  I think it would be good for the kernel to do that as well.

(somewhat OT..)

Perhaps it's just me, but i think it'd be nice that a new kernel version is
released every time a security issue is found.

Yes, vendors update their kernels themselves, but there's a *lot* of people
in linux who run kernel.org kernels, and it's hopefully to keep working
that way.

Those people  can also update themselves their kernel, also true. But the
security issues found in linux are not announced anywhere but mailing list
and sites like slashdot. Many people who run kernels from kernel.org don't
read slashdot or mailing lists and don't that there's a need of updating their
kernels. A new kernel version every time a security issue is found would help
for those people, or at least a "security updates" section in kernel.org's
webpage. Right now there's no "official" way of announcing those updates, and
I think it's a serious lack for a OS which is so widely used.

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Diego Calleja (diegocg@gmail.com) wrote:
> El Mon, 10 Jan 2005 16:40:02 -0800 Chris Wright <chrisw@osdl.org> escribió:
> 
> > Problem is, the rest of the world uses a security contact for reporting
> > security sensitive bugs to project maintainers and coordinating
> > disclosures.  I think it would be good for the kernel to do that as well.
> 
> (somewhat OT..)
> 
> Perhaps it's just me, but i think it'd be nice that a new kernel version is
> released every time a security issue is found.

I agree.  I'd not mind seeing a full release, but at least a collection
of relevant patches.  I used to keep such a list, and have discussed
bringing it back with some folks (just for the current stable 2.6.x).
I think there's some agreement that we could do better.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Proper procedure for reporting possible security vulnerabilities?

[Florian Weimer]

* Alan Cox:

> vendor-sec@lst.de is a cross vendor security list and a good place for
> stuff.

Some people claim that vendor-sec is not trustworthy anymore because
it leaks information, based on the recent forged e-matters advisory.
Personally, I think the intent of the forgers was to discredit
vendor-sec.  There's no hard no evidence that there is a systematic
leak (apart from the occasional blunders).

Re: Proper procedure for reporting possible security vulnerabilities?

[Florian Weimer]

* Barry K. Nathan:

> On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
>> They could have mailed to *THIS* mailing list, so anyone can make a patch.
>
> And abandon the whole idea of coordinated disclosure?

For local vulnerabilities?  Get real.

Most users won't update anyway because they still believe that the
kernel team makes timely security releases, and they are safe as long
as they use the latest kernel.org release.  The current process
doesn't protect them.

(I know, they should use vendor kernels instead.)

Re: Proper procedure for reporting possible security vulnerabilities?

[Florian Weimer]

* Jesper Juhl:

> I don't know what other people would do or what the general feeling on 
> the list is, but personally I'd send such reports to the maintainer and 
> CC lkml, if there is no maintainer I'd just send to lkml.

Nevertheless, it would be good to have a designated security contact
just in case, when something is discovered that needs a more
coordinated form of disclosure.  Death by a single IP packet in the
default configuration, for example.

Local privilege escalation (or even denial-of-service) is not really
relevant.  We know from experience that Linux does not enforce local
account separation and won't do so for the forseeable future, and the
prudent don't rely on it.

Re: Proper procedure for reporting possible security vulnerabilities?

[Alan Cox]

On Llu, 2005-01-10 at 21:42, Steve Bergman wrote:
> handled.  They clam that they sent email to Linus and Andrew and did not 
> receive a response for 3 weeks, and that is why they released exploit 
> code into the wild.
> 
> Anyone here have any comments on what I should tell him?

They could have reported them to:
	vendor-sec
	cert
	dfn-cert
	any other cert like object
	security@almost any linux vendor

but didn't. Nor it appears did they chase up their report.

Re: Proper procedure for reporting possible security vulnerabilities?

[Alan Cox]

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.

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.

Alan

Re: Proper procedure for reporting possible security vulnerabilities?

[Jesper Juhl]

On Mon, 10 Jan 2005, Barry K. Nathan wrote:

> On Mon, Jan 10, 2005 at 11:08:27PM +0100, Diego Calleja wrote:
> > They could have mailed to *THIS* mailing list, so anyone can make a patch.
> 
> And abandon the whole idea of coordinated disclosure? That would put

Not everyone agrees that that is the proper way to do things, some prefer 
full disclosure.
Personally I'd prefer full disclosure on a public mailing list (copying 
vendors, maintainers etc of course), so as many people as possible can get 
to work on a fix as soon as possible. Keeping things secret doesn't speed 
up the time to get a fix made.

-- 
Jesper Juhl

Re: Proper procedure for reporting possible security vulnerabilities?

[Jesper Juhl]

On Mon, 10 Jan 2005, Chris Wright wrote:

> * Jesper Juhl (juhl-lkml@dif.dk) wrote:
> > On Mon, 10 Jan 2005, Steve Bergman wrote:
> > > Actually I am having a discussion with a Pax Team member about how the recent
> > > exploits discovered by the grsecurity guys should have been handled.  They
> > > clam that they sent email to Linus and Andrew and did not receive a response
> > > for 3 weeks, and that is why they released exploit code into the wild.
> > > 
> > > Anyone here have any comments on what I should tell him?
> > > 
> > I don't know what other people would do or what the general feeling on 
> > the list is, but personally I'd send such reports to the maintainer and 
> > CC lkml, if there is no maintainer I'd just send to lkml.
> 
> Problem is, the rest of the world uses a security contact for reporting
> security sensitive bugs to project maintainers and coordinating
> disclosures.  I think it would be good for the kernel to do that as well.
> 
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).

-- 
Jesper Juhl

Re: Proper procedure for reporting possible security vulnerabilities?

[Jan Engelhardt]

>Not everyone agrees that that is the proper way to do things, some prefer 
>full disclosure.
>Personally I'd prefer full disclosure on a public mailing list (copying 
>vendors, maintainers etc of course), so as many people as possible can get 
>to work on a fix as soon as possible. Keeping things secret doesn't speed 
>up the time to get a fix made.

But five people working on the same thing aiming to provide a patch (the 
very same one, probably) is also no better; work could be saved.



Jan Engelhardt
-- 
ENOSPC

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Jesper Juhl (juhl-lkml@dif.dk) wrote:
> On Mon, 10 Jan 2005, Chris Wright wrote:
> > Problem is, the rest of the world uses a security contact for reporting
> > security sensitive bugs to project maintainers and coordinating
> > disclosures.  I think it would be good for the kernel to do that as well.
> > 
> 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).

That's not quite the case.  The point of having a security contact is to
help coordinate timely public disclosure, not to sit on and mothball
info.  In most projects it turns out to be helpful.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

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@lst.de 
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@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:
	- vendor-sec@lst.de
	- 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, vendor-sec@lst.de (so the vendors get a fair chance to 
react to the public information on an even footing with everyone else), 
linux-kernel@vger.kernel.org (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@vger.kernel.org>
Your CC list should most likely include:
        - vendor-sec@lst.de
        - security@vendor.tld (or equivalent)
	- special interrest mailing lists relevant to the affected code.





-- 
Jesper Juhl

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Jesper Juhl (juhl-lkml@dif.dk) wrote:
> 
> 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 ?

Let's just bite the bullet...

===== REPORTING-BUGS 1.2 vs edited =====
--- 1.2/REPORTING-BUGS	2002-02-04 23:39:13 -08:00
+++ edited/REPORTING-BUGS	2005-01-10 15:35:10 -08:00
@@ -16,6 +16,9 @@ code relevant to what you were doing. If
 describe how to recreate it. That is worth even more than the oops itself.
 The list of maintainers is in the MAINTAINERS file in this directory.
 
+      If it is a security bug, please copy the Security Contact listed
+in the MAINTAINERS file.  They can help coordinate bugfix and disclosure.
+
       If you are totally stumped as to whom to send the report, send it to
 linux-kernel@vger.kernel.org. (For more information on the linux-kernel
 mailing list see http://www.tux.org/lkml/).
===== MAINTAINERS 1.269 vs edited =====
--- 1.269/MAINTAINERS	2005-01-10 17:29:35 -08:00
+++ edited/MAINTAINERS	2005-01-11 13:29:23 -08:00
@@ -1959,6 +1959,11 @@ M:	christer@weinigel.se
 W:	http://www.weinigel.se
 S:	Supported
 
+SECURITY CONTACT
+P:	Security Officers
+M:	kernel-security@{osdl.org, vger.kernel.org, wherever}
+S:	Supported
+
 SELINUX SECURITY MODULE
 P:	Stephen Smalley
 M:	sds@epoch.ncsc.mil

Re: Proper procedure for reporting possible security vulnerabilities?

[Florian Weimer]

* Jesper Juhl:

> Problem is that the info can then get stuck at a vendor or maintainer 
> outside of public view and risk being mothballed.

The submitter can go public anyway.  Most coordinators do not require
signing NDAs for submitters (some require them from software authors,
though).

A designated security contact would give submitters a choice: either
go public directly, or try something else first.  And believe, some
vulnerabilities really need a tested fix which is published at the
time of disclosure (death by single packet, for example). 

Re: Proper procedure for reporting possible security vulnerabilities?

[Florian Weimer]

* Alan Cox:

> On Llu, 2005-01-10 at 21:42, Steve Bergman wrote:
>> handled.  They clam that they sent email to Linus and Andrew and did not 
>> receive a response for 3 weeks, and that is why they released exploit 
>> code into the wild.
>> 
>> Anyone here have any comments on what I should tell him?
>
> They could have reported them to:
> 	vendor-sec

vendor-sec's reputation apparently has been damaged in some circles as
the result of the fake e-matters advisory.  Heise Online also
suggested that the exploit was leaked from vendor-sec ("a natural
conclusion").

> 	cert

CERT/CC shares vulnerability information with anyone who's paying
enough money (read the fine print).  Probably that's not what the
submitters want.

> 	dfn-cert

DFN-CERT is certainly honored to be included in this list, but they
can only forward it to security@ at some vendors and probably
vendor-sec.

If you get stuck, asking someone who has published kernel
vulnerabilities previously what to do is also an option.

But in general, there are plenty of options besides trying to contact
just two kernel developers high up the food chain.  Contacting the
subsystem maintainer is often a possiblity, too.  Of course, it's no
good if the subsystem maintainer tells you to post it to a public
list. 8-/

Re: Proper procedure for reporting possible security vulnerabilities?

[Jesper Juhl]

On Tue, 11 Jan 2005, Chris Wright wrote:

> * Jesper Juhl (juhl-lkml@dif.dk) wrote:
> > 
> > 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 ?
> 
> Let's just bite the bullet...
> 
No value in providing some info on what's the apreciated behaviour for 
both the coordinated disclosure and full disclosure people of the world? 
Both camps are going to continue to exist, and if you only provide 
information on the prefered aproach for coordinated disclosure then you 
have even less influence on how the full disclosure camp will spread the 
info - if you provide some info for them as well, at least some are going 
to follow it and then more of the proper kernel people will get notified 
at once instead of finding out later via other channels. I still think 
adding something along the lines of what I wrote to REPORTING-BUGS has 
merrit.


-- 
Jesper Juhl


PS. Linus, adding you to CC since you're involved in the new thread on 
more or less the same topic, so I thought you might be interrested in this 
thread as well.

Re: Proper procedure for reporting possible security vulnerabilities?

[Alan Cox]

On Mer, 2005-01-12 at 12:33, Florian Weimer wrote:
> vendor-sec's reputation apparently has been damaged in some circles as
> the result of the fake e-matters advisory.  Heise Online also
> suggested that the exploit was leaked from vendor-sec ("a natural
> conclusion").

For someone who has no actual information and is speculating wildly
perhaps. There are very good reasons that those who know something about
it are fairly sure it isnt the case.

Re: Proper procedure for reporting possible security vulnerabilities?

[Werner Almesberger]

Chris Wright wrote:
> +SECURITY CONTACT
> +P:	Security Officers
> +M:	kernel-security@{osdl.org, vger.kernel.org, wherever}
> +S:	Supported

If you mean this in the sense of "choose one, then put it here",
this looks good. If you're suggesting multiple choices, to be
made by the bug reporter, I'm not so sure.

A single contact point, preferably with a human being that can
confirm that the message has been received and understood, and
indicate that there's now somebody taking care of it who knows
what to do (which may just be forwarding it to someone else or
some list, and monitoring the reaction), should be useful.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Werner Almesberger (wa@almesberger.net) wrote:
> Chris Wright wrote:
> > +SECURITY CONTACT
> > +P:	Security Officers
> > +M:	kernel-security@{osdl.org, vger.kernel.org, wherever}
> > +S:	Supported
> 
> If you mean this in the sense of "choose one, then put it here",
> this looks good. If you're suggesting multiple choices, to be
> made by the bug reporter, I'm not so sure.

Yeah, "choose one, then put it here."  I've set up
security@kernel.osdl.org.

> A single contact point, preferably with a human being that can
> confirm that the message has been received and understood, and
> indicate that there's now somebody taking care of it who knows
> what to do (which may just be forwarding it to someone else or
> some list, and monitoring the reaction), should be useful.

Agreed.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Proper procedure for reporting possible security vulnerabilities?

[Christoph Hellwig]

On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> Yeah, "choose one, then put it here."  I've set up
> security@kernel.osdl.org.

Any chance we could have that @kernel.org or @vger.kernel.org?

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> > Yeah, "choose one, then put it here."  I've set up
> > security@kernel.osdl.org.
> 
> Any chance we could have that @kernel.org or @vger.kernel.org?

Yeah sure, I'll ask.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Proper procedure for reporting possible security vulnerabilities?

[Alan Cox]

On Llu, 2005-01-17 at 23:26, Chris Wright wrote:
> * Christoph Hellwig (hch@infradead.org) wrote:
> > On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> > > Yeah, "choose one, then put it here."  I've set up
> > > security@kernel.osdl.org.
> > 
> > Any chance we could have that @kernel.org or @vger.kernel.org?

@kernel.org would make a lot of sense given most other products/projects
are security@[projectsite] - security@mozilla.org etc

Re: Proper procedure for reporting possible security vulnerabilities?

[Chris Wright]

* Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> On Llu, 2005-01-17 at 23:26, Chris Wright wrote:
> > * Christoph Hellwig (hch@infradead.org) wrote:
> > > On Mon, Jan 17, 2005 at 02:52:16PM -0800, Chris Wright wrote:
> > > > Yeah, "choose one, then put it here."  I've set up
> > > > security@kernel.osdl.org.
> > > 
> > > Any chance we could have that @kernel.org or @vger.kernel.org?
> 
> @kernel.org would make a lot of sense given most other products/projects
> are security@[projectsite] - security@mozilla.org etc

Makes perfect sense.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: Proper procedure for reporting possible security vulnerabilities?

[Indrek Kruusa]

Horst von Brand wrote:

>Indrek Kruusa <indrek.kruusa@tuleriit.ee> said:
>  
>
>>Steve Bergman wrote:
>>
>>    
>>
>>>There seems to be some confusion in certain quarters as to the proper 
>>>procedure for reporting possible kernel security issues.   
>>>REPORTING-BUGS says send bug reports to the maintainer of that area of 
>>>the kernel.
>>>      
>>>
>>Unfortunately my english is not on a par with this but this document 
>>*needs* updating at every corner and after that the direct hyperlink to 
>>this document on the kernel.org should be placed above links of the 
>>kernel source (currently it is somewhere at the middle of the page). And 
>>the note "please read before using vanilla kernel" should be in red. It 
>>*seems* to me that there is a big cap between reality and this 
>>document/common sense (in the days of heavily patched kernels and 2.6 
>>devel. model). There should be several separate parts in this document: 
>>for kernel developers, for distro makers, for "smart" users, for 
>>"enthusiasts"....
>>    
>>
>
>Write something up, I'd be happy to help polishing English. And you'll find
>more helpers on LKML.
>  
>
sorry, but... yes, it was meant as "I am ready to help" :) but 
definitely I am not the right person to start to change this document. I 
can assist as linux user who need some information about bug reporting 
and how/why I should use sources from kernel.org at all. I have no idea 
what is desired by kernel developers (obviously they need good reports 
from informed users and less annoying traffic in LKML...maybe this 
letter is similar, sorry) but I have seen that those old school 
enthusiasts who are going to compile their custom kernel after every new 
release or -ac - they are not happy 'cause something which was part of 
their life (faster, smaller and maybe safer custom system) is now quite 
hard to achieve. Explanation would be nice for them, maybe even in 
kernel README.

thanks,
Indrek