On Fri, Apr 15, 2016 at 08:10:50AM -0700, Dick Wilkins wrote: > Peter, > > Yes, we definatly have a broken procedure here. I think that Tony M. needs to > work with the USRT to develop a procedure for handling security issues in the > open-source code. The general flow should be: > > 1- A security vulnerability is found and is reported to the USRT as well as > the Tianocore security alias. > 2- The USRT opens a tracking ticket and evaluates the severity and decides on > how to proceed. > 3- In most cases, we report the problem to our "notify" email alias, > preferably with the fix, and IBVs and OEMs adopt the fix. > 4- After a suitable timeframe, the problem and fix are disclosed by checking > in the code change to the open-source repository. > 5- If appropriate, after the fix is widely available and adopted, a CVE is > created.
CVE should be step 3 here, not step 5. You don't actually have to disclose what's broken or what the fix is to get a CVE allocated - often we get them as soon as we know there's a problem, sometimes without even knowing if it's possible to write an exploit. It's best to do it before the notification step if possible - that way the fix's commit message (and the USRT ticket) can say what CVE it's for, and when any level of public disclosure happens later, it'll include that. That in turn also means firmware updates' change logs can include the same CVE number. Even if it's in something that doesn't get publicly disclosed (say a BSP driver or other hardware support package), the same is true. That way it's easy for IBVs and OEMs to match up the private thing with the publicly disclosed info, and for consumers to figure out if they got the fix for a given vulnerability. > This is my proposal as chair of the UEFI Security Response team. For > those not familiar with us, please visit http://uefi.org/security. > Please feel free to provide input on this proposed process. > > Thanks, > Dick Wilkins > > ________________________________________ > From: edk2-devel [edk2-devel-boun...@lists.01.org] On Behalf Of Peter Jones > [pjo...@redhat.com] > Sent: Friday, April 15, 2016 10:51 AM > To: Zhang, Chao B > Cc: edk2-de...@ml01.01.org; Kevin Davis; Laszlo Ersek; Long, Qin > Subject: Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong > verification logic in DBX & DBT > > On Fri, Apr 15, 2016 at 12:40:14AM +0000, Zhang, Chao B wrote: > > Hi all: > > Thank you very much for the info. Do you agree to add "[USRT > > 0001604]: Bug found in SecuritPkg: DxeImageVerificationLib" into the > > log & check in this patch? > > What's the point of adding our internal tracker to it? If anything the > CVE should be part of the commit message. So we should still do that, > and tracking the progress in doing so with a USRT ticket is reasonable. > But there's a bigger problem: right now the bug is public info, and this > discussion is public: > http://thread.gmane.org/gmane.comp.bios.edk2.devel/10693 . > > The time for a ticket to be opened with USRT, having a CVE assigned, and > contacting vendors who may have shipped this code was *before* the patch > was posted to the list. Now we need to clean up the mess. > > Our saving grace here is that Jeremiah hasn't actually /issued/ any DBT > updates, so it's unlikely anybody is really vulnerable to the attack > unless vendors have added DBT entries to their own shipping firmwares > (which I also doubt). But what that distinction affords us is the > ability to learn the right procedures now, so when there's a worse > vulnerability found, we don't make the same mistakes again. > > -- > Peter > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > -- Peter _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
