Yes, this process needs refinement, it's on my list of things to worry about.
We will have a standard way for handling security issues, and part of the upcoming rollout of our defect management system, procedure will target security bugs. Got the memo, it's a problem we'll work on a fix. > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Peter Jones > Sent: Friday, April 15, 2016 8:44 AM > To: Dick Wilkins <dick_wilk...@phoenix.com> > Cc: edk2-de...@ml01.01.org; Kevin Davis <kevin.da...@insyde.com>; Laszlo > Ersek <ler...@redhat.com>; Zhang, Chao B <chao.b.zh...@intel.com>; > Long, Qin <qin.l...@intel.com> > Subject: Re: [edk2] [PATCH] SecuritPkg: DxeImageVerificationLib: Fix wrong > verification logic in DBX & DBT > > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
