* Proper procedure for reporting possible security vulnerabilities? @ 2005-01-10 16:46 Steve Bergman 2005-01-10 18:23 ` Indrek Kruusa ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Steve Bergman @ 2005-01-10 16:46 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 16:46 Proper procedure for reporting possible security vulnerabilities? Steve Bergman @ 2005-01-10 18:23 ` Indrek Kruusa 2005-01-10 19:24 ` Alan Cox 2005-01-10 21:31 ` Florian Weimer 2 siblings, 0 replies; 36+ messages in thread From: Indrek Kruusa @ 2005-01-10 18:23 UTC (permalink / raw) To: Steve Bergman; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 16:46 Proper procedure for reporting possible security vulnerabilities? 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 2 siblings, 1 reply; 36+ messages in thread From: Alan Cox @ 2005-01-10 19:24 UTC (permalink / raw) To: Steve Bergman; +Cc: Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 19:24 ` Alan Cox @ 2005-01-11 9:32 ` Florian Weimer 0 siblings, 0 replies; 36+ messages in thread From: Florian Weimer @ 2005-01-11 9:32 UTC (permalink / raw) To: Alan Cox; +Cc: Steve Bergman, Linux Kernel Mailing List * 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). ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 16:46 Proper procedure for reporting possible security vulnerabilities? Steve Bergman 2005-01-10 18:23 ` Indrek Kruusa 2005-01-10 19:24 ` Alan Cox @ 2005-01-10 21:31 ` Florian Weimer 2005-01-10 21:42 ` Steve Bergman 2 siblings, 1 reply; 36+ messages in thread From: Florian Weimer @ 2005-01-10 21:31 UTC (permalink / raw) To: Steve Bergman; +Cc: linux-kernel * Steve Bergman: > So what is the preferred procedure and is it documented somewhere? Contact your vendor. You are using vendor kernels, are you? 8-) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 21:31 ` Florian Weimer @ 2005-01-10 21:42 ` Steve Bergman 2005-01-10 22:08 ` Diego Calleja ` (3 more replies) 0 siblings, 4 replies; 36+ messages in thread From: Steve Bergman @ 2005-01-10 21:42 UTC (permalink / raw) Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 21:42 ` Steve Bergman @ 2005-01-10 22:08 ` Diego Calleja 2005-01-11 0:19 ` Barry K. Nathan 2005-01-10 22:09 ` linux-os ` (2 subsequent siblings) 3 siblings, 1 reply; 36+ messages in thread From: Diego Calleja @ 2005-01-10 22:08 UTC (permalink / raw) To: Steve Bergman; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 22:08 ` Diego Calleja @ 2005-01-11 0:19 ` Barry K. Nathan 2005-01-11 0:45 ` Diego Calleja ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Barry K. Nathan @ 2005-01-11 0:19 UTC (permalink / raw) To: Diego Calleja; +Cc: Steve Bergman, linux-kernel 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> ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 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 2 siblings, 0 replies; 36+ messages in thread From: Diego Calleja @ 2005-01-11 0:45 UTC (permalink / raw) To: Barry K. Nathan; +Cc: steve, linux-kernel 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 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 2 siblings, 0 replies; 36+ messages in thread From: Florian Weimer @ 2005-01-11 9:35 UTC (permalink / raw) To: Barry K. Nathan; +Cc: Diego Calleja, Steve Bergman, linux-kernel * 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.) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 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 2 siblings, 1 reply; 36+ messages in thread From: Jesper Juhl @ 2005-01-11 16:57 UTC (permalink / raw) To: Barry K. Nathan; +Cc: Diego Calleja, Steve Bergman, linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 16:57 ` Jesper Juhl @ 2005-01-11 17:05 ` Jan Engelhardt 0 siblings, 0 replies; 36+ messages in thread From: Jan Engelhardt @ 2005-01-11 17:05 UTC (permalink / raw) Cc: linux-kernel >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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 21:42 ` Steve Bergman 2005-01-10 22:08 ` Diego Calleja @ 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 16:10 ` Alan Cox 3 siblings, 1 reply; 36+ messages in thread From: linux-os @ 2005-01-10 22:09 UTC (permalink / raw) To: Steve Bergman; +Cc: Linux kernel 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 22:09 ` linux-os @ 2005-01-11 0:44 ` Barry K. Nathan 0 siblings, 0 replies; 36+ messages in thread From: Barry K. Nathan @ 2005-01-11 0:44 UTC (permalink / raw) To: linux-os; +Cc: Steve Bergman, Linux kernel 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> ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 21:42 ` Steve Bergman 2005-01-10 22:08 ` Diego Calleja 2005-01-10 22:09 ` linux-os @ 2005-01-10 22:11 ` Jesper Juhl 2005-01-11 0:40 ` Chris Wright 2005-01-11 9:49 ` Florian Weimer 2005-01-11 16:10 ` Alan Cox 3 siblings, 2 replies; 36+ messages in thread From: Jesper Juhl @ 2005-01-10 22:11 UTC (permalink / raw) To: Steve Bergman; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 22:11 ` Jesper Juhl @ 2005-01-11 0:40 ` Chris Wright 2005-01-11 1:09 ` Diego Calleja 2005-01-11 17:05 ` Jesper Juhl 2005-01-11 9:49 ` Florian Weimer 1 sibling, 2 replies; 36+ messages in thread From: Chris Wright @ 2005-01-11 0:40 UTC (permalink / raw) To: Jesper Juhl; +Cc: Steve Bergman, linux-kernel * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 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 1 sibling, 1 reply; 36+ messages in thread From: Diego Calleja @ 2005-01-11 1:09 UTC (permalink / raw) To: Chris Wright; +Cc: juhl-lkml, steve, linux-kernel 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 1:09 ` Diego Calleja @ 2005-01-11 1:18 ` Chris Wright 0 siblings, 0 replies; 36+ messages in thread From: Chris Wright @ 2005-01-11 1:18 UTC (permalink / raw) To: Diego Calleja; +Cc: Chris Wright, juhl-lkml, steve, linux-kernel * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 0:40 ` Chris Wright 2005-01-11 1:09 ` Diego Calleja @ 2005-01-11 17:05 ` Jesper Juhl 2005-01-11 16:39 ` Alan Cox ` (2 more replies) 1 sibling, 3 replies; 36+ messages in thread From: Jesper Juhl @ 2005-01-11 17:05 UTC (permalink / raw) To: Chris Wright; +Cc: Jesper Juhl, Steve Bergman, linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 17:05 ` Jesper Juhl @ 2005-01-11 16:39 ` Alan Cox 2005-01-11 21:25 ` Jesper Juhl 2005-01-11 17:57 ` Chris Wright 2005-01-12 12:23 ` Florian Weimer 2 siblings, 1 reply; 36+ messages in thread From: Alan Cox @ 2005-01-11 16:39 UTC (permalink / raw) To: Jesper Juhl; +Cc: Chris Wright, Steve Bergman, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 16:39 ` Alan Cox @ 2005-01-11 21:25 ` Jesper Juhl 2005-01-11 21:29 ` Chris Wright 0 siblings, 1 reply; 36+ messages in thread From: Jesper Juhl @ 2005-01-11 21:25 UTC (permalink / raw) To: Alan Cox Cc: Jesper Juhl, Chris Wright, Steve Bergman, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 21:25 ` Jesper Juhl @ 2005-01-11 21:29 ` Chris Wright 2005-01-12 21:05 ` Jesper Juhl 2005-01-17 22:49 ` Werner Almesberger 0 siblings, 2 replies; 36+ messages in thread From: Chris Wright @ 2005-01-11 21:29 UTC (permalink / raw) To: Jesper Juhl Cc: Alan Cox, Chris Wright, Steve Bergman, Linux Kernel Mailing List * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 21:29 ` Chris Wright @ 2005-01-12 21:05 ` Jesper Juhl 2005-01-17 22:49 ` Werner Almesberger 1 sibling, 0 replies; 36+ messages in thread From: Jesper Juhl @ 2005-01-12 21:05 UTC (permalink / raw) To: Chris Wright Cc: Jesper Juhl, Alan Cox, Steve Bergman, Linux Kernel Mailing List, torvalds 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 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 1 sibling, 1 reply; 36+ messages in thread From: Werner Almesberger @ 2005-01-17 22:49 UTC (permalink / raw) To: Chris Wright Cc: Jesper Juhl, Alan Cox, Steve Bergman, Linux Kernel Mailing List 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/____________________________________________/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-17 22:49 ` Werner Almesberger @ 2005-01-17 22:52 ` Chris Wright 2005-01-17 23:23 ` Christoph Hellwig 0 siblings, 1 reply; 36+ messages in thread From: Chris Wright @ 2005-01-17 22:52 UTC (permalink / raw) To: Werner Almesberger Cc: Chris Wright, Jesper Juhl, Alan Cox, Steve Bergman, Linux Kernel Mailing List * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-17 22:52 ` Chris Wright @ 2005-01-17 23:23 ` Christoph Hellwig 2005-01-17 23:26 ` Chris Wright 0 siblings, 1 reply; 36+ messages in thread From: Christoph Hellwig @ 2005-01-17 23:23 UTC (permalink / raw) To: Chris Wright Cc: Werner Almesberger, Jesper Juhl, Alan Cox, Steve Bergman, Linux Kernel Mailing List 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? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-17 23:23 ` Christoph Hellwig @ 2005-01-17 23:26 ` Chris Wright 2005-01-17 23:57 ` Alan Cox 0 siblings, 1 reply; 36+ messages in thread From: Chris Wright @ 2005-01-17 23:26 UTC (permalink / raw) To: Christoph Hellwig, Chris Wright, Werner Almesberger, Jesper Juhl, Alan Cox, Steve Bergman, Linux Kernel Mailing List * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-17 23:26 ` Chris Wright @ 2005-01-17 23:57 ` Alan Cox 2005-01-18 1:08 ` Chris Wright 0 siblings, 1 reply; 36+ messages in thread From: Alan Cox @ 2005-01-17 23:57 UTC (permalink / raw) To: Chris Wright Cc: Christoph Hellwig, Werner Almesberger, Jesper Juhl, Steve Bergman, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-17 23:57 ` Alan Cox @ 2005-01-18 1:08 ` Chris Wright 0 siblings, 0 replies; 36+ messages in thread From: Chris Wright @ 2005-01-18 1:08 UTC (permalink / raw) To: Alan Cox Cc: Chris Wright, Christoph Hellwig, Werner Almesberger, Jesper Juhl, Steve Bergman, Linux Kernel Mailing List * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 17:05 ` Jesper Juhl 2005-01-11 16:39 ` Alan Cox @ 2005-01-11 17:57 ` Chris Wright 2005-01-12 12:23 ` Florian Weimer 2 siblings, 0 replies; 36+ messages in thread From: Chris Wright @ 2005-01-11 17:57 UTC (permalink / raw) To: Jesper Juhl; +Cc: Chris Wright, Steve Bergman, linux-kernel * 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 17:05 ` Jesper Juhl 2005-01-11 16:39 ` Alan Cox 2005-01-11 17:57 ` Chris Wright @ 2005-01-12 12:23 ` Florian Weimer 2 siblings, 0 replies; 36+ messages in thread From: Florian Weimer @ 2005-01-12 12:23 UTC (permalink / raw) To: Jesper Juhl; +Cc: Chris Wright, Steve Bergman, linux-kernel * 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). ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 22:11 ` Jesper Juhl 2005-01-11 0:40 ` Chris Wright @ 2005-01-11 9:49 ` Florian Weimer 1 sibling, 0 replies; 36+ messages in thread From: Florian Weimer @ 2005-01-11 9:49 UTC (permalink / raw) To: Jesper Juhl; +Cc: Steve Bergman, linux-kernel * 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-10 21:42 ` Steve Bergman ` (2 preceding siblings ...) 2005-01-10 22:11 ` Jesper Juhl @ 2005-01-11 16:10 ` Alan Cox 2005-01-12 12:33 ` Florian Weimer 3 siblings, 1 reply; 36+ messages in thread From: Alan Cox @ 2005-01-11 16:10 UTC (permalink / raw) To: Steve Bergman; +Cc: Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-11 16:10 ` Alan Cox @ 2005-01-12 12:33 ` Florian Weimer 2005-01-13 15:36 ` Alan Cox 0 siblings, 1 reply; 36+ messages in thread From: Florian Weimer @ 2005-01-12 12:33 UTC (permalink / raw) To: Steve Bergman, Linux Kernel Mailing List * 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-/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Proper procedure for reporting possible security vulnerabilities? 2005-01-12 12:33 ` Florian Weimer @ 2005-01-13 15:36 ` Alan Cox 0 siblings, 0 replies; 36+ messages in thread From: Alan Cox @ 2005-01-13 15:36 UTC (permalink / raw) To: Florian Weimer; +Cc: Steve Bergman, Linux Kernel Mailing List 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <200501101959.j0AJxUvl032294@laptop11.inf.utfsm.cl>]
* Re: Proper procedure for reporting possible security vulnerabilities? [not found] <200501101959.j0AJxUvl032294@laptop11.inf.utfsm.cl> @ 2005-01-10 21:36 ` Indrek Kruusa 0 siblings, 0 replies; 36+ messages in thread From: Indrek Kruusa @ 2005-01-10 21:36 UTC (permalink / raw) To: Horst von Brand; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2005-01-18 1:14 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-10 16:46 Proper procedure for reporting possible security vulnerabilities? 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 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] <200501101959.j0AJxUvl032294@laptop11.inf.utfsm.cl> 2005-01-10 21:36 ` Indrek Kruusa
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).